一个被反复验证却仍被忽视的结论正在重塑多智能体（Multi-Agent）工程：当一个任务能被单智能体做到约45%以上正确率时，往系统里加更多 agent，得到的不是加成，而是反噬。 Google Research、DeepMind 与 MIT 联合在 2026 年 1 月发布的 180 组态实测（arXiv:2512.08296）首次给出了这条定量的"能力饱和曲线"——它把过去三年所有"多智能体翻车"的工程血泪，收束成一个可计算的拐点。本文以这条曲线为骨架，拆解反噬的三层机制（复合误差、协调开销、上下文碎片化），对照 Anthropic 编排者-工人模式里 3~5 个子智能体的甜点带，并给出一套四步阈值体检法，让你在动手切分任务前先算清账。
过去两年，多智能体几乎成了"复杂任务"的默认答案。理由听起来无懈可击：分工更细、并行更快、专精更深、还能互相校验。于是 practitioner 把一个研究任务切成 10 个 agent，把一个客服流程切成 8 个角色，把一个代码任务切成 planner / coder / reviewer / tester / critic 五段流水线，再叠一层 orchestrator。星标数和 agent 数一起涨，账单和报错也一起涨。
但 2025 年起，三份互相印证的数据接连把这张幻灯片打穿：
这三条共同指向一个反直觉的事实：多智能体不是"复杂度越高越该用"，而是"单智能体越搞不定越该用"。 决定要不要拆分的，不是任务看起来多复杂，而是单智能体在这件事上还差多远。
下面这张表把"加 agent"这件事拆成两个维度横向结算——单智能体基线准确率（横轴）和子智能体数量（纵轴），单元格给出质量变化、token 倍数、端到端延迟倍数、反噬风险四项实测倾向。数据综合自 180 组态缩放律、Anthropic 工程披露与多家生产 FinOps 记录的区间值。
| 子智能体数 | 单智能体基线 | 质量增益 | token 倍数 | 延迟倍数 | 反噬风险 |
|---|---|---|---|---|---|
| 1（不拆） | 任意 | 1.0× 基准 | 1× | 1× | 无 |
| 3~5（甜点带） | <45% | +15%~+30% | 8~15× | 3~5× | 低（正收益） |
| 3~5（甜点带） | >45% | −5%~−15% | 8~15× | 3~5× | 中高（已反噬） |
| 6~10（过度拆分） | <45% | +5%~+15% | 20~50× | 5~9× | 中（边际递减） |
| 6~10（过度拆分） | >45% | −15%~−30% | 20~50× | 5~9× | 极高 |
| >10（bag of agents） | 任意 | 多为负 | 50×↑ | 10×↑ | 极高（17× 错误陷阱） |
读这张表的关键是"对角线"。基线越低、agent 越少，越在绿色区；基线越高、agent 越多，越滑进红色区。同一条流水线，把基线模型从 Haiku 换成 Opus，可能让一个原本加分的多智能体设计瞬间变成扣分——这正是"换模型即重写"那条税在多智能体层面的投影。
单智能体每一步的失误，被它自己的上下文连续修正；多智能体的失误，则被交接（handoff）逐跳固化。若单个 agent 在子任务上的错误率为 $p$，且错误在下游被"信任并继续"，那么 $k$ 个串行 agent 全程正确的概率近似 $ (1-p)^k $。当 $p=0.15$、$k=5$ 时，链路正确率只剩 $(0.85)^5 \approx 44\%$——看起来每个 agent 都"还行"，整条链却已经掉到及格线以下。
更致命的是错误类型的扩散。单智能体错了，往往是局部错；多智能体错了，常常是"方向性错"——planner 把目标理解偏 5 度，coder 沿这 5 度写出整段代码，reviewer 拿着同一份偏掉的目标去审，反而给"正确实现错误目标"打了高分。这就是 towardsdatascience 所说的 17× 错误陷阱：bag-of-agents 架构下，定位一个根因错误的成本是单智能体的十几倍，因为错误被分散在 $k$ 个彼此隔离的上下文里，没有一个 agent 看得到全貌。
协调不是免费的。每多一个子智能体，编排者要额外做三件事：把任务再拆一份、把拆出的结果再合一次、对结果做一次可信度裁决。这三件事都要喂给同一个最贵的模型（orchestrator 通常用顶配模型）。于是出现一个违反直觉的成本结构：10 个子智能体的系统，token 花得最多的不是这 10 个 worker，而是那个不停拆-合-判的 orchestrator。
生产 FinOps 数据印证了这一点：一个 planner-executor-reviewer 的三段流水线，跑一次复杂任务常烧 40 万~80 万 token；10 agent 的生产系统月费落在 $3,200~$13,000；agentic 工作负载相对纯聊天的 token 放大倍数是 10~100×。协调开销把"多智能体更省心"的叙事彻底掀翻——它恰恰是最烧钱的设计。
子智能体拿到的是被编排者裁切过的"片段上下文"。裁切本身就是一次信息有损压缩：编排者必须先读懂全局，再用更短的 prompt 转述给 worker，worker 再基于这个二手转述干活。两次转述之间，全局约束、隐性偏好、跨子任务的耦合关系被系统性丢失。
后果是"局部最优、全局次优"。每个子 agent 都把自己那一段做得很好，合起来却互相打架：文档 agent 写的口径和代码 agent 实现的接口对不上，理由是没有任何一个 agent 同时见过两者。Anthropic 在工程日志里反复强调 context isolation 是双刃剑——它让 worker 不被噪声淹没，但也让 worker 看不到自己决策的全局后果。分得越细，每个 agent 越聪明地解决着一个错误的问题。
下面的流程图把"要不要加 agent"的决策路径画成一条主干，关键岔路就是那条 45% 拐点。
flowchart TD
A["新任务进来"] --> B["先用顶配单智能体跑<br/>测基线准确率"]
B --> C{"基线准确率<br/>是否 > 45%?"}
C -->|"否 (<45%)"| D["落点：能力未饱和区<br/>多智能体有正加成"]
C -->|"是 (>45%)"| E["落点：能力饱和区<br/>多智能体反噬"]
D --> F{"子任务能否天然并行<br/>且耦合低?"}
F -->|"是"| G["编排者-工人<br/>3~5 个子智能体"]
F -->|"否"| H["保留单智能体<br/>用工具扩能而非加 agent"]
E --> I["禁止横向加 agent<br/>改投：更长上下文/更好工具/更细提示"]
G --> J["设硬上限<br/>超 5 个先证伪再扩"]
H --> J
I --> J
J --> K["上线 + 观测<br/>盯复合误差与 token 倍数"]
Anthropic 的 Research 系统是多智能体"用对了"的范本：一个编排者 agent 先把研究问题拆成若干子问题，每个子问题派给一个带独立上下文的子智能体并行检索，最后编排者聚合。它在内部研究评测上比单 agent 的 Claude Opus 高出 90.2%——但请注意，这个数字成立的三个前提常被引用者省略：
这三条缺一不可。许多团队照搬"编排者-工人"却把 3~5 放大到 10~15，或把并行改成串行流水线，于是 90.2% 的加成瞬间蒸发，只剩 token 账单。甜点带不是一个数字，而是一组耦合条件。
如果你的多智能体系统出现以下任一症状，大概率已经越过拐点、进入反噬区：
出现两条以上，正确的动作不是"再加一个 reviewer agent 来兜底"——那只会让 $k$ 继续涨、复合误差继续放大——而是反向收缩：砍掉冗余 agent，把省下的 token 投到更长上下文、更准的工具、更清晰的提示上。
把多智能体的成本拆开看，每个子智能体都背着三笔固定税，且互相叠加：
三税叠加，token 随 agent 数大致呈超线性增长。这意味着"用便宜模型多堆 agent"是个伪命题——worker 可以便宜，但 orchestrator 不能，而 orchestrator 的工作量随 worker 数线性涨。多智能体的单位 token 性价比，几乎总是低于"单智能体 + 好工具"。
落到工程，把"加不加 agent"变成一道可计算的题。建议按以下四步走，顺序不可颠倒：
一句话收口：多智能体不是"复杂任务"的答案，而是"单智能体还差很远"的答案。 先量基线，再决定要不要切；切，就切到 3~5；切完，盯紧那条随时可能反噬的拐点。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。