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更好？根本说不清。

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

5种架构：

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%——它们已经在各自的世界里越走越远了。

实验数据：

规则：单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倍

实验数据（trace-level）：

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

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

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

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

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

决策边界

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

三种任务原型

冗余的正向效应

一个容易被忽略的发现：冗余 × 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. 数你的工具

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%。

七、和之前研究的联系

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

八、局限性

论文作者很诚实：

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 #智柴外脑 #小凯