Multi-Agent vs Single-Agent
一、最新研究进展
Google DeepMind 联合 MIT，做了一件业界期待已久的事：用 180 组控制实验，定量回答”多 Agent 到底比单 Agent 强多少”。
论文叫《Towards a Science of Scaling Agent Systems》（arXiv: 2512.08296），跨 3 个模型家族（OpenAI、Google、Anthropic）、5 种架构、4 个基准任务。不是理论推导，不是案例论证，这是真金白银烧 token 跑出来的实验数据。
结论一句话：
“More Agents Is NOT All You Need.”
更多的 Agent 不等于更好的结果。在大多数场景下，多 Agent 系统的表现不仅没有显著优于单 Agent，反而因为协调开销而更差。
二、论文里的六个关键数字
这篇论文最大的价值不是观点，是数据。以下是六个关键定量发现，每一个都直接对应我们日常使用中的某种”体感”：
1：工具协调惩罚系数 = -0.330
在论文的 20 参数回归模型中，工具 - 协调交互项是最大的负因子。
翻译成人话：你给多 Agent 系统配的工具越多，协调损耗越大，性能下降越严重。当工具超过 15 个时，多 Agent 相比单 Agent 会产生 ****2-6 倍****的效率惩罚。
这解释了为什么那些号称”注册 60+ 工具”的编排框架，实际效果往往令人失望——不是工具不好，是协调这些工具的成本把收益吃掉了。
2：能力饱和阈值 ≈ 45%
当单 Agent 在目标任务上的基线准确率超过约 45% 时，引入多 Agent 协作的边际收益趋近于零甚至为负。
45% 是一条分水岭。 2025 年主流大模型在代码生成、文本分析等常见任务上的基线能力早已远超这个阈值。这意味着，对你日常使用的大多数任务来说，加 Agent 不会让结果更好，只会让账单更贵。
3：错误放大率——独立并行 17.2 倍，中心化 4.4 倍
没有验证瓶颈的独立并行 Agent，不仅不能互相纠错，反而会把单个 Agent 的错误假设无限传播，错误率被放大 17.2 倍。
即便引入一个”总管”做中心化编排（这已经是最常见的 multi-agent 架构了），错误放大也只能控制到 4.4 倍。
你以为多找几个人商量就能降低犯错率？在 AI Agent 的世界里恰恰相反——一个人犯的错，传给三个人，变成三种不同的错。
4：推理轮次公式 T = 2.72 × (n+0.5)^1.724
这是论文中我最喜欢的一个发现。Agent 之间的推理协调轮次随 Agent 数量超线性增长——指数是 1.724，远大于 1。
实际含义：
| Agent 数量 | 相对协调成本 |
|---|---|
| 1 | 1x（基线） |
| 2 | ~3.3x |
| 3 | ~6.5x |
| 4 | ~10.6x |
| 5 | ~15.7x |
从 1 到 3 个 Agent，协调成本已经翻了 6 倍多。从 3 到 5 个，再翻一倍。超过 3-4 个 Agent 就是成本爆炸的拐点。 这就是为什么我在实践中发现，大多数有效的 Agent 配置都不超过 3 个——不是因为设计不出更多角色，而是物理规律决定了你加不起。
5：消息密度饱和 ≈ 5 条/轮
Agent 之间每轮沟通超过约 5 条消息后，新增的信息就全是冗余，不产生任何有效信息增益。
说白了：AI Agent 之间的沟通效率有天花板。不是聊得越多越好，超过一定量就是在烧 token 说废话。这和你在微信群里 @ 了十个人讨论需求、最后发现不如直接找一个人说清楚，是完全一样的道理。
6：模型智力的收益是二次方增长
回归模型中，单 Agent 智力的二次项系数为 +0.087。
含义：投资让一个模型变强的回报，是加速增长的。 与其把预算花在多搞几个 Agent 上，不如花在用更好的模型、写更好的 prompt、做更好的上下文管理上——边际回报更高。
三、不只是论文——工业界也在”回归极简”
上面介绍了学术观点，接下来谈谈工业界的实践，做出顶级 AI Agent 产品的两家公司，几乎在同一时期表达了高度一致的立场。
Cognition（Devin 团队）：别搞 Multi-Agent
Devin 是目前公认最强的 AI 编程 Agent 之一。其 CPO Walden Yan 在 2025 年 6 月发了一篇博文，标题就是 《Don’t Build Multi-Agents》。
核心观点只有两条：
- 必须共享完整上下文，而非压缩摘要。 你把一个任务拆给两个子 Agent，每个都只拿到一条指令而不是完整的推理过程，信息衰减不可避免——他们叫它”传声筒效应”。
- 每个动作都携带隐式决策，并行 Agent 的隐式决策必然冲突。 Agent A 选了 A 风格的 API 命名，Agent B 选了 B 风格的——两个人都”没错”，但合在一起就不能用。
Cognition 自己怎么做的？单线程线性 Agent + 上下文压缩模型。 超长任务不拆agent，拆上下文——专门训了一个小模型做历史记录压缩，保留关键决策，丢掉冗余细节。
还有一个关键细节：Claude Code 的subagent 只被允许做只读查询，从不被允许写代码。为什么？因为子 subagent 没有主 Agent 的完整上下文，让它做决策就是让一个只听了会议纪要的人去写代码。
Anthropic（Claude 团队）：从简单开始，只在必要时加复杂度
Anthropic 官方指南《Building Effective Agents》的第一句话就是：
“最成功的实现是使用简单、可组合的模式，而非复杂框架。”
他们给出了一个渐进式复杂度阶梯——从增强型单 LLM 到 Prompt 链、路由、并行化、编排器 - 工人……一共 7 层。核心理念是：只在上一层不够用时，才爬下一层。
更犀利的是他们对框架的态度：”框架创造了额外的抽象层，使调试更困难，并且诱使人在简单方案就够用时增加复杂度。”——建议开发者先直接调 API，别一上来就套框架。
这和我之前在拆解 Ruflo 时的结论完全吻合：一个仓库超 110 万行、每轮额外消耗 6000-9000 tokens 的编排层，对大多数中短任务来说，你还没开始干活，token 预算已经被系统本身吃了一大块。
四、那什么时候 Multi-Agent 真的有用？
说了这么多”不该用”，必须说清楚”什么时候该用”。DeepMind 的论文在这一点上最有价值——它没有简单站队，而是给出了分场景的定量结论：
| 任务类型 | Multi-Agent 的表现 | 结论 |
|---|---|---|
| 金融分析（高度可并行） | 中心化 MAS +57% ~ +127.5% | 有效，值得用 |
| Web 浏览搜索（动态探索） | 去中心化 MAS +9.2% | 微弱正收益 |
| 规划类任务（强顺序依赖） | 所有 MAS 架构 -39% ~ -70% | 严重劣化，别碰 |
| 工具密集型任务（确定性执行） | 收益可忽略不计 | 白花钱 |
看出规律了吗？Multi-Agent 的价值取决于任务是否”天然可并行”且”不需要全局一致的决策链”。
金融分析为什么有效？因为”分析美股”和”分析港股”之间几乎没有信息依赖，天然可以独立做。规划类任务为什么灾难？因为第三步依赖第二步的决策，第二步依赖第一步——你让三个人各想各的，拼出来的方案必然矛盾。
另外还有两篇论文提供了更锐利的视角：
《When Single-Agent with Skills Replace Multi-Agent Systems》 发现，对于串行通信特征的多 Agent 系统，可以直接”编译”为带技能库的单 Agent——减少 53.7% token 消耗、49.5% 延迟，准确率持平甚至更高。多 Agent 的能力并不是不能实现，只是不需要通过多个”人”来实现。
《Understanding Agent Scaling via Diversity》 发现，如果你非要用 Multi-Agent，2 个异构 Agent（不同模型/不同工具集）就能打 16 个同质化 Agent。堆人数没用，堆多样性才有用。
五、如何决策？
基于以上所有信源，我提炼了一个极简决策框架：
六、说回体感——为什么极简才是正道
奥卡姆剃刀的精髓、决策树剪枝和 Dropout 的哲学含义：如无必要，勿增实体！
回到开头。我的体感是：只使用必要的。 不是因为懒，而是经历了一个完整的从入门到祛魅的周期。
装了一堆 SKILL、AGENT？好多只在 demo 里好看，日常任务里可能一周也用不到一次，还额外占 context。配了花式 Persona？模型 follow 你写的一长串”你是一个资深 XX 架构师”的概率越来越低，不如把同样的精力花在写清楚任务描述上。搞了多 Agent 编排？每轮 6000+ token 的固定开销，短任务根本回不了本。
现在发现，这不是个人偏好，这是物理规律：
- 协调成本超线性增长（指数 1.724）
- 工具越多惩罚越大（系数 -0.330）
- 模型够强就不需要帮手（45% 阈值）
- 提升单模型的回报是加速的（二次方增长）
OK，结论很明显：
AI Agent 工程的核心竞争力不是架构拓扑，而是上下文工程（当然，现在更流行的说法是 Harness Engineering）——确保每一次模型调用都拥有做出正确决策所需的全部相关信息。
Cognition 的 CPO 把它定义为”Agent 工程师的第一职责”。Anthropic 通过工具设计和渐进式模式体现这一理念。DeepMind 的回归模型给出了量化证据。
模型本身的智力不是瓶颈。让模型在每次调用时”看到”足够完整、足够相关的上下文，才是瓶颈。 把精力花在这里，比折腾架构拓扑有效得多。
PS：这个结论只保鲜半年，半年后 AGI 初见端倪后就是另外一种情形了。