当通用型 Agent 击败专家组：统一单 Agent 架构的优势

AI 工程界的普遍共识是，复杂的任务需要专门化的 Agent：研究员 Agent、作家 Agent、评论员 Agent，每个 Agent 处理其狭窄的领域并交接给下一个。这种架构直觉似乎是正确的——它反映了人类团队的工作方式、微服务的构建方式以及我们在软件工程中分解问题的方式。问题在于，越来越多的实验数据表明事实并非如此。

Google DeepMind 和 MIT 在 2025 年的一项研究评估了 5 种 Agent 架构和 3 个 LLM 系列的 180 种配置。对于顺序推理任务——涵盖了大多数实际知识工作的类别——与配置良好的单 Agent 相比，每一种多 Agent 协作变体的性能都下降了 39% 到 70%。不是持平，而是性能下降。

这并不是要全盘否定多 Agent 系统。在某些工作负载中，协作确实能带来真正的收益。但这种追求专门化的默认本能，正让生产团队在金钱、延迟和可靠性方面付出真实的代价——而且往往没有任何可衡量的准确率提升。

协作税并非理论虚构

当你向流水线中添加第二个 Agent 时，你会立即支付四种成本：每次交接的延迟（每个边界 100–500 毫秒）、在 Agent 之间重建共享上下文的 Token 开销（对生产追踪的分析显示，多 Agent 系统中 37% 的总 Token 是“协作 Token”——用于重新建立共享状态，而不是做实际工作）、下游 Agent 继承上游错误导致的错误放大，以及成倍增加调试范围的工程复杂性。

一个真实的生产案例研究说明了这种计算。一个运行文档分析工作流的团队测量出，使用三 Agent 流水线（研究员 → 分析师 → 合成器）的编排成本为每月 47,000 美元。重构后的单 Agent 版本成本为每月 22,700 美元。准确率差异为 2.1 个百分点（94.3% vs 92.2%）。多 Agent 版本的延迟惩罚是：每次查询增加 4.8 秒。他们在将其与基准进行测量之前，花了三个月时间构建这条流水线。

生产追踪的可靠性数据也说明了同样的问题。单 Agent 的平均成功率约为 99.5%。转为多 Agent 协作，成功率降至 97.0%——这 2.5 个百分点的下降在规模化运作时会严重恶化。一个具有 10 个步骤、每步可靠性为 97% 的 Agent 工作流，其端到端成功率仅为 74%。而在 99.5% 的情况下，同样的工作流能达到 95%。

Token 成本也会翻倍。从单 Agent 转向三 Agent 流水线通常会导致 Token 支出增加 2–5 倍。如果单 Agent 处理每个内容的成本为 0.08 美元，那么多 Agent 的成本就是 0.24 美元，而质量差异大到评审人员甚至无法可靠地分辨出来。

研究关于错误放大的真实发现

17 倍的错误放大数字值得关注。对“Agent 包”（bag of agents）架构——即没有结构化协作拓扑的松耦合 Agent——的分析显示，错误放大并非线性增长。当 Agent B 将 Agent A 的输出视为事实真理时，A 的错误就成了 B 的初始假设。当错误传导到第三跳时，原始错误已经被两个下游系统言之凿凿地进一步阐述了。

带有验证循环的结构化协作能将这种放大降低到 4.4 倍。这仍然很可观，且只有通过刻意的架构设计（闭环验证、显式错误信号、重试门控）才能实现。大多数团队并没有构建这些，他们构建的是输出向前流动、错误不断累积的流水线。

协作的拓扑结构比你拥有一个还是五个 Agent 更重要。成功部署多 Agent 系统的团队将协作视为一流的工程问题，而不仅仅是添加更多 Agent 的结果。

能力饱和效应

Google/MIT 的研究发现了一个比具体数字更具理论意义的现象：能力饱和效应。一旦单 Agent 基准在某项任务上达到约 45% 的准确率，额外的多 Agent 协作就会产生边际收益递减甚至负收益。他们的模型仅根据单 Agent 基准性能，就能预测 87% 的预留配置的最优架构。

这一结论对于投入多 Agent 框架的团队来说有些令人不安：协作是模型能力不足的权宜之计，而非永久的架构优势。随着基座模型的改进，多 Agent 协作优于能力强大的单 Agent 的任务范围正在不断缩小。2024 年需要三 Agent 流水线处理的工作流，到 2026 年可能由运行新模型的单 Agent 处理得更好。

这并不意味着多 Agent 系统会消失。但这意味着评估基准应始终是“一个能力强大的单 Agent 能做得多好？”——团队在接受协作开销之前，应要求多 Agent 架构证明其相对于该基准的优势。

多智能体协作真正胜出的场景

那些证明单智能体简洁性优势的研究，同时也指出了多智能体协作（multi-agent coordination）在哪些领域能带来真正的提升。

具有独立子任务的可并行化工作负载。 Google 和 MIT 的研究发现，在并行财务推理任务中，性能提升了 +80.9%。当子任务之间没有顺序依赖关系且可以并发执行时，协调开销是一项能换取真正吞吐量的固定成本。批量文档处理、多源研究汇编和并行假设评估都符合这种模式。

对抗性验证。 在测试可验证的任务中，使用独立评审智能体（reviewer agent）的软件开发流水线能实现可衡量的质量提升。SWE-bench 的数据显示，多智能体编程团队（由管理者 + 研究员 + 工程师 + 评审员组成）在 SWE-bench Verified 上的表现达到了 72.2%，而单智能体为 65% —— 这是实打实的 7 个百分点的提升。关键在于代码具有客观的质量信号（测试通过或失败），这使得评审员的批评是有据可依的，而非凭空猜测。

安全与合规边界。 当法规要求不同领域之间进行数据隔离时（例如，医疗健康标识符不能接触财务记录），架构分离是合规性要求，而非性能选择。

团队规模的开发。 当不同的工程团队负责系统的不同部分并需要独立的部署周期时，组织结构会自然地映射到智能体分离上。这是一种工程治理主张，而非能力主张。

请注意这个列表中缺少的内容：大多数团队在辩护采用多智能体架构时实际引用的用例。“通过专业化实现更好的推理”、“更清晰的关注点分离”、“更模块化的架构” —— 这些都是软件工程直觉，但在智能体系统中并不能直接转化，因为智能体系统的上下文重构成本很高，且模型能力非常广泛。

浏览器与研究智能体：统一架构优势最明显的领域

浏览器智能体领域是统一架构最清晰的经验案例。目前在网页导航基准测试中表现最佳的系统，并不是在搜索专家、阅读专家和综合专家之间进行路由的多智能体流水线，而是具有丰富集成工具访问权限的单智能体。

Surfer 2 在 WebVoyager 基准测试中达到了 97.1%，它采用统一架构并拥有搜索、视觉和交互工具的访问权限。OpenAI 的 Deep Research 系统表现优于以往的多智能体研究流水线，它是一个针对网页浏览和数据分析进行优化的单一模型，而非专业组件构成的流水线。性能优势源于能力的无缝整合，而非专业化。

直观的原因是研究任务本质上是顺序的且依赖于上下文的。搜索决策取决于上一个结果返回的内容，阅读决策取决于搜索发现了什么。专业智能体之间的每次交接都需要重新构建这种上下文 —— 支付协调税（coordination tax）来重新整合统一智能体已经拥有的信息。

生产系统的决策框架

研究支持一个相当清晰的决策规则，用于判断何时采用多智能体架构，而非优化单智能体。

在以下情况下，请先从单智能体开始： 任务主要是顺序的、工具集可以放入一个上下文窗口、延迟预算在 5 秒以内、团队只有不到六个月的智能体开发经验，或者你每月运行的查询量少于 10,000 次。在这些条件下，多智能体协调开销的成本高于其回报。

在以下情况下，请考虑多智能体架构： 你拥有可证明的且无顺序依赖的并行化子任务、客观验证信号（如测试套件）证明了对抗性评审智能体的合理性、合规性要求强制数据隔离、不同团队负责具有独立部署需求的组件，或者你持续运行每月超过 50,000 次查询，吞吐量的提升能抵消平台投资成本。

先运行基准测试。 在构建多智能体系统之前，先衡量一个能力强大的单智能体在你的特定任务上能做到什么程度。能力饱和效应（capability saturation effect）意味着这个数值可以预测协作是否会有所帮助。如果你的单智能体基准在该任务上已经达到 45–50% 以上，那么你可能已经进入了增加智能体只会增加成本而不会提高准确性的领域。

不要将并行性与专业化混淆。 那些真正从多智能体协作中受益的系统，是通过独立子任务的并行执行来实现的，而不是通过为不同的推理模式对智能体进行专业化分工。一个“研究智能体”和一个“写作智能体”并不是独立的 —— 写作取决于研究，而在智能体之间传递该上下文的协调开销往往超过了专业化带来的好处。

趋向复杂性的组织压力

多智能体架构传播速度超过其性能表现的一个原因是组织层面的。复杂的架构看起来更高级。框架供应商将编排（orchestration）视为他们的主要差异化优势。构建多智能体系统的从业者在设计评审中需要解释的内容更多。“我们使用单智能体”听起来显得很幼稚，而“我们拥有一个带有监督层和批判层的五智能体流水线”则不然。

Gartner 预测，到 2027 年底，超过 40% 的智能体 AI 项目将因成本上升、商业价值不明确以及风险控制不足而被取消。最有可能落入这一统计数据的团队，是那些在衡量是否需要多智能体复杂性之前就选择了它的团队。

过去两年生产环境智能体部署中得到的反直觉教训是，能力广度的扩展速度超过了协作基础设施的改进速度。2026 年的一个能力强大的单智能体在广义上比 2024 年的三智能体流水线更有能力，而且它更便宜、更快，也更容易调试。将专业化作为一种架构策略，正背离模型发展的方向，而非顺应。

从一个智能体开始，诚实地衡量它，只有当数据表明你需要时才添加协作。