5
选择控制方式:工作流、路由还是 Agent
参考:来源 B · Anthropic
学完你能做到
- 用一句话说清 workflow 和 agent 的分界
- 面对一个需求,先判断需不需要 agent,再想怎么实现
- 说出"什么都让模型自己决定"会带来的四个具体后果
前面几个模块讲的都是"agent 怎么做"。这一节讲一个更前面的问题:你到底需不需要 agent?
这可能是整个课程里最省钱、最省调试时间的一节。
两者的分界
先建立直觉
工作流像菜谱:第一步切菜,第二步下锅,第三步调味。谁做都是这三步,做一百遍都一样。
Agent 像让厨师自由发挥:给他食材说"做个好吃的",他自己决定做什么菜、先做哪一步。可能很惊艳,也可能翻车,而且每次都不一样。
"全交给模型"会发生什么
这是学生第一次做 agent 项目最常见的失败模式。四个具体后果:
- 结果每次都不一样。 本来三步固定流程能解决的,做成自由发挥,同一个输入跑两遍得到两个答案,没法测试。
- 调试时无从下手。 没有确定的执行路径,你不知道它这次为什么这么走。
- 贵十几倍。 每一次"想一下"都是一次模型调用,都在烧。
- 出了错分不清是谁的锅。 是提示词写得不好?工具描述不清楚?还是模型今天状态不对?
常见误解
用 agent 显得技术更先进,项目答辩会加分。
实际上
恰恰相反。能看出"这个需求不需要 agent"并且说明理由,比硬做一个 agent 更能体现你想清楚了。
Anthropic 那篇文章整体的立场就是:构建模块化、透明、渐进自主的系统,而不是臃肿的"全知全能"型。
一个判断流程
- 步骤能不能提前列出来? 能 → 写普通代码,可能连模型都不需要
- 步骤固定,但需要模型的语言能力? → (模式一)
- 有几类明显不同的输入,各需要不同处理? → (模式二)
- 子任务能提前拆好,而且互不依赖? → (模式三)
- 子任务的数量和性质取决于具体输入,提前不知道? → (模式四)
- 输出需要反复打磨,而且有清晰的评价标准? → (模式五)
- 以上都不匹配,任务开放到无法预设结构? → 这才是真正需要 agent 的场景
案例推演:同一产品里的三种控制方式怎样分工
售后系统既有固定退款规则,又要按问题类型分流,还要处理描述模糊的复杂故障。用一种控制方式覆盖全部任务,要么僵硬,要么失控。
本节追问:Workflow、Router 和 Agent 分别应该控制哪类不确定性? 先不要急着看结论。沿着下面四步,逐项区分输入、决策、证据和失败信号。
| 阶段 | 本步要做的决定 | 什么算证据 | 最常见的失败 |
|---|---|---|---|
| 固定流程 | 身份校验、订单检查、退款入账使用 Workflow | 规则明确且必须稳定重放 | 让模型决定财务记账顺序 |
| 分类路由 | 按退货、维修、物流和咨询选择处理链 | 类别有限且每类后续流程明确 | 用自由 Agent 做简单四分类 |
| 开放处理 | 复杂故障由 Agent 选择诊断工具和追问 | 路径无法事先枚举但边界清楚 | 让 Agent 获得无限工具和轮次 |
| 统一收口 | 所有路径进入相同的权限、审计与完成检查 | 结果格式和责任归属一致 | 三条路径各自随意结束 |
阅读方式:先遮住后两列自己回答,再用“证据”和“失败”两列检查理解。
常见误解
按“技术先进程度”选择控制方式
实际上
可观察症状:简单任务成本上升,复杂任务仍缺少边界。
更可靠的修复:按路径可预测性、风险、动作可逆性和验证难度选择。
案例工作坊 · 建议真正动手完成
25 分钟- 给十个售后动作分别标 W、R 或 A,并说明理由。
- 找出一个 Router 分错后可安全恢复的设计。
- 为 Agent 路径设置轮次、金额和工具上限。
查看参考答案
控制方式没有高低:固定、有限分支、开放决策对应不同问题。好的系统会组合使用,并让所有路径共享安全与验证层。
迁移检查:换一个场景还会不会
只有“账单、技术、物流”三类且后续流程固定,首选是?
检查一下
"把这篇中文文档翻译成英文,然后检查术语是否统一。"这个需求应该用什么?