本文永久链接 – https://tonybai.com/2026/08/02/google-agent-scaling-science-multi-agent-myth

大家好，我是Tony Bai。

【导读】

“更多智能体等于更好效果”，几乎是行业里心照不宣的共识。但谷歌一篇新论文用260组受控实验证明，这个共识只对了一半：多智能体在可并行任务上能带来最高81%的性能提升，却也可能在顺序任务上让效果暴跌70%。谷歌团队还给出了一个能提前判断“该不该上多智能体”的预测模型，准确率高达87%。

【文章要点】

  • 谷歌研究团队通过260组受控实验，首次为AI智能体系统建立了可量化的“缩放原则”，覆盖5种架构、3大模型家族、6个基准测试。
  • 核心发现：多智能体系统的效果好坏，取决于任务能否被拆解为可并行的子任务，而不取决于智能体数量本身；在需要严格顺序推理的任务上，所有多智能体架构无一例外地拖累了效果。
  • 架构设计本身就是一种“安全机制”：没有中心协调者的独立并行架构，会把单个智能体的错误放大17.2倍；而有协调者审核的中心化架构，能把错误放大控制在4.4倍。
  • 谷歌训练出的预测模型（R²=0.373～0.413）能仅凭任务的工具数量、可拆解性等特征，提前判断出最优架构，在未见过的任务上准确率达到87%。
  • 结论：模型越聪明，不代表越应该“堆智能体”，架构必须与任务结构对齐，收益才能兑现。

从代码助手到私人健康顾问，AI智能体正在从“一次性问答”走向“持续多步骤交互”。但一个问题始终没有标准答案：一个任务，到底该交给一个足够强的智能体自己搞定，还是拆给一群智能体分工协作？

过去两年，“智能体越多越好”几乎成了行业默认答案。有论文报告过，LLM的表现会随着智能体数量增加而持续提升；也有研究发现，多智能体协作“往往能通过集体推理超越任何单一个体”。

但谷歌研究院联合麻省理工学院等机构在最新论文《Towards a Science of Scaling Agent Systems》中给出了不同的答案：多智能体系统的效果天花板，早就存在，而且这个天花板由任务本身的结构决定，跟你堆多少个智能体没有必然关系。

先划清一条线：什么才算“智能体任务”

在动手做实验之前，谷歌团队先解决了一个容易被忽略的问题：市面上很多“智能体评测”，测的其实根本不是智能体能力，而是模型的静态知识水平。

研究团队给出了三条判断标准，一个任务只有同时满足下面三点，才算是真正的“智能体任务”：

  • 需要与外部环境进行持续的多步骤交互；
  • 需要在信息不完整的情况下反复主动收集信息；
  • 需要根据环境反馈不断调整策略。

像GSM8K数学题、MMLU知识问答这类“一次生成、立刻出答案”的静态基准，并不满足这些条件——用它们来评估多智能体协作的价值，得出的结论很可能是误导性的。

按照这套标准，研究团队最终选定了六个真正意义上的智能体基准：

  • 网页信息检索（BrowseComp-Plus）
  • 金融分析（Finance-Agent）
  • Minecraft环境下的任务规划（PlanCraft）
  • 真实商业场景中的工具调用（WorkBench）
  • 软件工程任务
  • 终端操作任务

实验设计：5种架构，260组“对照实验”

为了排除“不同架构用了不同提示词、不同工具、不同算力预算”这种混杂因素，谷歌团队严格控制了所有变量：所有架构使用完全相同的任务提示、相同的工具接口、相同的计算预算，唯一改变的只有协调结构本身。

研究团队一共定义了五种典型架构：

  • 单智能体系统（SAS）：一个智能体独自完成全部推理和行动，拥有统一、连续的记忆流；
  • 独立式（Independent）：多个智能体并行处理子任务，彼此互不通信，只在最后汇总结果；
  • 中心化（Centralized）：“中枢+分支”模式，一个协调者负责拆解任务、分发给子智能体、再汇总结果；
  • 去中心化（Decentralized）：智能体两两之间直接通信，通过多轮讨论达成共识；
  • 混合式（Hybrid）：中心化的层级控制 + 有限的智能体间横向沟通。

在此基础上，研究团队把这五种架构，套用到OpenAI GPT、谷歌Gemini、Anthropic Claude三大模型家族的多个能力档位上，一共跑出了260组受控配置，覆盖六个真实智能体基准。这也是目前公开研究中，对“智能体架构效果”做得最系统的一次受控对比。

核心发现一：“对齐原则”——能不能并行，才是关键

实验结果直接推翻了“智能体越多越好”的简单假设。

在可以拆解成并行子任务的场景里，比如财务分析——不同智能体可以同时分析营收趋势、成本结构、市场对比——中心化协调架构相比单智能体系统，性能提升了80.9%。任务被拆得越合理，多个智能体各自专注一块，整体效果反而比一个智能体“连轴转”要好得多。

但在需要严格按顺序推理的任务里，比如Minecraft环境下的规划任务，情况完全反转：论文测试的每一种多智能体架构，都让性能下降了39%到70%。原因也不复杂——协调本身要消耗“认知预算”，当任务的每一步都强依赖上一步的结果时，智能体之间互相沟通、对齐进度所花费的开销，反而挤占了本该用来推理的资源。

这就是论文提出的核心原则：架构要不要“加人”，不取决于任务难不难，而取决于任务能不能被拆解。这一条，恰恰是很多团队在设计智能体系统时最容易忽略的地方。

核心发现二：工具越多，协调“税”越重

论文还发现了一个此前很少被量化讨论的现象——“工具-协调权衡”（tool-coordination trade-off）。

当一个任务需要调用的工具越多（比如一个需要接入16种以上工具的编码智能体），多智能体协调所带来的额外开销就会不成比例地上升。研究团队给出的解释是：多智能体系统本质上是把有限的token预算，切分给了多个智能体，当任务本身就需要大量token去处理复杂的工具编排时，协调开销会进一步压缩每个智能体可用的“思考空间”，效率损失也就随之被放大。

这意味着，工具越复杂的任务，往往越不适合简单粗暴地“拆给一群智能体各管一部分工具”，除非协调机制本身经过精心设计。

核心发现三：架构，本身就是一种安全机制

如果说前两个发现回答的是“效果好不好”，那么这一个发现回答的是一个更现实的问题：多智能体系统会不会“越帮越乱”？

研究团队专门测量了一个指标——错误放大率，即一个智能体犯的错，最终有多大概率被放大、传导到整个系统的最终结果里。

结果很直接：在没有协调者、各自并行工作的独立式架构中，错误被放大了17.2倍——因为没有任何机制去互相检查、互相纠正，一个小失误很容易一路传导到最终输出。 而在设有协调者的中心化架构中，这个放大倍数被压到了4.4倍。协调者在这里扮演的角色，相当于一道“验证关卡”，在错误汇总进最终结果之前，就有机会把它拦下来。

这个发现的意义超出了“性能优化”本身：对于要在真实业务中部署智能体系统的团队来说，选架构，某种程度上也是在选一套“容错机制”。同样的任务，选独立式还是中心化架构，容错能力可能相差好几倍。

核心发现四：一个能提前“猜对”87%架构的预测模型

前面三个发现，本质上都是“事后总结的规律”。谷歌团队更进一步，把这些规律做成了一个可以“事前预测”的工具。

研究团队用任务的可测量特征——比如工具数量、任务的可拆解程度——训练出了一个回归预测模型（交叉验证 R²=0.373，如果换用更贴合任务本身的能力评估指标，R²可提升到0.413）。这个模型能在完全没见过的任务配置上，正确预测出最优架构，准确率达到87%。

换句话说，开发者以后不再需要靠“试了再说”来决定用单智能体还是多智能体、用哪种多智能体架构，而是可以先看任务本身的两个关键属性——顺序依赖程度和工具密度——就能大致判断出该往哪个方向设计系统。

小结：模型越强，越需要“会用”多智能体

论文的结论其实指向了一个反直觉但更接地气的判断：随着谷歌Gemini这类基础模型持续变强，多智能体系统并不会因此变得不必要——恰恰相反，模型越强，多智能体协作能撬动的收益也越大，前提是架构选对了。

对于正在做智能体产品的团队，这篇论文提供的与其说是一套具体算法，不如说是一份决策清单：

  • 任务能不能拆成互不依赖的子任务？能拆，多智能体大概率划算；不能拆，先别急着堆智能体。
  • 任务要调用的工具多不多？工具越多，协调成本可能吃掉多智能体的收益。
  • 对可靠性要求高不高？如果高，优先考虑带协调者的中心化架构，而不是各自为政的独立式架构。
  • 单智能体基线本身表现是不是已经很不错了？如果已经很高，加协调开销可能得不偿失。

从“多智能体是不是灵丹妙药”这种模糊的争论，到“具体什么任务该用什么架构”这种可以量化计算的工程问题——这或许才是这篇论文对整个行业最大的价值。

参考资料：

  1. Google Research Blog: Towards a science of scaling agent systems: When and why agent systems work https://research.google/blog/towards-a-science-of-scaling-agent-systems-when-and-why-agent-systems-work/
  2. 论文原文：Towards a Science of Scaling Agent Systems（arXiv:2512.08296v3） https://arxiv.org/abs/2512.08296

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

  • 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
  • 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
  • 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
  • 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
  • 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

  • 告别低效，重塑开发范式
  • 驾驭AI Agent(Claude Code)，实现工作流自动化
  • 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。