Agentic Workflow
Agentic Workflow 这个概念最早被讲清楚，是 Anthropic 2024 年 12 月的《Building Effective Agents》。它把基于 LLM 的系统分成两类：
- Workflow：通过预定义的代码路径编排 LLM 和工具。开发者提前画好流程图，LLM 只在固定节点上干活，不决定流程走向
- Agent：LLM 在运行时动态决定自己的流程和工具使用，自己掌控怎么完成任务
判断标准只有一个：控制权在谁手里。代码写死下一步去哪，就是 Workflow；模型运行时决定下一步做什么，就是 Agent。一个实用的判断：能不能在 LLM 运行之前画出完整的流程图？能，用 Workflow；不能，才考虑 Agent。
这套分类和前面几篇的关系：ReAct、Plan-and-Execute 是 Agent 的内部循环，五种 Workflow 模式是编排层。一个系统叫什么不重要，重要的是每个决策点由谁决定。
五种工作流模式
Anthropic 从生产系统里归纳了五种反复出现的模式：
Anthropic 五种工作流模式
Prompt Chaining。 把任务拆成顺序步骤，每一步处理上一步的输出。关键在程序化门控（gate）：中间结果不符合要求就中断，防止坏结果污染下游。适合能干净拆成固定子任务的任务，用延迟换准确率。
Routing。 对输入分类，转发给专门的后续任务。每个分支可以有独立的 prompt、工具集甚至模型。适合输入类型多、每类处理逻辑固定的场景，客服工单分诊、邮件分类都是经典例子。任务集很小的时候，用按钮做显式路由比 LLM 分类更快更便宜。
Parallelization。 两个变体：Sectioning 把任务拆成独立子任务并行跑再合并；Voting 同一任务跑多次取投票结果，正确性比成本重要时用，比如内容安全审查。延迟上把 n 次串行变成一次加合并开销，但合并逻辑设计不好，结果可能比串行还差。
Orchestrator-Workers。 中心 LLM 动态拆解任务、分派给 worker、汇总结果。和并行化的区别是灵活性：子任务不是预定义的，由 orchestrator 根据具体输入决定。多 Agent 篇讲的 Orchestrator-Worker 在这里的边界是：如果 for 循环分发、汇总逻辑由代码控制，worker 只是执行固定 prompt，整体就是 Workflow；如果每个 worker 自己决定调什么工具、跑几步，那就是多 Agent 系统。
Evaluator-Optimizer。 一个 LLM 生成，另一个评估反馈，循环到质量达标。适用条件有两个：人类给出明确反馈时输出能明显改进，且 LLM 自己能提供这样的反馈。生成器和评估器角色分离，生成器敢冒险，评估器保持严苛。评估器 prompt 是整套循环质量的上限，评分要结构化（分维度打分加具体反馈），不能用一句“不够好”。
什么时候用哪个
Anthropic 的原则很直接：从最简单的方案开始，只有在性能明显改善时才增加复杂性。 大多数场景，单次 LLM 调用加 RAG 就够，不需要任何模式。
选型可以按三个问题走：
- 终点能不能模板化？ 产出能定义成一张表或 schema，每个字段怎么填都预先规定，才配得上 Workflow。只有测试能判对错、产出形态开放的任务（比如任意代码改动），评测和护栏就是本体成本
- 起点是不是单一任务？ 是，不需要路由；否，前面加一层路由收敛意图
- 执行环境有界吗？ 会遇到的输入类型有限、状态机吃得下，纯 Workflow 成立。代码库是无界的，你永远不知道打开一个仓库会看到什么，只能上 Agent
注意一个反直觉点：修 bug 的 coding agent 起点确定、终点也有测试当裁判，按说该走 Workflow，但业界全用自主 Agent。因为“测试通过”是成功标准，不是模板。终点确定性决定的不是要不要 Agent，而是 Agent 能不能被评测兜住。
混合形态：Agentic Workflow
纯 Workflow 太脆，穷举不了所有情况；纯 Agent 太不可控，成本不可预测还难排查。生产里最主流的其实是混合：Workflow 固定主流程骨架，在需要灵活判断的节点嵌入 Agent，其余固定节点直接用 LLM 或工具。
骨架是确定的，出问题知道在哪一环，调试、审计、成本都可控；关键节点是灵活的，能应对预料之外的情况。成熟产品的形态基本是“路由加多条工作流加兜底的人工或 Agent”，比如客服系统：八成请求（退款、查物流、改地址）步骤固定走 Workflow，两成复杂投诉走 Agent，设轮数上限和转人工兜底。不要因为 20% 的复杂 case 把整个系统做成 Agent。
生产注意
- 模式可以组合，但嵌套别超过两层。 常见的组合：路由进链、orchestrator 扇出并行、链尾挂评估优化。嵌套过深，调试复杂度和延迟一起涨
- 评估先行。 成功的关键是衡量性能再迭代，不是堆复杂度。Workflow 用单元测试式验收，Agent 用统计评估看质量分布
- 验收别用错标尺。 用验收 Workflow 的逻辑验收 Agent（要求每次输出一致），或用灵活性苛责 Workflow（抱怨它处理不了未预设的边界），都是选型灾难
面试追问
- Workflow 和 Agent 的本质区别？ 控制流归属。代码写死下一步去哪是 Workflow，模型运行时决定是 Agent。判断：能不能在 LLM 运行前画出完整流程图
- Orchestrator-Workers 用了 LLM 拆任务，为什么不算 Agent？ 拆任务用了 LLM，但分发循环、汇总逻辑由代码控制，模型不决定“要不要继续拆、要不要跳过某个 worker”。判断标准不是用没用 LLM，而是 LLM 是否控制整体流程走向
- Evaluator-Optimizer 算 Agent 吗？ 边界模糊。循环的 max_retries 由代码硬编码、评估器只做二分判断时是 Workflow；评估器能动态调整生成策略（“上轮内存泄漏，这次换算法”）就过渡到 Agent 了
- 什么时候从 Workflow 升级到 Agent？ 步骤不可预测（排障、debug）、工具选择依赖中间结果、需要长期规划动态调整。拿 50 个真实输入画决策树，叶子不超过 15 个就用 Workflow
- 大部分生产系统是纯 Workflow 还是纯 Agent？ 都不是，是混合。确定性骨架做路由和简单处理，复杂节点嵌入 Agent。纯 Workflow 分支爆炸后维护成本高，纯 Agent 不可控