# 四成五即反噬：多智能体加成阈值深拆 ## 概述 一个被反复验证却仍被忽视的结论正在重塑多智能体（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 年起，三份互相印证的数据接连把这张幻灯片打穿： - **arXiv:2503.13657《Why Do Multi-Agent LLM Systems Fail?》** 发现，多智能体在流行基准上的"增益"大多经不起对照，生产中失败率落在 **41%~86%** 区间。 - **arXiv:2512.08296（180 组态实测）** 给出第一条定量缩放律：当单智能体基线准确率跨过约 **45%** 后，多智能体协调的边际收益由正转负，并随基线继续升高而加速恶化。 - **Anthropic 工程日志** 同时指出，他们自家的 Research 系统只在编排者下挂 **3~5** 个子智能体，且对外明确：超过这个数，回报骤降而 token 与延迟线性甚至超线性膨胀。 这三条共同指向一个反直觉的事实：**多智能体不是"复杂度越高越该用"，而是"单智能体越搞不定越该用"。** 决定要不要拆分的，不是任务看起来多复杂，而是单智能体在这件事上还差多远。 ## 二、对比表：子智能体数量 × 四档基线，加成还是反噬 下面这张表把"加 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，可能让一个原本加分的多智能体设计瞬间变成扣分**——这正是"换模型即重写"那条税在多智能体层面的投影。 ## 三、深度拆解：反噬的三层机制 ### 3.1 复合误差——多跳即放大，17 倍错误陷阱的数学骨架 单智能体每一步的失误，被它自己的上下文连续修正；多智能体的失误，则被交接（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 看得到全貌。 ### 3.2 协调开销——orchestrator 本身就在烧钱烧延迟 协调不是免费的。每多一个子智能体，编排者要额外做三件事：把任务再拆一份、把拆出的结果再合一次、对结果做一次可信度裁决。这三件事都要喂给同一个最贵的模型（orchestrator 通常用顶配模型）。于是出现一个违反直觉的成本结构：**10 个子智能体的系统，token 花得最多的不是这 10 个 worker，而是那个不停拆-合-判的 orchestrator。** 生产 FinOps 数据印证了这一点：一个 planner-executor-reviewer 的三段流水线，跑一次复杂任务常烧 **40 万~80 万 token**；10 agent 的生产系统月费落在 **$3,200~$13,000**；agentic 工作负载相对纯聊天的 token 放大倍数是 **10~100×**。协调开销把"多智能体更省心"的叙事彻底掀翻——它恰恰是最烧钱的设计。 ### 3.3 上下文碎片化——分解即丢全局，再难拼回 子智能体拿到的是被编排者裁切过的"片段上下文"。裁切本身就是一次信息有损压缩：编排者必须先读懂全局，再用更短的 prompt 转述给 worker，worker 再基于这个二手转述干活。两次转述之间，全局约束、隐性偏好、跨子任务的耦合关系被系统性丢失。 后果是"局部最优、全局次优"。每个子 agent 都把自己那一段做得很好，合起来却互相打架：文档 agent 写的口径和代码 agent 实现的接口对不上，理由是没有任何一个 agent 同时见过两者。Anthropic 在工程日志里反复强调 context isolation 是双刃剑——它让 worker 不被噪声淹没，但也让 worker 看不到自己决策的全局后果。**分得越细，每个 agent 越聪明地解决着一个错误的问题。** ## 四、Mermaid：能力饱和曲线与甜点带 下面的流程图把"要不要加 agent"的决策路径画成一条主干，关键岔路就是那条 45% 拐点。 ```mermaid flowchart TD A["新任务进来"] --> B["先用顶配单智能体跑
测基线准确率"] B --> C{"基线准确率
是否 > 45%?"} C -->|"否 (<45%)"| D["落点：能力未饱和区
多智能体有正加成"] C -->|"是 (>45%)"| E["落点：能力饱和区
多智能体反噬"] D --> F{"子任务能否天然并行
且耦合低?"} F -->|"是"| G["编排者-工人
3~5 个子智能体"] F -->|"否"| H["保留单智能体
用工具扩能而非加 agent"] E --> I["禁止横向加 agent
改投：更长上下文/更好工具/更细提示"] G --> J["设硬上限
超 5 个先证伪再扩"] H --> J I --> J J --> K["上线 + 观测
盯复合误差与 token 倍数"] ``` ## 五、甜点带为何是 3~5：Anthropic 编排者-工人模式的依据 Anthropic 的 Research 系统是多智能体"用对了"的范本：一个编排者 agent 先把研究问题拆成若干子问题，每个子问题派给一个带独立上下文的子智能体并行检索，最后编排者聚合。它在内部研究评测上比单 agent 的 Claude Opus 高出 **90.2%**——但请注意，这个数字成立的三个前提常被引用者省略： 1. **基线低**：开放式研究的单 agent 基线准确率天然偏低（信息散落、需要多跳），正处于"<45%"的能力未饱和区，多智能体才吃得到正加成。 2. **子智能体被钉死在 3~5 个**：超过 5 个，编排者的拆-合-判开销开始吃掉 worker 带来的信息增量。 3. **并行而非串行**：子智能体之间几乎不相互依赖，复合误差的 $k$ 次方效应被压平，只在编排者聚合处发生一次合并。 这三条缺一不可。许多团队照搬"编排者-工人"却把 3~5 放大到 10~15，或把并行改成串行流水线，于是 90.2% 的加成瞬间蒸发，只剩 token 账单。**甜点带不是一个数字，而是一组耦合条件。** ## 六、过度拆分的四种典型症状：自检清单 如果你的多智能体系统出现以下任一症状，大概率已经越过拐点、进入反噬区： - **token 倍数畸高**：单任务 token 是单智能体的 30 倍以上，质量却没明显提升——典型协调开销失控。 - **结果互相打架**：不同子 agent 的产出存在口径/接口/事实冲突，编排者疲于仲裁——典型上下文碎片化。 - **加 agent 不加质量**：从 5 个加到 10 个，评测分数持平甚至下降——已进入能力饱和区。 - **错误难溯源**：一次失败要翻 5 个 agent 的 trace 才定位根因——典型 17× 错误陷阱。 出现两条以上，正确的动作不是"再加一个 reviewer agent 来兜底"——那只会让 $k$ 继续涨、复合误差继续放大——而是**反向收缩**：砍掉冗余 agent，把省下的 token 投到更长上下文、更准的工具、更清晰的提示上。 ## 七、token 经济学：每个子智能体的"固定税" 把多智能体的成本拆开看，每个子智能体都背着三笔固定税，且互相叠加： - **上下文重建税**：每个 worker 都要被独立喂一遍任务背景、工具说明、格式约定。这部分是冗余的——同样的背景在 $k$ 个 agent 里被读 $k$ 遍。 - **交接税**：上游产出转成下游输入，编排者要做一次"翻译+摘要"，每次交接都过一次最贵模型。 - **仲裁税**：多份产出要裁决谁对、怎么合，裁决本身又是高难度推理，常顶配模型。 三税叠加，token 随 agent 数大致呈超线性增长。这意味着"用便宜模型多堆 agent"是个伪命题——worker 可以便宜，但 orchestrator 不能，而 orchestrator 的工作量随 worker 数线性涨。**多智能体的单位 token 性价比，几乎总是低于"单智能体 + 好工具"。** ## 八、推荐方案：四步阈值体检法 落到工程，把"加不加 agent"变成一道可计算的题。建议按以下四步走，顺序不可颠倒： 1. **测基线**：用你计划给 orchestrator 用的那个模型，单 agent 跑一遍任务，拿到基线准确率。这一步省不得——它是整条决策链的输入。 2. **判拐点**：基线 <45% → 进入多智能体候选区；基线 >45% → 直接走"单智能体 + 工具扩能"，禁止横向加 agent。 3. **定粒度**：候选区内，子智能体数从 3 起步，上限锁 5。每加一个，先证伪"它带来的信息增量 > 它引入的协调税"，证不出来就不加。 4. **盯信号**：上线后持续观测 token 倍数与复合误差率。token 倍数超 15× 或错误率随 agent 数上升，立刻回退一档。 一句话收口：**多智能体不是"复杂任务"的答案，而是"单智能体还差很远"的答案。** 先量基线，再决定要不要切；切，就切到 3~5；切完，盯紧那条随时可能反噬的拐点。 ## 参考来源 1. [Towards a science of scaling agent systems: When and why agent systems work — Google Research](https://research.google/blog/towards-a-science-of-scaling-agent-systems-when-and-why-agent-systems-work/) — 180 组态实测，首次给出能力饱和曲线与 ~45% 拐点（arXiv:2512.08296） 2. [Why Do Multi-Agent LLM Systems Fail? — arXiv:2503.13657](https://arxiv.org/abs/2503.13657) — 多智能体在流行基准上的增益失真，生产失败率 41%~86% 3. [How we built our multi-agent research system — Anthropic](https://www.anthropic.com/engineering/multi-agent-research-system) — 编排者-工人模式、3~5 子智能体甜点带、90.2% 加成的前提条件 4. [More AI agents isn't always better, new Google and MIT study finds — The Decoder](https://the-decoder.com/more-ai-agents-isnt-always-better-new-google-and-mit-study-finds/) — 对缩放律拐点的第三方解读，强调强基线下协调成本反超 5. [The Real Cost of Multi-Agent Orchestration in 2026 — KSPL Academy](https://academy.kspl.tech/blog/2026-05-31-multi-agent-orchestration-real-cost-2026) 与 [Multi-Agent Token Cost: Context Budget Accounting 2026](https://wowhow.cloud/blogs/context-budget-accounting-multi-agent-token-cost-2026) — 生产 token 与月费区间，三税叠加的成本结构 > [!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 等场景全覆盖。