多Agent协作翻车指南：四种编排模式，只有一种能上生产

去年大家都在做”一个 Agent”。今年很多团队开始做”一群 Agent”。

结果也很一致：Demo 惊艳，上生产就崩。原因不是模型不行，而是编排模式选错了。

一、四种模式，先看清楚

模式 A：Supervisor（主管调度）

一个主 Agent 负责拆任务、分派、汇总，子 Agent 各管一摊。

用户 → Supervisor → [检索Agent | 计算Agent | 报告Agent] → Supervisor → 用户

优点：逻辑集中，好调试，任务边界清晰。 代价：Supervisor 的上下文会膨胀，它必须”记得”每个子 Agent 做了什么。 适用：任务可明确定义、子任务独立性强的场景，比如”查资料 + 算数据 + 写报告”。

模式 B：流水线（Pipeline）

固定顺序，A 的输出是 B 的输入，没有回头路。

抽取 → 校验 → 格式化 → 入库

优点：最便宜、最稳定、最容易监控。每一步都能单独跑测试。 代价：不能处理”需要回头补信息”的任务。 适用：文档处理、数据清洗、批量化内容生成。这是最容易上生产的模式，也是被低估最多的。

模式 C：辩论（Debate）

两个或多个 Agent 互相批评，最后收敛。

优点：能显著降低事实错误，对开放式分析有效。 代价：token 成本是单 Agent 的 3–6 倍，而且不保证收敛。曾经见过两个 Agent 互相说对方错，跑了 40 轮。 适用：高价值的决策分析，且必须加上轮次上限和仲裁者。

模式 D：群体（Swarm / 自由交接）

Agent 之间自由转交任务，没有中心。

优点：灵活。 代价：不可预测、不可复现、不可审计。生产环境里基本是灾难。 适用：研究原型，以及少数人工全程监督的场景。

二、真实成本对比

以一个”竞品调研报告”任务为例（同一模型、同样输入）：

模式	调用次数	平均耗时	失败率	可复现性
单 Agent	4	45s	8%	高
流水线	6	70s	5%	高
Supervisor	12	130s	18%	中
辩论	26	300s	31%	低
群体	30+	不稳定	50%+	无

注意流水线的失败率反而比单 Agent 低——因为每一步都能做校验和重试。这就是工程化的价值。

三、选型的三个判断问题

1. 子任务之间需要”来回沟通”吗？

不需要 → 用流水线。需要，但方向固定 → Supervisor。需要双向反复 → 才考虑辩论。

2. 你能给每个 Agent 写出一句准确的职责描述吗？

写不出来，说明任务还没拆清楚。任务没拆清楚就上多 Agent，只会把混乱放大。

3. 出错了能定位到哪一层吗？

生产系统必须有 trace。每个 Agent 的输入、输出、耗时、token 数都要记录。如果定位不了，先补可观测性再说编排。

四、上生产的四个硬约束

1. 全局步数上限 每个 Agent 有最大步数，整个编排有总步数上限。没有上限的系统一定会失控烧钱。

2. 交接必须结构化 Agent 之间传的不是自然语言，而是带 schema 的 JSON。自然语言交接是多 Agent 系统最大的 bug 来源。

3. 状态外置 把共享状态存在数据库/文件里，而不是塞在某个 Agent 的上下文里。上下文会丢，数据库不会。

4. 降级路径 Supervisor 挂掉时能不能退化成单 Agent？辩论超时时能不能直接返回第一个答案？没有降级路径的系统不叫生产系统。

五、把评估体系一起设计好

多 Agent 系统最容易被忽略的，是评估粒度。单 Agent 可以端到端打分，多 Agent 必须分层看：

• 端到端指标：任务成功率、总耗时、总 token 成本。这是老板看的。
• 单节点指标：每个 Agent 的输入是否完整、输出是否符合 schema、重试次数。这是工程师看的。
• 交接指标：A 交给 B 的信息有多少被 B 真的用上了？如果 B 几乎不用 A 的产物，说明交接设计有问题，或者这个环节根本多余。

最后一条特别有效。我们曾用这个方法砍掉了一个 Supervisor 系统里两个”看起来专业、实际没产出”的子 Agent，成本直接降了四成，效果反而更好。

判断一个 Agent 该不该存在的标准：把它删掉，系统会变差吗？如果不会，它就是在消耗预算。

六、我的建议

从流水线开始。真的。

大多数团队以为自己的任务需要多 Agent，实际上只是没把流程拆清楚。先把单条流水线跑通、测好、监控上，再考虑加 Supervisor。

多 Agent 的价值不在”更聪明”，而在”分工让每个环节更可控”。如果分工没让可控性上升，那就是纯粹的复杂度税。