前言：为什么多 Agent 编排总在生产环境里「看起来很美」
多 Agent 系统的上线咨询量同比增长了 14.5 倍（Gartner 数据），但 40% 的多 Agent 项目在上线六个月内宣告失败。问题从来不是多 Agent 本身——而是团队选错了编排模式，或者选对了模式却不知道它在哪里会坏。
这是我们做这次深度评测的出发点：不比功能比失效边界，不列表格比迁移路径。
数据来源主要是 Beam.ai 的生产案例库，以及公开可查的 Microsoft、Gartner、Princeton NLP 报告。我们拆解六种主流编排模式，给出每种的「什么时候用」和「在什么条件下炸」。
评测维度说明
我们在评测每种模式时使用了三个维度：
- 失效边界：在什么条件下这个模式会失败，这是最难找到的数据
- 成本结构：多 Agent 带来的 token 消耗和延迟开销
- 迁移路径：如果你已经在用另一种模式，迁移到这种模式需要什么
模式一：Orchestrator-Worker，最常用也最危险
结构描述
单个协调 Agent 接收任务，拆解为子任务，分配给专门的 Worker Agent，最后汇总结果。Coordinator 通常用能力强的模型，Worker 用便宜的模型。
典型案例
Wells Fargo 用这个模式让 35,000 名银行柜员在 30 秒内访问 1,700 个流程文件——之前需要 10 分钟。Salesforce Agentforce 2.0 的 Atlas Reasoning Engine 也是这个架构。
失效边界：两个场景会炸
第一个：任务分类错误率随规模复合
Orchestrator 承担了分类和路由的责任。如果任务被错误分类，错误会一直传递到对应的 Worker，且没有任何回退机制。在高并发场景下，错误分类率会随请求量增加而升高，因为模型面对的输入分布会变化。
第二个：上下文窗口溢出是隐藏的成本杀手
这是最多团队忽视的问题。Orchestrator 积累了所有 Worker 的中间结果作为上下文。Worker 越多，累积上下文越长。四轮以上的 Worker 协作，上下文字符数经常超过模型窗口限制。
实际成本差距有多大？测试环境下一次完整流程成本 $0.50，但当系统规模达到每月 10 万次执行，因为 Orchestrator 每次都要对每个 Worker 的结果做二次分解和聚合，月成本可能达到 $50,000。
迁移路径
如果你的系统目前是单体 Agent，想迁移到 Orchestrator-Worker，核心工作有三步：
- 识别稳定子任务集：先手工拆解业务流程，明确哪些子任务是固定的、可复用的
- 先引入 Worker，不动 Coordinator：用新模型充当 Worker，保持原 Agent 作为 Coordinator
- 评估错误分类的业务损失：对每个子任务做 A/B 测试，计算错误路由的真实成本，再决定是否升级 Coordinator 模型
我的判断
Orchestrator-Worker 适合「任务结构固定但需要跨专业知识」的场景。客服 routing、文档处理流水线是典型适用场景。但它不适合「任务边界模糊、探索式执行」的场景——那会触发第二种失效边界。
模式二：Sequential Pipeline，线性链式但容易被过度使用
结构描述
多个 Agent 按预定义的线性顺序执行，每个 Agent 处理前一个 Agent 的输出，通过共享状态传递数据。执行顺序在设计时确定，不随运行时变化。
典型案例
Microsoft Azure Architecture Center 记录过一间律所的合同生成流程：模板选择 → 条款定制 → 合规审查 → 风险评估，每个阶段由不同的 AI Agent 处理。
失效边界：级联错误比性能问题更致命
Pipeline 模式最怕的是第一阶段出错。一旦第一个 Agent 的输出有误，这个错误会毫无阻拦地传递到之后的每一个阶段。更糟的是：没有回退机制，错误只会累积。
容易被忽视的问题是开销。四阶段的 Pipeline 累积协调开销约 950ms，而实际处理只需要 500ms。三阶段的 Pipeline 消耗 29,000 token，而等价的单 Agent 方案只需要 10,000 token。如果你的 Pipeline 没有充分利用每个阶段的专门能力，你实际上在为一个没有收益的设计多付 3 倍成本。
迁移路径
从单体 Agent 迁移到 Pipeline，通常是业务需要合规性审查或分工审计的场景：
- 先固定顺序：不要上来就用动态路由，先把业务流程的阶段顺序手工定义清楚
- 用代理 Agent 做状态传递：不要让 Agent 之间直接传递上下文，用中间存储（文件或数据库）作为共享状态
- 每阶段加校验：在每个阶段出口加一个轻量校验 Agent，发现异常及时中断而不是传递下去
我的判断
Pipeline 模式本身没问题，问题在于太多团队在不需要分工的时候强行 Pipeline。如果你只有两个阶段，而且第二阶段的输入完全依赖第一阶段——这种情况下用 Pipeline 是杀鸡用牛刀。单 Agent 加 few-shot examples 可能是更优解。
模式三：Fan-out/Fan-in，并行化收益最高但风险最难控
结构描述
多个 Agent 同时处理同一个输入的不同方面或独立子任务，一个调度 Agent 分发任务，一个聚合 Agent 汇总结果（通过投票、加权合并或 LLM 合成）。
典型案例
多视角金融分析（基本面、技术面、情绪面、ESG 同时跑）、代码安全+风格+性能并发审查。
失效边界：三个维度同时出问题
API 速率限制：并发 Agent 共享 API 限额。15 个并发 Agent 各自消耗 150 req/s，当你的总限额是 100 req/s 时，每个 Agent 单独看都没超，但集体直接击穿上限。
共享状态的竞态条件：N 个 Agent 潜在并发交互数为 N(N-1)/2。5 个 Agent 是 10 个潜在冲突，10 个 Agent 是 45 个。这不是线性增长，是平方级增长。
聚合步骤本身的误差：LLM 合成可能在底层 Agent 存在分歧时产生幻觉共识。比如基本面 Agent 说”卖出”，情绪面 Agent 说”买入”，LLM 聚合可能给出一个不存在的”市场情绪中性”结论。如果你的并行 Agent 会产生对立结论，你必须设计显式的冲突解决策略，而不是依赖”让 LLM 总结一下”。
迁移路径
从 Pipeline 或单体迁移到 Fan-out/Fan-in：
- 先做任务独立性分析：识别哪些子任务真正没有依赖关系，只有独立任务才适合并行
- 建立 Token 预算：并发 Agent 数 × 单 Agent Token 消耗 = 总并发消耗，在设计阶段就算清楚
- 设计冲突解决策略：先定义”当 Agent A 和 Agent B 结论冲突时，谁说了算”
我的判断
Fan-out/Fan-in 是六种模式中收益上限最高的：理论上能将耗时减少 75%。但它也是六种模式中工程实现最复杂的——需要处理并发控制、冲突解决、速率限制三个工程问题。如果你的团队没有成熟的并发编程经验，建议先在一个低风险业务场景做灰度验证。
模式四：Multi-Agent Debate，治幻觉最有效但治不了谄媚
结构描述
多个 Agent 在共享对话中各持己见，相互质疑，迭代修正立场。包含 Maker-Checker 循环：一个 Agent 生成内容，另一个 Agent 审核直到通过。
典型案例
合规审查、质量保证场景。研究表明多 Agent 辩论相比单模型查询能显著减少幻觉。
一个实用的变体：用便宜快速的模型做 Maker，用能力强的模型做 Checker。这样能获得辩论的质量提升，同时比两个都用强模型节省 40-60% 的成本。
失效边界：两种级联失效
对话循环：Agent 持续辩论但不收敛。Microsoft 建议将群聊参与 Agent 数量限制在三个以内，因为每增加一个 Agent，交互复杂度呈指数增长。
谄媚级联（Sycophancy Cascading）比对话循环更难解决。Agent 倾向于同意多数意见，即使多数是错的。5 轮 × 3 Agent = 15 次 LLM 调用，结果可能因为 Agent 们相互强化了错误答案而变得「自信地错误」。
迁移路径
从单体或有监督的单 Agent 审查迁移到 Debate：
- 从 Maker-Checker 二元结构起步：不要一上来就做多 Agent 群聊，从一个生成、一个审核开始
- 设定辩论轮数上限：超过上限强制收敛（取第一个 Agent 的结论或外部仲裁），防止无限循环
- 监控一致性而非质量：Debate 的输出质量需要事后对比验证，但如果三个 Agent 快速达成共识，你要警觉——这可能是谄媚级联的信号
我的判断
Multi-Agent Debate 是治幻觉最有效的模式，但它的适用范围被高估了。它只在「质量>速度」且「多视角确实有益」的强合规场景有优势。日常的问答、文档生成、内容创作不值得为此付出 3 倍延迟和 5 倍 token 消耗。
模式五：Dynamic Handoff，没有中央协调但有无限循环风险
结构描述
每个 Agent 评估当前任务，决定是自己处理还是转移给更合适的专家 Agent。与 Orchestrator-Worker 不同：没有中央协调器，Agent 之间相互转交控制权。只有一个 Agent 在任意时刻活跃。
典型案例
客服场景中，计费问题在对话过程中暴露为技术问题——这类边界模糊、无法预判专家的场景。
HCLTech 报告用这个模式将案件解决速度提升 40%。
失效边界：两种循环是命门
无限转交循环：Agent A 转给 B，B 转给 C，C 再转回 A。无限循环是排名第一的失败模式。每个 Agent 持续重新规划，因为没有一个 Agent 对任务拥有最终所有权。
上下文丢失随转交累积：要么传递完整上下文（昂贵，最终超过窗口限制），要么做摘要（有损的，累积摘要错误会持续降低质量）。由于路由是非确定性的，相同输入可能产生完全不同的 Agent 调用链，这让调试几乎不可能。
迁移路径
从 Orchestrator-Worker 迁移到 Dynamic Handoff：
- 先定义 Agent 能力边界：如果 Agent 不知道自己擅长什么，Handoff 就成了随机游走
- 建立转交黑名单：禁止某些 Agent 之间的直接转交，避免循环
- 引入任务所有权跟踪：每次 Handoff 记录原始任务发起者，确保最后有唯一责任方
我的判断
Dynamic Handoff 是六种模式里最有未来感、但当前工程成熟度最低的。HCLTech 的案例发生在高度专业化的客服场景，普通业务场景很难复制。如果你想尝试这个模式，建议从有明确专家边界、且任务量可控的垂直场景开始，而不是上来就做全业务覆盖。
模式六：Adaptive Planning，探索型任务的最优解
结构描述
Manager Agent 动态构建、细化、执行任务计划，通过咨询专家 Agent 发现计划本身。与 Orchestrator-Worker 的关键区别：计划是发现的，不是预设的。Manager 会迭代、回退、按需委托，并持续检查目标是否达成。
典型案例
Microsoft 记录过一个 SRE 场景：Manager 创建初始计划，咨询诊断 Agent 和基础设施 Agent，当诊断发现问题是数据库而非部署时，整个计划实时转向。
失效边界：慢收敛和目标漂移
慢收敛：这个模式优先保证正确性而非速度。对时间敏感的任务是灾难——在 Manager 迭代的时候，用户已经等不及了。
目标漂移（Goal Drift）是生产环境的头号杀手。经过多次迭代，Manager 精化的计划可能与原始意图显著偏离。回退更糟：当 Manager 发现死路，之前的工作全部浪费，而且这个成本无法提前预测。如果原始请求本身就模糊（比如”帮我优化这个系统”），Manager 可能无限循环，试图构建一个满足模糊目标的「完整」计划。
迁移路径
从 Sequential Pipeline 迁移到 Adaptive Planning：
- 先识别不可预测的步骤：在 Pipeline 中找到那些”依赖前一步输出才能决定”的步骤，这些步骤才是 Adaptive Planning 的真正目标
- 设定计划长度上限：防止 Manager 无限细化计划
- 建立原始目标锚点：每次迭代后检查当前状态与原始目标的偏差，超过阈值强制终止并返回原始结果
我的判断
Adaptive Planning 是 Open-ended 问题的答案，但也是成本最不可预测的模式。对于有明确成功标准、明确结束条件的任务，这个模式带来的计划灵活性是多余的。大部分团队在探索这个模式之前，应该先问自己：我的任务真的需要”计划发现”吗？
六种模式的横向对比
| 维度 | Orchestrator-Worker | Sequential Pipeline | Fan-out/Fan-in | Multi-Agent Debate | Dynamic Handoff | Adaptive Planning |
|---|---|---|---|---|---|---|
| 适用复杂度 | 中 | 低-中 | 高 | 中-高 | 高 | 极高 |
| 失效风险 | 上下文溢出 | 级联错误 | 竞态+聚合 | 谄媚级联 | 无限循环 | 目标漂移 |
| 延迟开销 | 中 | 低 | 低-中 | 高 | 中 | 高 |
| Token 消耗 | 高（随 Worker 数增长） | 中 | 中-高 | 高 | 中 | 不可预测 |
| 工程复杂度 | 低 | 低 | 高 | 中 | 高 | 极高 |
| 调试难度 | 低-中 | 低 | 高 | 中 | 极高 | 极高 |
决策流程图：什么场景选什么模式
问自己第一个问题：任务结构在设计时已知吗？
- 如果是 → Orchestrator-Worker
- 如果否 → 进入下一个问题
第二个问题：任务步骤是线性依赖吗？
- 如果是 → Sequential Pipeline（但优先考虑单 Agent + few-shot）
- 如果否 → 进入下一个问题
第三个问题：子任务之间相互独立吗？
- 如果是 → Fan-out/Fan-in（需处理并发控制）
- 如果否 → 进入下一个问题
第四个问题：质量比速度重要吗？
- 如果是 → Multi-Agent Debate（Maker-Checker 起步）
- 如果否 → 进入下一个问题
第五个问题：专家类型无法在设计时预判吗？
- 如果是 → Dynamic Handoff（需防循环机制）
- 如果否 → 进入下一个问题
第六个问题：任务边界和成功标准都模糊吗？
- 如果是 → Adaptive Planning（需设计划上限和目标锚点）
- 如果否 → 单 Agent 可能是最优解
Princeton NLP 的反向结论：单 Agent 赢面 64%
这是我们觉得最值得单独拿出来说的数据。
Princeton NLP 的研究对比了单 Agent 和多 Agent 系统在同等工具和上下文条件下的表现：单 Agent 在 64% 的任务中与多 Agent 系统持平或更优，多 Agent 仅带来 2.1 个百分点的准确率提升，但成本大约翻倍。
这意味着：如果你为了「多 Agent 而多 Agent」，你大概率在白花 Token。
选型建议：我的判断
新手团队：从 Orchestrator-Worker 起步，工程成本最低，失效模式最可预测。先把一个 Worker 跑稳再加更多 Worker。
已有单 Agent 系统：先做任务分析，用 A/B 测试验证多 Agent 的增量价值，再决定是否迁移。不要因为「大家都用多 Agent」就迁移。
合规/质量优先场景：Multi-Agent Debate 的 Maker-Checker 变体是当前投入产出比最优的方案，2 个 Agent，成本省 40-60%。
Fan-out/Fan-in：不要用在 4 个以下子任务的场景，并发开销得不偿失。适合需要 75% 时间节省且团队有并发编程经验的场景。
Dynamic Handoff 和 Adaptive Planning：当前生态成熟度低，适合专项研究而非生产主力。如果你在探索 Agentic AI 的边界，它们是值得投入的方向。
结语
多 Agent 编排没有银弹。最好的编排模式是匹配你实际问题的那一个，不是你能构建的最复杂的那一个。
在选下一个 Agent 架构之前，先回答这六个问题——这可能是你今天最重要的 Agent 工作。