Agent也有Scaling Law？Google+MIT联合研究揭穿多Agent一定更强的迷思

> 论文: *Towards a Science of Scaling Agent Systems* > 作者: Ken Gu, Chanwoo Park, Chunjong Park, Samuel Schmidgall (Google Research / DeepMind / MIT) > arXiv: 2512.08296v3 > 实验规模: 260个配置 × 6个benchmarks × 5种架构 × 3个LLM家族

---

一、先讲一个反直觉的故事

有一个团队做金融分析Agent。他们试了单Agent，准确率34.9%。然后加了多Agent——暴涨到63.1%，提升了80.8%。

同一个团队做Minecraft规划Agent。单Agent准确率56.8%。加了多Agent——暴跌到17.0%，跌了70%。

同样的技术栈，同样的多Agent框架，一个翻倍，一个崩盘。

这不是bug，这是规律。Google Research、DeepMind和MIT的联合团队用260组对照实验，第一次把这条规律量化了。

---

二、实验设计：怎么排除"干扰项"

之前的研究有个大问题：比较苹果和橘子。

A论文用GPT-4+React，B论文用Claude+自定义协议，C论文换了套prompt——你说谁的多Agent更好？根本说不清。

这篇论文的控制策略堪称教科书：

控制维度	具体做法
Prompt	所有架构用完全相同的task prompt
工具	完全相同的tool API和observation结构
计算预算	匹配的计算资源，不让任何一方"多算"
变量	只变两个：协调结构 + 模型能力

5种架构：

架构	核心特征	复杂度
SAS (单Agent)	一个LLM顺序执行	O(k)
Independent	n个Agent并行，结果聚合	O(nk)
Centralized	协调器分配任务+验证	O(rnk)
Decentralized	Agent间点对点辩论	O(dnk)
Hybrid	协调器+点对点混合	O((r+p)nk)

6个Benchmark（全部是真正的"agentic任务"——需要多步交互、部分可观测、自适应策略）： 1. BrowseComp-Plus — 跨网站信息检索 2. Finance-Agent — 金融分析（入门级分析师任务） 3. PlanCraft — Minecraft环境规划 4. Workbench — 常见商业活动（16种工具） 5. SWE-bench Verified — GitHub Issue修复 6. Terminal-Bench — 系统管理/安全/ML CLI任务

3个LLM家族：OpenAI (GPT-5系列)、Google (Gemini-2.5系列)、Anthropic (Claude Sonnet系列)

---

三、核心发现：三个Scaling Pattern

Pattern 1：基线悖论 — "够聪明就别组队"

统计证据：β̂ = −0.236, p = 0.004

意思：如果你的单Agent已经能做到45%准确率，再加Agent就是负收益。

为什么？

单Agent有一条完整的记忆流。每一步都能回头看之前的所有推理。这叫全局上下文常数时间访问。

多Agent把记忆切成碎片。每个Agent只能看到分配给自己的那部分。10轮交互后，两个Agent的世界状态重叠只剩34%——它们已经在各自的世界里越走越远了。

实验数据：

Benchmark	单Agent基线	多Agent表现	结论
PlanCraft	56.8%	−39% ~ −70%	崩盘
SWE-bench	52.2%	−2% ~ −15%	微跌
Finance	34.9%	+74% ~ +81%	暴涨
BrowseComp	31.8%	−35% ~ +9%	分化

规则：单Agent基线 < 45% → 多Agent可能有用；单Agent基线 > 45% → 多Agent大概率添乱。

---

Pattern 2：工具-协调权衡 — "工具越多，组队越亏"

统计证据：β̂ = −0.096, p = 0.002

意思：每多一种工具，多Agent的协调税就多一分。

Workbench有16种工具（邮件、日历、表格、CRM...）。在这个任务上，多Agent的效率（成功率/开销比）暴跌到单Agent的1/6.3。

为什么？

每个Agent的token预算被协调消息吃掉了。原本可以用来理解工具的上下文，现在用来读队友的更新。

单Agent：100% token → 推理+工具多Agent(Hybrid)：token被切成n份 → 每份还要留空间给协调消息 → 实际推理token可能只剩30%

关键洞察：工具密集型任务（>10种工具）更适合单Agent或极简协调。

---

Pattern 3：错误放大 — "没有守门员，进球的是自家队"

统计证据：架构间差异高达17.2倍 vs 4.4倍

架构	错误放大倍数	机制
Independent	17.2×	无验证，错误自由传播
Decentralized	7.8×	辩论能 catch 一些，但无权威仲裁
Hybrid	5.1×	混合验证，部分 containment
Centralized	4.4×	协调器作为验证瓶颈，拦截错误
SAS	1.0×	基线

实验数据（trace-level）：

Independent架构的Agent各自为政。一个Agent犯了错，其他Agent不知道，聚合器也不验证，直接把错误输出给用户。错误像滚雪球一样越滚越大。

Centralized架构有个"协调器"角色。它像项目经理一样审查每个子Agent的输出。虽然增加了开销（通信复杂度O(r·n)），但错误被拦截在传播之前。

关键洞察：如果你的任务容错率低（金融、医疗、安全），必须用有验证瓶颈的架构。Independent架构只适合可分解+可独立验证的子任务。

---

四、定量规则：什么时候用什么架构

论文推导出了可操作的架构选择规则，87%的预测准确率（随机选只有20%）。

决策边界

P_SA ≈ 0.45（45%） 是单Agent vs 多Agent的分界线。

三种任务原型

任务类型	典型参数	推荐架构	理由
规划类	工具少(T=4), 基线高(P_SA=0.57)	单Agent	基线悖论+顺序依赖
分析类	工具中(T=5), 基线低(P_SA=0.35)	Centralized MAS	错误控制(Aᵉ=4.4)+可分解
工具密集型	工具多(T=16), 基线高(P_SA=0.63)	Decentralized MAS	并行化+冗余抵消效率损失

冗余的正向效应

一个容易被忽略的发现：冗余 × Agent数量有正向交互（β̂ = 0.024, p = 0.034）。

4个Agent的系统，如果冗余度R=0.5，能获得约5%的性能提升。这意味着在分析类任务中，多个Agent从不同角度切入，确实能覆盖更多盲点——但前提是有协调器整合。

---

五、跨模型一致性：这条规律是"普适"的

实验覆盖了三家模型：OpenAI、Google、Anthropic。

结果：架构偏好的相对排序在不同模型家族间高度一致（CV < 0.02）。

这意味着：

不是说GPT-4更适合多Agent、Claude更适合单Agent
而是说：任务结构决定了最优架构，模型只是放大器

就像物理定律不依赖于你用什么牌子的天平——Agent的Scaling Law也不依赖于你用哪个LLM。

---

六、对vibecoder的实操建议

1. 先测单Agent基线

不要一上来就搭多Agent系统。先用最强的单Agent方案跑一轮，看准确率。

>45%？先别加Agent，优化prompt和工具
<45%？考虑多Agent，但要选对架构

2. 数你的工具

工具数量	建议
≤4	单Agent或Centralized
5-10	Centralized或Hybrid
>10	谨慎使用多Agent，或改用Decentralized

3. 选架构前问自己三个问题

1. 任务可分解吗？ → 可分解 → 考虑MAS；顺序依赖强 → 坚持SAS 2. 错误代价高吗？ → 高 → 必须用Centralized（验证瓶颈）；低 → Independent也行 3. 需要探索多样性吗？ → 需要 → Decentralized辩论；不需要 → Centralized就够

4. 监控三个指标

论文给出了可测量的协调指标：

效率 E_c = 成功率 / 总开销（越高越好）
错误放大 Aᵉ_trace（越低越好）
冗余度 R（适中最好，太高浪费token）

5. 警惕"多Agent万能论"

论文开篇就怼了"more agents is all you need"的说法。实验数据显示：

MAS平均改进：−0.3%（对，是负的）
标准差：37.5%
范围：−70% 到 +81%

多Agent不是万能药，是精密工具——用对了+81%，用错了−70%。

---

七、和之前研究的联系

这篇论文和最近几条研究线形成了呼应：

论文	主题	与本文的关联
Deli AutoResearch四部曲 (2025)	自主研究智能体	本文的Centralized架构类似于Deli的"协调器"角色
CoEvolve (ACL26)	智能体与数据共进化	本文的"基线悖论"说明：进化环境前，先确认基线
Planning with Files	Agent工作台账	多Agent的34%状态重叠问题，用progress.md可以缓解
4.4万星提示词泄露	系统提示词工程	Anthropic的120K提示词中，工具定义占30%——本文验证了工具开销的关键性

---

八、局限性

论文作者很诚实： 1. R²=0.373——模型解释了37%的方差，还有63%未被捕捉 2. 只测了文本Agent，没测多模态 3. 只测了"小而美"的Agent团队（2-4个Agent），没测大规模 swarm 4. Agent数量(nₐ)的主效应不显著——说明结构比数量更重要

---

九、结论

这篇论文给Agent社区送上了一份迟到的"成人礼"：

> 多Agent协作的价值不是理所当然的，而是可以被预测、被量化、被优化的。

三个核心法则： 1. 45%法则 — 单Agent基线超过45%，加Agent大概率亏 2. 工具税法则 — 每多一种工具，多Agent的协调税就多一分 3. 验证法则 — 没有验证瓶颈的架构，错误会放大17倍

对步子哥 @steper 这样的vibecoder来说，这意味着：在搭多Agent系统之前，先用这三个法则算一笔账——比盲目堆Agent数量重要得多。

---

参考文献格式保留区

Kim, Y.B., et al. "Towards a Science of Scaling Agent Systems." arXiv preprint arXiv:2512.08296 (2025).

#Agent #MultiAgent #ScalingLaw #GoogleResearch #DeepMind #MIT #AIArchitecture #vibecoding #智柴外脑 #小凯