AI产品经理进阶：手把手教你把 Agent 实战工作流跑通

前言：为什么 Agent 工作流是 AI 产品经理的必修课？

在生成式 AI 爆发的初期，许多 AI 产品经理的工作主要围绕着“调 Prompt（提示词工程）”展开。然而，随着业务场景的深入，大家逐渐发现：纯文本对话的“单轮 Prompt”在面对复杂、严谨的业务逻辑时，往往表现出极大的不确定性。大模型的幻觉、无法保证 100% 遵循格式、以及复杂的条件分支判断，让传统软件研发中习以为常的“确定性逻辑”变得难以落地。

正是为了解决这一痛点，AI Agent（智能体）工作流应运而生。工作流的核心思想在于“逻辑分治”：将一个庞大复杂的生成任务，拆解为多个单一职责的节点（如意图识别、逻辑判断、知识库检索、代码执行、大模型微调等），并通过确定性的有向无环图（DAG）将它们串联起来。

对于 AI 产品经理而言，跑通 Agent 实战工作流不再是一个选修课，而是核心竞争力。这不仅能让你深入理解大模型的底层运作机制，更能让你掌握将“非确定性 AI 能力”封装为“确定性商业产品”的设计范式。今天，我们就以 Dify 和 Coze（扣子）两大主流低代码 Agent 平台为例，带大家手把手拆解并跑通一个实战工作流。

大脑入口：基于意图识别（Intent Recognition）的输入与决策

任何一个智能客服或助理工作流，其第一步都是“听懂用户的意图，并做出正确的路线分发”。这在技术上被称为意图识别（Intent Recognition）。

在传统的 NLP 时代，意图识别通常依赖于关键词匹配或专用的意图分类小模型，开发成本高、扩展性差。而在大模型时代，我们可以直接利用 LLM 的语义理解能力来做零样本（Zero-Shot）或少样本（Few-Shot）的意图分类。

1. 意图识别节点的设计规范

在可视化工作流平台（如 Dify）中，意图识别节点通常是作为工作流的“总闸”。我们必须为它定义清晰的输入与输出 Schema：

• 输入变量 (Input)： query (String 类型)，即用户发送给智能体的原始文本。

• 配置选项 (Options / Classifications)： 预设的分类意图，例如：* 饮食 (Diet)：询问食物、菜谱、减肥餐等。* 出行 (Travel)：询问路线、天气、旅游目的地等。* 穿衣 (Clothing)：询问穿搭建议、温度变化穿衣等。* 健身 (Fitness)：询问运动、健身计划、减脂等。* 其他 (Other)：超出上述范围的闲聊或模糊表达。

2. 结构化输出的必要性

意图识别节点不能仅输出一段“大白话”作为分类，它必须输出结构化数据，以便下游的计算机逻辑进行解析。例如：

• classificationId (Integer 类型)：用于下游条件路由节点进行快速 If-Else 判断的唯一 ID。

• reason (String 类型)：大模型判定此分类的推理逻辑。这个字段对于后续的系统 Debug 和 Bad Case 分析极其关键。

以下是意图识别节点的标准输出 JSON 样例：

{
  "classificationId": 0,
  "reason": "The user's query discusses eating braised pork to lose weight, which is an unconventional and contradictory claim, falling outside regular dietary counseling."
}

确定性路由：低代码平台的分支逻辑设计

当意图识别节点输出 classificationId 后，工作流需要通过条件路由（Conditional Branch / Branching Node）将流量分发到不同的子节点。

在低代码平台中，条件路由相当于传统编程中的 switch-case 或 if-else。例如：

• IF classificationId = 1 (饮食) -> 执行“健康饮食 RAG 检索” -> 调用大模型回复。

• ELSE IF classificationId = 2 (出行) -> 调用“高德地图 API” -> 返回出行卡片。

• ELSE -> 走兜底回复。

下图展示了典型的意图识别路由工作流逻辑：

变量注入与插值

在分支处理节点（通常是文本生成或模板格式化节点）中，我们通常需要将意图识别或 API 返回的数据注入到回复模板中。最常用的语法是双大括号变量插值，例如：

• “出去玩？骑着！{{output}}”

• “穿秋裤呀 {{output}}”

• “啥也没干 {{output}}”

这里的 {{output}} 是一个动态变量，可以在工作流中自由传递和注入，确保了生成内容的个性化和动态化。

Bad Case 拆解：从“红烧肉减肥”看大模型常识推理与兜底

在实际运营中，用户的提问往往千奇百怪，甚至包含大量反常识或挑衅性内容。例如，用户输入一个看似与“饮食”相关的 Query：

“红烧肉多吃减肥吧”

作为一个合格的 Agent 产品经理，你应该如何设计工作流来应对这类提问？

1. 大模型的 CoT 推理过程

如果直接进行简单的关键字匹配，看到“红烧肉”就路由到“饮食分类（ID=1）”，下游的健康饮食智能体可能会顺着用户的话茬开始建议如何烹饪红烧肉，从而产生违背健康常识的幻觉。

通过配置意图识别节点的 Prompt，让 LLM 具备思维链（Chain of Thought, CoT）推理能力，LLM 会给出如下思考路径：

"The user's input expresses an unclear intention. While the mention of '红烧肉' could potentially be related to food or cooking, the statement about 'eating more to lose weight' is not a typical or established belief. It may be a personal opinion or a misunderstanding, and it does not clearly fall into any of the provided intention classifications." （用户的输入表达了不明确的意图。虽然提到了“红烧肉”（与食物相关），但“多吃红烧肉能减肥”的说法不符合常识或事实。这可能是一个误解，无法清晰归入任何预设意图。）

2. 兜底策略（Fallback）的意义

基于上述推理，LLM 将此提问的 classificationId 判定为 0（“其他”分类），流程自动走向了兜底分支（输出_1）。

• 执行耗时： 意图识别节点涉及模型思考，耗时约为 2~3 秒；而下游的兜底条件判断和文本拼接为纯逻辑计算，耗时仅 0.012s。

• 这种“大模型重推理 + 逻辑轻路由”的架构，既保证了对用户怪异提问的灵敏反应，又避免了胡乱路由导致的灾难性回答，是极其经典的 Agent 健壮性设计。

高阶实战：基于 Coze/扣子 搭建抖音电商智能客服 Agent

理解了基础的工作流编排，我们来看一个更贴近企业级实战的案例：基于 Coze（扣子）平台为抖音电商搭建智能客服系统。

在电商售后场景中，客服智能体面临的挑战更加严峻：多轮对话的状态管理、精确查询用户订单数据库、退换货 SOP 流程遵循、以及在 AI 无法解决时顺畅转接人工客服（Human-in-the-Loop）。

1. 电商智能客服的节点架构设计

基于 Coze 的多节点协同架构，我们可以将系统拆解为以下核心模块：

• 主流程逻辑控制（Main Flow）：作为整个会话的总入口，负责拦截用户的所有话语，进行会话状态（Session State）判断，并分发给对应的子流程。

• 大模型节点 (LLM Nodes)：* 寒暄与引导节点：处理开场白、感谢等非业务闲聊。* 澄清引导节点：当用户诉求不清晰（如“我想退货”但未提供订单号）时，主动询问并引导用户补充信息。* 方案决策节点：根据用户提供的信息与库表查询结果，判定是否符合退款或补偿政策。

• 逻辑与插件节点 (Logic & Tool Nodes)：* 订单查询接口 (REST API)：传入用户 ID/手机号，获取近期抖音订单列表。* 私有知识库 (RAG)：绑定店铺的“7天无理由退换货细则”、“大促发货时效规范”等，供大模型检索并提炼权威解答。

2. 服务链路的智能化运转流程

以下是完整的电商客服智能体运行逻辑流：

AI 产品经理的避坑指南

在设计和跑通 Agent 工作流的过程中，很多产品经理会陷入过度技术化或过度依赖大模型的误区。以下是梳理出的三条金科玉律：

1. 能用规则判断的，绝不用大模型： 大模型每次调用都有 token 成本和耗时，且存在随机性。如果是订单号格式校验、手机号提取等确定性任务，直接写正则表达式或调用 Python 脚本节点，不要用大模型，保证速度与 100% 确定性。

2. 注重节点间的 Schema 约束： 在设计每个节点时，要像开发写接口文档一样，严格定义好 Input/Output 的数据结构与数据类型（例如 reason 是 String，status_code 是 Integer）。只有输入输出标准化，才能在后续将工作流平滑地接入到已有工程中。

3. 务必设计兜底（Fallback）与人工兜底（Human-in-the-Loop）： AI 的认知是有边界的。工作流中必须有一个兜底分支来友好地回答“对不起，我暂时无法处理您的请求”；同时对于电商等高净值场景，必须留有“一键呼叫人工客服”的物理通道，避免把用户逼疯。

结语

掌握 Agent 实战工作流的构建，是从“尝鲜 AI 的爱好者”走向“落地 AI 的产品专家”的必由之路。通过将大模型的“混沌思考能力”嵌套进软件工程的“严谨管道”，我们才能真正创造出兼具智能度与可用性的商业级 AI 产品。

长按二维码关注 “边学边练”