「多智能体协作」听起来很美：一个规划、一个执行、一个审查，像一家公司。 但经验是：加 agent 常是在加复杂度，而不是加能力。 上一章《上下文工程与记忆》管的是单个 agent 的窗口， 这一章接着问：一个不够怎么办？
很多被叫做"多智能体系统"的东西，其实根本不需要多个智能体—— 它们需要的是一个工作流。
| 维度 | 工作流 Workflow | 多智能体 Multi-Agent |
|---|---|---|
| 路径 | 写在代码里，固定或条件分支 | 由模型临时决定，每次可能不同 |
| 可预测性 | 高。相同输入走相同路径 | 低。调试时你复现不了那个 bug |
| 成本 | 确定，可以提前算 | 波动很大，最坏情况不可控 |
| 什么时候用 | 任务能拆成明确的步骤时 | 任务无法预知需要几步、需要什么工具时 |
一张图 · 区别只有一个：下一步是谁定的
如果你能画出这个任务的流程图，那就写工作流，不要用多智能体。 只有当你画不出流程图——因为要做什么取决于中间结果、而且你事先不知道会得到什么—— 才需要让模型自己决定下一步。「能写死的东西就不要让模型决定」是省钱、省时、少 bug 的第一原则。
这是 Anthropic 总结的一套分类，非常实用——它把"多智能体"拆成了五个具体的结构， 而不是笼统的"多个 agent 协作"。
| 模式 | 结构 | 适合什么 |
|---|---|---|
| ① 提示链 Prompt Chaining |
A → B → C，串行分解 | 任务能干净地切成固定几步，每步的输入是上一步的输出 |
| ② 路由 Routing |
先分类 → 分派给不同的处理器 | 输入类型差异大（退款问题 vs 技术问题）， 用不同的提示/模型处理更划算 |
| ③ 并行 Parallelization |
同时跑多个分支 → 聚合结果 | 子任务互不依赖（同时检查合同的 5 个方面）， 或者需要多次投票提高可靠度（前提：错误互不相关，见第 5 节） |
| ④ 编排者-工作者 Orchestrator-Workers |
一个规划者动态拆任务 → 派给若干工作者 → 汇总 | 拆成几步事先无法预知，要看清内容才知道（比如改一个跨文件的 bug） |
| ⑤ 评估者-优化者 Evaluator-Optimizer |
一个生成 → 一个挑刺 → 拿反馈重做，循环几轮 | 有明确的评价标准，而且模型自己批自己确实能改好 |
它们对应一家公司里的五种工作方式：
提示链 = 流水线，一道工序接一道。
路由 = 前台分诊，先判断你该去哪个科室。
并行 = 多人同时审一份文件的不同章节，最后合并意见。
编排者-工作者 = 项目经理现场拆活、临时派人。
评估者-优化者 = 实习生写稿 + 主编反复打回重写。
较贵的是编排者-工作者和评估者-优化者：前者要有"事先说不清几步"的问题，后者要有明确的评价标准，才值得上。
这个类比管到"一份活由谁来做"为止：真公司里一个人能同时进好几件事，这里的每个格子都是一次完整的模型调用，串得越多越贵。
上一节把"多智能体"拆成了五种结构。这一节把它们的账算出来： 消息数怎么涨，成功率怎么掉。下面三张图都能自己拖。
动画 · N 个 agent 两两通信：每多一个人，多出一整排连线
互动 · 一条消息有多贵：它要过一次完整的模型
核心大图 · 成功率是乘出来的：拖可靠度看它怎么塌
成功率的账只有一个乘号：每道门只放过去 p，剩下的水一路乘下去——环节一多，塌得比直觉快得多。
图上这条曲线，就是"加 agent 买不到能力"的全部证据。
消息数那张图是同一件事的另一面：钱按 N² 涨，成功率按 p 的 N 次方掉，
一个涨得比 N 快，一个掉得比 N 快，夹出来的是同一句话——复杂度换不来能力。
任务设定：审阅一份 20 章合同（约 12000 token），找出风险条款并给出建议。 token 成本和延迟是按调用逐项累加的真实数字；成功率是按公式估的示意值，不是实跑。
两个数怎么来的：覆盖度 = 这条路线能照顾到多少种风险（固定三步约 0.85，并行四路约 0.95）； 单步可靠度 = 每个环节不出错的大致概率（各模式取 0.90~0.96）。都是示意值。 输出 token 按输入的 3 倍计价——主流 API 的输出单价约为输入的 3~5 倍。
互动 · 六种模式的成本 / 延迟 / 成功率
成本对比
成功率对比
互动 · 六个模式摊在同一张「成本 × 成功率」平面上
成功率和成本不是一回事。评估者-优化者的成功率最高（78.2%），代价是成本涨到单次的 2.7 倍、延迟多等 18 秒； 单次调用便宜到约其他模式的一半，但覆盖率最低。先问自己缺的是钱、时间，还是可靠性。
上面说的是工作流。那"真的多智能体"——每个 agent 有独立的循环、 能自己决定下一步、互相通信——什么时候才值得？只有两种情况。
互动 · 同一份材料，一个人背 vs 拆成两段
操作：拖大文件数，看单个 agent 的上下文什么时候塞不下、拆开后每个只读一半。
"让三个 agent 讨论一下，答案会更准"——这个假设通常不成立。
因为它们底层是同一个模型。让同一个模型换个说法再说一遍，
它的错误会高度相关——三个 agent 一起错同一个地方，比一个 agent 单独错更危险，
因为投票结果看起来更"可信"。
真正的多样性需要来自不同的东西：不同的工具、不同的数据、不同的提示策略——
而不是同一模型的三份拷贝。
| 代价 | 怎么发生的 | 什么时候真的会痛 → 换什么 |
|---|---|---|
| ① 通信开销爆炸 | N 个 agent 如果两两通信，消息数是 O(N²)（读作"大约按人数的平方增长"）。 而且每条消息都要经过一次模型推理才能产出或理解—— 5 个 agent 全连接有 10 条消息，通信成本可能是单 agent 的 10 倍 | 要几个 agent 两两互看时 → 改成星形（N−1 条）或串成流水线 |
| ② 错误传播 | agent A 产生一个幻觉，agent B 把它当成事实继续推理， agent C 再基于 B 的结论下判断。到最后没有任何一个环节知道源头是错的。 而且因为经过了"多个专家"，结论看起来更权威 | 一条长链、每步都以上一步的结论为前提 → 每步后加一次独立来源的校验 |
| ③ 调试地狱 | 非确定性（同一个输入跑两次，结果可能不一样）的系统上再叠一层非确定性， 可能走了完全不同的路径。"上次还能跑通"是最常见的一句话， 而你没法复现上次 | 线上偶发、你必须复现那一刻 → 把路径写死成工作流，别让它每次自己选 |
互动 · 错误传播：加 agent 到底让结果更好还是更糟
互动 · 投票到底能不能救回来：拖「错误相关程度」看它怎么失效
互动 · 方案演化
| 方案 | 是什么 | 适合 |
|---|---|---|
| 单 agent + 好工具 | 一个循环，配一套精心设计的工具 | 绝大多数任务的正确答案。先把这个做到极限，再考虑别的 |
| 工作流编排 | 用代码把固定步骤串起来（第 2 节的五种模式） | 能画出流程图的任务。可测、可控、成本可算 |
| LangGraph | 用图结构描述 agent 的状态流转，支持条件分支和循环 | 把它看作"带状态的复杂工作流"，而不是"多 agent 框架"—— 大多数用它的人做的其实是工作流 |
| AutoGen | 多个 agent 用对话的方式协作，可以有人参与 | 研究性质的多轮协商场景 |
| CrewAI | 给每个 agent 设定角色（研究员/写手/审稿人），按角色分工 | 概念直观，适合快速搭原型。但要小心"角色扮演"带来的成本膨胀 |
| MetaGPT / ChatDev | 模拟一整套软件公司的角色，让它们合作完成项目 | 演示和探索。实际项目里的性价比通常远低于一个会写代码的单 agent |
越往下的方案，演示效果越惊艳，生产性价比越低：它们把大量 token 花在了角色扮演和互相汇报上，
这些开销对最终结果没有直接贡献。
判断标准：一个 agent 用更多工具、更长的循环能做到同样的事，就用一个。
决策顺序（别跳步）
多智能体的问题不是"它不work"，而是"它 work 的成本几乎总是高于更简单的方案"。
这就像问"我要不要为公司每个职能都雇一个副总裁"——
在你有几百人之前，答案几乎都是"不"。
回到第 5 节那张「错误传播」。把「单个 agent 的可靠度」从 99.5% 往左拖到 80%—— 看「串联链成功率」那条指数曲线怎么塌下去：单看每个 agent 都挺靠谱，串起来的成功率还是掉得飞快。
那个瞬间你看到的就是「复杂度不等于能力」：加 agent 并不会让结论更可靠， 它只是把更多环节串在了一起。然后再把「独立校验的可靠度」往右拖一点， 看它怎么把成功率拉回来——救回来的是「不同来源的判断」，不是「更多的 agent」。 如果你刚才没想指着那条曲线说这句话，那一节对你就是没用的——回去再拖一遍。
| 直觉上 | 实际发生的事 |
|---|---|
| 三个 agent 讨论一下，答案会更准 | 底层是同一个模型，它们的错会一起犯——投票结果看起来更可信，反而更危险（第 4 节） |
| 拆成七步，每步简单一点，总该更稳 | 每步的可靠度是相乘的。单步 96% 听着很高，七步连乘只剩 75.1%；再乘上覆盖度，就掉到约 70% （第 5 节那张图量的就是这件事）——步骤越多，"最后一环把前面全带偏"的机会越多 |
| 结构越复杂 = 系统越强 | 结构只决定信息怎么流动，不决定每一环判断得多准。 所以正确的做法是加工具、加校验（换来源），而不是加 agent（加环节） |
| 暗线 | 这一章的回答 |
|---|---|
| A 信息流动 | 真正变的是 |
| D 跑在什么上 | 带宽受限。推理是一次解码一个 token 的过程，每吐一个 token 都要把整份权重从显存里过一遍——
所以 token 的价格，本质上就是显存带宽的价格。多 agent 真正贵的地方正是消息数量：
N 个 agent 两两通信是 O(N²) 条消息，每条消息都要过一次完整的模型推理。 反过来，第 3 节里并行是唯一"延迟不增加"的模式（4 路同时跑，总延迟只等于最慢那路）—— 因为它花的是并行算力而不是串行时间。所以"要不要组队"这个问题， 其实是在问"你缺的是 token 预算还是墙上时间"。 完整的带宽账在 《硬件与算力账本》 |
| E 它假设了什么 | 整套多 agent 的做法假设「多一个 agent 就多一份独立判断」。 第 4 节那段警告把这条假设戳破了：如果几个 agent 是同一个模型、看同一批资料， 它们的判断根本不独立。这也解释了第 5 节的反直觉结果—— 「每步加独立校验」在它足够可靠时最有效，是因为它换掉了信息来源，而"多投票"没有 |
它接住了上一章的什么：《上下文工程与记忆》管的是单个 agent 的窗口和记忆。再上一章《Agent 与工具调用》给了单个 agent 的循环和四个失败模式：大多数时候答案是"再给它配一个好工具"。
它给下一章留了什么：当决策路径由好几个 agent 共同决定时， "谁该为最后那句话负责"就变得说不清了——这就是 《对齐、安全与越狱》要面对的新问题。
能画出流程图就用工作流，顺序永远是单次调用 → 加工具 → 加工作流 → 最后才考虑多 agent。 多 agent 真正买到的只有上下文隔离和并行探索，代价是通信按 N² 涨、错误跨 agent 传染——复杂度换不来能力。
上面讲的都是「够用」的版本。想往下挖，这里有三个入口—— 它们不是必修内容，是给想再往前走一步的读者准备的。