5.3工作流型 Agent

先给直觉

很多人想象中的 Agent 是：

给它一个目标，它自己想办法全部完成。

这个想法很诱人，也很容易翻车。

真实产品里，更靠谱的方式通常是工作流型 Agent：

给 Agent 一条可控轨道。
让它在每一步做判断、调用工具、处理异常。
高风险动作前请人确认。

它不是完全自由，也不是完全死板。

好的工作流型 Agent 像一个有操作手册的助手：能灵活处理情况，但不会拿着公司印章去自由创作。

三种形态

传统 Workflow

传统工作流按固定步骤执行。

例子：

提交表单 → 主管审批 → 财务审批 → 打款

优点：

• 稳定。
• 可审计。
• 容易控制。

缺点：

• 灵活性低。
• 很难处理模糊输入。
• 需要提前写好所有规则。

自由 Agent

自由 Agent 根据目标自己规划步骤。

优点：

• 灵活。
• 适合开放任务。
• 可以根据中间结果调整。

缺点：

• 难预测。
• 难评估。
• 容易跑偏。
• 权限风险高。

工作流型 Agent

工作流型 Agent 把两者结合：

• 流程骨架由系统定义。
• 每一步允许模型做有限判断。
• 工具和权限受控。
• 高风险动作有人确认。

这通常更适合真实产品。

为什么要限制自由度

Agent 太自由会带来几个问题：

• 计划不稳定。
• 工具调用顺序不可控。
• 失败后乱重试。
• 很难复现问题。
• 难以审计。
• 用户不知道它做了什么。

限制自由度不是让 Agent 变笨，而是让它可控。

好系统不是让模型想干嘛就干嘛，而是让它在合适范围内做判断。

基础结构

一个工作流型 Agent 可以这样设计：

任务输入
  ↓
任务分类
  ↓
计划生成
  ↓
步骤执行
  ↓
工具调用
  ↓
结果检查
  ↓
是否需要人类确认
  ↓
继续 / 停止 / 失败处理
  ↓
输出结果和日志

每一步都可以设计边界。

Planner-Executor

Planner-Executor 是常见模式。

• Planner：负责拆解任务，制定计划。
• Executor：负责执行每一步。

例子：

用户任务：

请帮我把这篇论文整理成课程选题。

Planner 可能输出：

1. 提取论文核心问题。
2. 总结主要方法。
3. 找出和课程模块的关系。
4. 生成 3 个公众号选题。
5. 标注需要事实核查的点。

Executor 按步骤执行。

优点：

• 计划清楚。
• 中间结果可检查。
• 方便失败定位。

风险：

• Planner 计划可能不合理。
• Executor 可能误解步骤。
• 计划执行中可能需要动态调整。

ReAct 思路

ReAct 可以粗略理解为让模型交替进行：

• Reason：思考下一步。
• Act：执行动作。
• Observe：观察结果。

简化形式：

思考：我需要查课程资料。
动作：调用 search_course。
观察：找到 RAG 和微调的章节。
思考：现在可以比较两者。
动作：生成回答。

ReAct 的价值是把推理和行动连接起来。

但真实系统中，不一定要把模型所有思考暴露给用户。产品层可以保留结构化日志，而不是展示一长串内部过程。

状态机

状态机适合把 Agent 限制在明确状态里。

例如课程内容生产 Agent：

待选题
  ↓
已定主线
  ↓
已生成大纲
  ↓
已生成初稿
  ↓
待事实核查
  ↓
待人工审阅
  ↓
可发布

每个状态允许的动作不同。

好处：

• 状态清楚。
• 容易恢复。
• 容易审计。
• 不容易跳步骤。

这对长任务特别重要。

人类确认节点

工作流型 Agent 里，确认节点要提前设计。

需要确认的情况：

• 发布内容。
• 发送消息。
• 删除文件。
• 花钱。
• 修改生产数据。
• 处理敏感资料。
• 进入下一阶段前需要用户判断。

确认节点应该显示：

• 当前任务。
• 已完成步骤。
• 即将执行动作。
• 影响范围。
• 可选操作。

不要让用户只看到一个神秘的“继续”按钮。

错误处理

工作流型 Agent 必须设计错误处理。

常见错误：

• 工具失败。
• 检索无结果。
• 权限不足。
• 输出格式不合法。
• 用户取消。
• 中间状态丢失。
• 外部 API 超时。

每种错误至少要决定：

• 是否重试。
• 是否换工具。
• 是否降级。
• 是否请求用户帮助。
• 是否停止任务。

日志与可观察性

工作流型 Agent 必须记录：

• 用户目标。
• 计划。
• 工具调用。
• 工具参数。
• 工具结果。
• 状态变化。
• 人工确认。
• 错误和重试。
• 最终输出。

没有日志，Agent 一旦出错，你只能看着结果发呆。发呆不是调试方法，虽然很常见。

案例：课程文章生产 Agent

目标：

把一个课程单元转成公众号文章初稿。

工作流：

1. 读取课程单元。
2. 提取核心问题。
3. 生成文章主线。
4. 生成 3 个标题候选。
5. 生成人话解释和案例。
6. 标注事实核查点。
7. 生成初稿。
8. 按风格检查表自检。
9. 等待人工审阅。

工具：

• 文件读取。
• 课程索引查询。
• 事实核查队列写入。
• 草稿写入。

确认节点：

• 选题主线确认。
• 标题确认。
• 发布前确认。

失败处理：

• 找不到课程单元时停止。
• 事实不确定时进入核查队列。
• 风格检查不通过时返回修改。

案例：RAG 问答 Agent

目标：

回答课程问题，并在资料不足时停止。

工作流：

1. 判断问题是否属于课程范围。
2. 改写查询。
3. 检索课程资料。
4. 判断检索结果是否足够。
5. 生成回答和引用。
6. 检查引用是否支持结论。
7. 输出回答或说明资料不足。

这里 Agent 不需要自由决定所有步骤。它只在每一步做有限判断。

常见误区

误区 1：工作流型 Agent 不够智能

可控不是不智能。真实产品常常需要稳定胜过自由发挥。

误区 2：有了 Planner 就万事大吉

Planner 也会出错。计划需要检查和调整。

误区 3：所有中间思考都要展示给用户

不一定。用户需要可理解的过程和结果，不一定需要模型内部长篇推理。

误区 4：错误处理可以以后再说

Agent 的错误处理必须早设计。否则上线后错误会替你开会。

误区 5：状态不重要

长任务没有状态，就很难恢复、审计和排错。

动手练习

设计一个“AI 课程内容生产 Agent”。

填写：

项目	你的设计
用户目标
工作流步骤
每一步使用的工具
状态列表
需要人工确认的节点
可能失败的地方
失败处理方式
需要记录的日志