谷歌180种Agent架构实测：多Agent协作可能让你的系统更烂

最近在做一个多Agent协作的项目，踩了不少坑。正好看到谷歌联合MIT发了一篇论文，测了180种Agent架构配置，结论让人冷汗直冒——多Agent系统在顺序推理任务上，所有变体的性能都下降了39%到70%。这不是随便跑几个demo得出的结论。研究团队用了四个benchmark（Finance-Agent、BrowseComp-Plus、PlanCraft、Workbench），五种架构模式（单Agent、独立多Agent、集中式、去中心化、混合式），三个LLM家族，总共180种配置的对照实验。

「Agent越多越好」这个直觉是错的

搞Agent的人几乎都有这个直觉：任务复杂？加Agent。效果不好？再加Agent。分工明确一点，每个Agent负责一块，组合起来肯定比单打独斗强。谷歌这篇论文直接打脸了。先看数据。在金融推理这类可并行化的任务上，集中式多Agent确实能比单Agent提升80.8%，效果拔群。但在PlanCraft这类顺序推理任务上，所有多Agent方案全部拉垮：

为什么？论文给了一个很直观的解释：通信开销会割裂推理过程。顺序推理需要连贯的”认知预算”，Agent之间的消息传递、上下文切换会打断思维链。本来一个Agent能完整推理出来的东西，拆成三个Agent反而每个都只看到局部信息，谁也拼不出全貌。

错误放大效应：17倍 vs 4.4倍

这是论文里最让我印象深刻的发现。独立Agent架构（每个Agent各自为战，最后汇总结果）会把错误放大约17倍。一个Agent犯了错，没人纠正，错误就一路传播下去。集中式架构好一些，调度器会在传递结果前做校验，错误放大被控制在约4.4倍。17倍什么概念？假设单个Agent有5%的错误率，独立多Agent架构下系统错误率能飙到接近不可用的水平。这还不算Agent之间的错误叠加和幻觉传染。实际开发中我遇到过类似情况。之前做一个文档分析的Agent pipeline，三个Agent串行处理：抽取→分析→总结。第一个Agent偶尔会抽取错误的字段，第二个Agent基于错误数据做出荒谬的分析，第三个Agent还把荒谬分析写成了一本正经的总结。最后输出的东西看起来很professional，但内容完全是错的。

工具调用越多，多Agent越拉垮

论文提出了一个”工具-协调权衡”（tool-coordination trade-off）：在固定计算预算下，工具密集型任务受多Agent开销的影响特别大。这很好理解。每个Agent都需要调用API、查数据库、执行代码，这些操作本身就有延迟和失败率。多个Agent同时调工具，不仅要处理工具本身的问题，还要处理Agent之间的协调问题。两层复杂度叠加，系统的脆弱性指数级上升。一个具体的例子：假设你的Agent需要调用5个不同的API来完成任务。单Agent模式下，它按顺序调用，每一步都能根据上一步结果调整策略。多Agent模式下，你可能让3个Agent并行调用不同API，但它们之间需要共享中间状态，这个共享机制本身就是bug的温床。

能力饱和点：单Agent超过45%就别加人了

论文发现了一个关键阈值：当单Agent在某个任务上的baseline准确率超过约45%时，加更多Agent的边际收益急剧下降，甚至变成负收益。这个发现的实践意义很明确——先把单Agent优化到极致，再考虑多Agent方案。很多团队（包括我自己之前）犯的错误是：单Agent效果一般，立刻想到”加Agent”。正确的做法应该是：先优化prompt、调整工具、升级模型、改进检索策略。把单Agent的能力压榨到极限之后，如果任务确实是可并行的，再上多Agent。

# 错误做法：单Agent效果不好，立刻上多Agent
agent1 = Agent(role="researcher", model="gpt-4")
agent2 = Agent(role="analyzer", model="gpt-4")
agent3 = Agent(role="writer", model="gpt-4")
result = pipeline([agent1, agent2, agent3], task)

# 正确做法：先优化单Agent
agent = Agent(
    role="full_stack_analyst",
    model="claude-opus",
    tools=[search, analyze, write],
    system_prompt=optimized_prompt,  # 花时间在这里
    max_retries=3,
    self_reflection=True  # 让Agent自我检查
)
result = agent.run(task)

87%准确率的架构选择模型

论文不只是指出问题，还给了一个实用的预测框架。研究团队开发了一个基于任务特性的预测模型，能以87%的准确率判断某个任务该用什么架构。判断依据主要看两个维度：1. 任务的可并行度任务能不能拆成独立的子任务？如果能，集中式多Agent收益最大。如果任务是链式依赖的（A的输出是B的输入，B的输出是C的输入），别用多Agent。2. 工具密集度任务需要调用多少外部工具？工具调用越密集，多Agent的协调成本越高。如果你的任务主要是纯推理（不需要调API、不需要查数据库），多Agent的开销相对可控。把这两个维度画成四象限：

这个模型在GPT-5.2上做了out-of-sample验证，MAE只有0.071，说明这些规律在新模型上依然成立。

实际项目中怎么用这些结论

结合论文和自己的踩坑经验，总结几条可操作的建议：1. 默认单Agent，除非有明确理由不要因为”多Agent看起来更高级”就上多Agent。单Agent + 好的prompt + 合适的工具，能解决绝大多数问题。我现在的做法是：先用单Agent跑通全流程，跑出baseline，然后看瓶颈在哪。2. 只在并行任务上用多Agent典型的适用场景：同时分析多个文档、并行搜索多个数据源、批量处理独立的子任务。关键词是”独立”——子任务之间不能有依赖关系。3. 如果必须用多Agent，加调度器独立Agent的17倍错误放大太可怕了。集中式调度器虽然增加了延迟，但把错误控制在4.4倍已经好很多。调度器的核心功能：校验子Agent的输出、管理上下文、决定是否需要重试。

// 集中式调度器的基本结构
class Coordinator {
  private agents: Agent[];

  async run(task: Task): Promise<Result> {
    const subtasks = this.decompose(task);
    const results = await Promise.all(
      subtasks.map(st => this.executeWithValidation(st))
    );
    return this.merge(results);
  }

  private async executeWithValidation(subtask: SubTask) {
    const result = await this.agents[subtask.agentId].run(subtask);
    // 关键：调度器校验子Agent输出
    const validation = await this.validate(result, subtask);
    if (!validation.passed) {
      // 重试或降级到其他Agent
      return this.fallback(subtask, validation.errors);
    }
    return result;
  }
}

4. 监控Agent间通信开销多Agent系统的隐性成本很容易被忽略。Agent之间传递的context越大，token消耗越高，延迟越大。我现在会专门track每个Agent调用的token数和响应时间，一旦通信开销超过实际推理开销的30%，就说明架构有问题。

这篇论文的局限

说了这么多论文的发现，也得指出它的不足。实验用的都是标准benchmark，真实业务场景比benchmark复杂得多。比如论文没有覆盖”人机协作”的Agent架构——很多生产系统里，Agent并不是全自动的，中间有人类审核环节。加了人类审核的多Agent系统，错误放大效应会不会被抑制？论文没回答这个问题。另外，R²=0.524说明预测模型只能解释约52%的性能差异。还有将近一半的方差来自其他因素——prompt设计、工具质量、数据特性等等。87%的架构选择准确率听起来不错，但在生产环境里，那13%的误判可能正好踩在你的场景上。不过这不影响核心结论的价值。至少现在我们有了定量的证据，而不是靠直觉拍脑袋。

写在最后

多Agent不是银弹。这个结论说出来好像很显然，但在实际开发中，”加Agent”这个操作的诱惑力太大了——它给人一种”我在做架构设计”的错觉。谷歌这篇论文最大的贡献不是告诉你”多Agent有时候不好用”（这个很多人踩过坑之后都知道了），而是给出了量化的判断框架：什么时候该用、什么时候不该用、用了能好多少、不用会差多少。如果你正在搭Agent系统，建议把论文原文读一遍（arXiv:2512.08296），特别是里面的决策树部分。能帮你在项目早期就避开一些错误的架构选择，省下不少返工时间。