Workflow 与 Agent
路径预先写好 vs 动态决策，以及两者之间的光谱。
一句话理解：Workflow 的执行路径由人预先写好，Agent 的执行路径由模型边做边决定。真正的设计问题不是二选一，而是为每一步决定它在这条光谱上的位置。
“我们要做一个 Agent”是今天最常见的需求开头，但很多需求真正需要的是一条设计良好的 Workflow。反过来，也有团队把一个本该交给模型判断的排查过程写成几百个 if-else，每出现一种新异常就要发一次版。
Anthropic 在《Building effective agents》一文中给出了一个清晰的区分：Workflow 是通过预先定义的代码路径来编排 LLM 和工具的系统；Agent 是由 LLM 动态决定自己的执行过程和工具使用、自己掌控如何完成任务的系统。两者都算“智能体系统”，区别只在于：下一步由谁决定。
两种系统的差异
| 维度 | Workflow | Agent |
|---|---|---|
| 下一步由谁决定 | 代码（人预先写好） | 模型（根据上一步的结果） |
| 可预测性 | 高，同样的输入走同样的路径 | 较低，同样的输入可能走不同路径 |
| 成本与延迟 | 可预估，通常更低 | 波动大，步数越多越贵 |
| 调试方式 | 看是哪个节点出了错 | 需要阅读完整轨迹，理解模型为什么这么走 |
| 适合的任务 | 步骤可以提前枚举、要求一致可审计 | 步骤无法提前确定、需要边查边判断 |
| 典型失败 | 遇到没设计过的情况就卡住或走错分支 | 跳步、绕远路、陷入循环、过早宣布完成 |
注意，Workflow 里完全可以有 LLM。一条“抽取字段 → 校验 → 生成摘要”的流水线，每一步都调用模型，但下一步永远是固定的，所以它仍然是 Workflow。判断的标准从来不是“用没用模型”，而是**“控制流在谁手里”**。
同一个任务的两个版本
任务：判断一条客服工单反映的是什么问题，并给出处置建议。
Workflow 版：
Agent 版：
两个版本的表现：
- 90% 的常见工单（发货延迟、未支付），Workflow 版又快又便宜，结果也稳定。
- 遇到“订单显示已发货，但支付回调失败，用户上个月还提过同一个问题”这种组合问题，Workflow 版只能输出“未知原因”；Agent 版会顺着线索去查退款记录和历史工单。
- 代价是：Agent 版每单的调用次数不固定，偶尔会重复查询同一个接口，或者证据不足就下结论。
这正是 Anthropic 那篇文章的核心建议：先找最简单的方案，只在确有必要时才增加复杂度。 Agent 系统通常是用更高的延迟和成本，换取在复杂任务上更好的表现，这笔交易值不值，要具体计算。
光谱：从单次调用到自主 Agent
现实中的系统不是非黑即白，而是分布在一条光谱上：
几点观察：
- 最左边的“增强型 LLM”（一次模型调用，配上检索、工具或记忆）是所有系统的基本构件，很多需求到这里就已经够用。
- 中间几种 Workflow 模式各有适用场景，见下一课「常见 Workflow 模式」。
- 同一个产品的不同步骤，可以处在光谱上的不同位置，这就是「混合架构」要解决的问题。
- 这条光谱和「自主性等级 L0–L5」相关但不同：自主性等级描述 Agent 能在多大程度上不经人确认就行动，这里讨论的是执行路径由谁决定。
怎么选：四个判断
1. 路径能否提前枚举？ 把处理步骤写在白板上。如果 90% 以上的情况都能用有限的分支覆盖，先做 Workflow；如果每次都要“看情况”，才考虑 Agent。
2. 对一致性和可审计性的要求有多高？ 财务结算、合规审批这类场景，“每次都按同样的步骤处理”本身就是需求，适合 Workflow。允许过程有差异、只要结论正确的场景，可以交给 Agent。
3. 有没有可靠的反馈信号？ Agent 需要在环境中得到真实反馈，才能判断自己是否走在正确的路上。Coding Agent 能跑测试，数据分析 Agent 能核对总数，这些场景适合 Agent；没有任何反馈信号的任务，Agent 容易越跑越偏。详见「为什么必须验证」。
4. 量有多大，每次的价值有多高？ 每天 10 万单的例行分类，每单多花几次模型调用就是一笔大钱；每天 20 单的疑难排查，每单节省一个专家半小时，Agent 的成本完全可以接受。成本测算见「成本模型」。
常见误区
- “Agent 比 Workflow 更高级。” 这是控制权分配的不同选择，不是技术先进性的高低。能用 Workflow 稳定解决的问题，改成 Agent 往往更贵、更慢、更难调试。
- “用了 LLM 就是 Agent。” 控制流在代码里，就是 Workflow，不管里面调用了多少次模型。
- “先选一个 Agent 框架，再想怎么用。” Anthropic 建议先直接调用模型 API 实现，很多模式几行代码就能写出来；框架会增加抽象层，让 Prompt 和模型响应更难看清、更难调试。
- “一次定型。” 常见的演进路径是：先用 Workflow 覆盖高频情况，把规则解决不了的部分交给 Agent 节点；或者先用 Agent 做原型，再把轨迹中反复出现的固定路径固化成 Workflow。
产品经理检查清单
听到“做一个 Agent”时，先问：
- 能不能把处理流程画成一张有限分支的流程图？画不出来的部分具体是哪几步？
- 如果两次处理同一个输入走了不同路径，业务上能接受吗？
- Agent 做完每一步，能从环境中拿到什么反馈来判断对错？
- 预计日处理量是多少？单次处理的业务价值是多少？
- 最简单的可行方案是什么？它在哪些案例上失败了？
练习
把「找出上周销售额下降的原因」分别设计成 Workflow 版和 Agent 版（约 45 分钟）：
- 画出 Workflow 版：固定查询哪些维度、按什么规则得出结论。
- 画出 Agent 版：提供哪些工具、何时结束、结论需要附带什么证据。
- 准备 3 个案例：一个简单的（某区域整体下滑）、一个中等的（某 SKU 缺货）、一个复杂的（促销口径变更叠加渠道迁移）。分别推演两个版本会怎么处理，并填表：
| 案例 | Workflow 版结果 | Agent 版结果 | 你会选哪个 | 理由 |
|---|---|---|---|---|
延伸阅读
- Building effective agents：Anthropic 对 Workflow 与 Agent 的定义、常见模式，以及“从简单开始”的设计原则。
下一步
下一课「常见 Workflow 模式」会讲五种最常用的编排模式：链式、路由、并行、编排者-执行者、评估者-优化者，以及它们各自适合什么场景。