本文永久链接 – https://tonybai.com/2026/08/02/google-agent-scaling-science-multi-agent-myth
大家好，我是Tony Bai。
【导读】
“更多智能体等于更好效果”，几乎是行业里心照不宣的共识。但谷歌一篇新论文用260组受控实验证明，这个共识只对了一半：多智能体在可并行任务上能带来最高81%的性能提升，却也可能在顺序任务上让效果暴跌70%。谷歌团队还给出了一个能提前判断“该不该上多智能体”的预测模型，准确率高达87%。
【文章要点】
从代码助手到私人健康顾问，AI智能体正在从“一次性问答”走向“持续多步骤交互”。但一个问题始终没有标准答案：一个任务，到底该交给一个足够强的智能体自己搞定，还是拆给一群智能体分工协作？
过去两年，“智能体越多越好”几乎成了行业默认答案。有论文报告过，LLM的表现会随着智能体数量增加而持续提升；也有研究发现，多智能体协作“往往能通过集体推理超越任何单一个体”。
但谷歌研究院联合麻省理工学院等机构在最新论文《Towards a Science of Scaling Agent Systems》中给出了不同的答案：多智能体系统的效果天花板，早就存在，而且这个天花板由任务本身的结构决定，跟你堆多少个智能体没有必然关系。
在动手做实验之前，谷歌团队先解决了一个容易被忽略的问题：市面上很多“智能体评测”，测的其实根本不是智能体能力，而是模型的静态知识水平。
研究团队给出了三条判断标准，一个任务只有同时满足下面三点，才算是真正的“智能体任务”：
像GSM8K数学题、MMLU知识问答这类“一次生成、立刻出答案”的静态基准，并不满足这些条件——用它们来评估多智能体协作的价值，得出的结论很可能是误导性的。
按照这套标准，研究团队最终选定了六个真正意义上的智能体基准：
为了排除“不同架构用了不同提示词、不同工具、不同算力预算”这种混杂因素，谷歌团队严格控制了所有变量：所有架构使用完全相同的任务提示、相同的工具接口、相同的计算预算，唯一改变的只有协调结构本身。
研究团队一共定义了五种典型架构：
在此基础上，研究团队把这五种架构，套用到OpenAI GPT、谷歌Gemini、Anthropic Claude三大模型家族的多个能力档位上，一共跑出了260组受控配置，覆盖六个真实智能体基准。这也是目前公开研究中，对“智能体架构效果”做得最系统的一次受控对比。
实验结果直接推翻了“智能体越多越好”的简单假设。
在可以拆解成并行子任务的场景里，比如财务分析——不同智能体可以同时分析营收趋势、成本结构、市场对比——中心化协调架构相比单智能体系统，性能提升了80.9%。任务被拆得越合理，多个智能体各自专注一块，整体效果反而比一个智能体“连轴转”要好得多。
但在需要严格按顺序推理的任务里，比如Minecraft环境下的规划任务，情况完全反转：论文测试的每一种多智能体架构，都让性能下降了39%到70%。原因也不复杂——协调本身要消耗“认知预算”，当任务的每一步都强依赖上一步的结果时，智能体之间互相沟通、对齐进度所花费的开销，反而挤占了本该用来推理的资源。
这就是论文提出的核心原则：架构要不要“加人”，不取决于任务难不难，而取决于任务能不能被拆解。这一条，恰恰是很多团队在设计智能体系统时最容易忽略的地方。
论文还发现了一个此前很少被量化讨论的现象——“工具-协调权衡”（tool-coordination trade-off）。
当一个任务需要调用的工具越多（比如一个需要接入16种以上工具的编码智能体），多智能体协调所带来的额外开销就会不成比例地上升。研究团队给出的解释是：多智能体系统本质上是把有限的token预算，切分给了多个智能体，当任务本身就需要大量token去处理复杂的工具编排时，协调开销会进一步压缩每个智能体可用的“思考空间”，效率损失也就随之被放大。
这意味着，工具越复杂的任务，往往越不适合简单粗暴地“拆给一群智能体各管一部分工具”，除非协调机制本身经过精心设计。
如果说前两个发现回答的是“效果好不好”，那么这一个发现回答的是一个更现实的问题：多智能体系统会不会“越帮越乱”？
研究团队专门测量了一个指标——错误放大率，即一个智能体犯的错，最终有多大概率被放大、传导到整个系统的最终结果里。
结果很直接：在没有协调者、各自并行工作的独立式架构中，错误被放大了17.2倍——因为没有任何机制去互相检查、互相纠正，一个小失误很容易一路传导到最终输出。 而在设有协调者的中心化架构中，这个放大倍数被压到了4.4倍。协调者在这里扮演的角色，相当于一道“验证关卡”，在错误汇总进最终结果之前，就有机会把它拦下来。
这个发现的意义超出了“性能优化”本身：对于要在真实业务中部署智能体系统的团队来说，选架构，某种程度上也是在选一套“容错机制”。同样的任务，选独立式还是中心化架构，容错能力可能相差好几倍。
前面三个发现，本质上都是“事后总结的规律”。谷歌团队更进一步，把这些规律做成了一个可以“事前预测”的工具。
研究团队用任务的可测量特征——比如工具数量、任务的可拆解程度——训练出了一个回归预测模型（交叉验证 R²=0.373，如果换用更贴合任务本身的能力评估指标，R²可提升到0.413）。这个模型能在完全没见过的任务配置上，正确预测出最优架构，准确率达到87%。
换句话说，开发者以后不再需要靠“试了再说”来决定用单智能体还是多智能体、用哪种多智能体架构，而是可以先看任务本身的两个关键属性——顺序依赖程度和工具密度——就能大致判断出该往哪个方向设计系统。
论文的结论其实指向了一个反直觉但更接地气的判断：随着谷歌Gemini这类基础模型持续变强，多智能体系统并不会因此变得不必要——恰恰相反，模型越强，多智能体协作能撬动的收益也越大，前提是架构选对了。
对于正在做智能体产品的团队，这篇论文提供的与其说是一套具体算法，不如说是一份决策清单：
从“多智能体是不是灵丹妙药”这种模糊的争论，到“具体什么任务该用什么架构”这种可以量化计算的工程问题——这或许才是这篇论文对整个行业最大的价值。
参考资料：
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
扫描下方二维码，开启你的AI原生开发之旅。
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。