Google Research 和 MIT 最近联合发了篇论文，做了一件很有价值的事——他们不是在推销某个框架，而是在科学地回答一个问题：多Agent系统到底什么时候该用，什么时候不该用？

这可能是我今年看到的最实用的一篇Agent论文。

他们做了什么？

简单说：测了180种Agent配置，涵盖不同的架构模式、任务类型、Agent数量，然后用数据说话。

他们把多Agent架构分成了四类：

• 独立型：每个Agent各干各的，互不通信
• • 集中型：有个中央编排器，所有Agent只跟编排器对话
• • 去中心化型：Agent之间点对点通信
• • 混合型：集中+去中心化的结合
    然后在不同类型的任务上跑测试。

关键发现

发现一：并行任务，多Agent碾压

如果一个大任务可以拆成多个独立的子任务同时执行（比如同时分析10份文档），多Agent系统的优势是碾压级的。

这个好理解——就是并发嘛。

发现二：串行任务，多Agent反而拖后腿

这个就反直觉了。如果任务必须按顺序执行（步骤B依赖步骤A的结果），加Agent不仅没帮助，反而因为通信开销导致性能下降。

说白了：如果任务本身是线性的，一个Agent从头干到尾反而最快。

发现三：错误传播是最大隐患

独立型架构（Agent各干各的）在出错时，错误会被放大17倍。因为没有人检查中间结果，一个Agent的错误直接传递给下游。

而集中型架构（有编排器）把错误放大控制在了4.4倍——因为编排器会在中间做一次校验。

这个数据太重要了。 它直接说明：不是Agent越多越好，而是架构选择决定了系统的可靠性。

87%准确率的架构选择器

Google团队做了一个预测模型，根据任务特征自动推荐最佳架构。在未见过的任务配置上，准确率达到了87%。

核心判断维度就两个：

1. 任务可并行度 — 子任务之间的依赖关系有多强
2. 2. 错误容忍度 — 单步出错对最终结果的影响有多大
      高并行度 + 低错误敏感 → 独立型或去中心化
      低并行度 + 高错误敏感 → 集中型
      复杂混合场景 → 混合型

对实际开发的启示

1. 别无脑堆Agent

看到太多人的思路是"任务复杂？加Agent！还是不行？再加Agent！"。Google的数据告诉你：对于串行任务，这样做是负优化。

2. 编排器不是可选项，是必选项

17倍 vs 4.4倍的错误放大率差异太大了。只要你的Agent系统有两个以上的Agent，就必须有一个编排器做中间校验。

3. 更聪明的模型不能替代更好的架构

论文里有一句话说得好：“更聪明的模型不会取代多Agent系统的需求——它只会加速这个需求，但前提是架构得对。”

用GPT-5替换GPT-4不会让一个烂架构变好，但会让一个好架构变得更好。

我的实操建议

如果你正在构建Agent系统，先回答三个问题：

1. 你的任务能拆成并行子任务吗？能拆多少个？
2. 2. 单个子任务出错，会影响最终结果吗？影响多大？
3. 3. 子任务之间需要共享信息吗？共享多少？
      这三个问题的答案，直接决定了你该用哪种架构。不需要试错180种配置——Google已经帮你试过了。

---

参考：

• Google Research: “Towards a Science of Scaling Agent Systems”
• • InfoQ: “Google Publishes Scaling Principles for Agentic Architectures”
• • 论文 arXiv:2512.08296