一项发表于《Nature Machine Intelligence》的大规模对照研究对“Agent越多，效果越好”提出了系统性质疑。研究团队在提示词、工具和总计算预算基本一致的条件下，测试了OpenAI、Google与Anthropic三个模型家族、五种单/多Agent架构及六类真实交互任务，共形成260种配置。结果显示，多Agent相对单Agent的效果从提升80.8%到下降70%不等：适合并行调查的金融分析明显受益，顺序关系很强的规划和软件工程任务却可能被协调成本拖累。研究还提出一条实用但非普遍定律的经验线：如果单Agent在同类任务上的成功率已超过约45%，增加Agent通常不会带来收益。真正应该扩展的不是Agent数量，而是与任务结构相匹配的协作方式、验证节点和信息流。
文章作者、来源：Chanwoo Park
“组建Agent团队”并不是免费的能力升级
多Agent系统背后的直觉非常诱人：一个Agent负责搜索，一个负责分析，一个负责验证，再由一个管理者汇总，效果理应胜过单个模型独自工作。软件开发、金融研究和科学发现领域已经出现大量采用这种结构的产品，“更多Agent就是你所需要的一切”甚至一度成为流行口号。
问题是，每增加一个Agent，系统得到的不只是更多推理能力，也增加了新的通信和管理负担。
单Agent拥有一条统一的上下文：它此前读过什么、调用过哪些工具、环境发生了什么变化，通常都保存在同一条工作轨迹里。多Agent则把这些信息分散到不同上下文中。每个Agent只看到局部信息，必须通过消息把结论压缩后传给其他Agent。在压缩过程中，细节可能丢失；多个Agent还可能对环境状态形成不同理解，或者把同一项工作重复执行。
因此，研究团队没有简单比较“一个Agent与四个Agent谁的分数高”，而是尽量保持提示词、工具接口和系统总计算预算一致，只改变模型能力与协作结构。实验覆盖单Agent，以及独立、中心化、去中心化和混合式四种多Agent架构，并使用OpenAI、Google和Anthropic三个模型家族的不同能力档位。
六项测试分别覆盖网页搜索、金融分析、游戏规划、现实办公任务、SWE-bench Verified软件工程任务和Terminal-Bench终端任务。这些任务需要模型持续观察环境、调用工具并根据反馈调整策略，比一次性回答数学题更接近真正部署的Agent。
同样是多Agent，结果可以相差150个百分点
实验最醒目的结果，是多Agent并不存在稳定的平均优势。
在Finance Agent金融分析任务上，中心化架构的平均成绩比单Agent提高80.8%，成功率从34.9%上升到63.1%；去中心化和混合架构也分别提升74.5%和73.1%。金融研究天然适合分工：一个Agent调查监管与新闻，一个分析SEC文件，一个评估企业运营影响，最后由管理Agent综合证据。并行搜索扩大了信息覆盖范围，协调成本因而值得支付。
但在PlanCraft顺序规划任务上，所有多Agent架构都出现退步。其中，独立Agent架构相较单Agent下降70%，中心化架构下降50.3%。
论文给出的例子是合成一个游戏物品。单Agent只需要查询配方、移动材料并执行合成，整个过程只有几步。中心化系统却可能把任务拆成“研究配方”“检查库存”“执行制作”三个子任务，再发送多轮协调消息。任务本身非常简单，协作流程反而比实际工作更复杂。
真实软件工程也没有自动从“人多”中获益。在SWE-bench Verified上，单Agent平均成功率为48.8%；混合、中心化、去中心化和独立架构分别下降1.3%、2.6%、6.4%和12.8%。当模型已经可以在统一上下文中理解代码库并连续修改时，拆分上下文可能破坏文件之间的关联，让不同Agent基于过时状态工作。
综合六项基准，所有多Agent配置相对单Agent的平均提升为0%，而结果范围从下降70%到提升80.8%。这说明“多Agent是否更强”本身可能就是一个错误问题。更有意义的问题是：任务能否自然拆成彼此独立的并行信息流，以及协作架构是否与这种结构一致。
约45%的“能力饱和线”
研究团队发现，预测多Agent是否值得使用时，最稳定的指标并不是模型品牌、Agent数量或消息频率，而是单Agent已经能把任务做得多好。
团队基于实验拟合出一条约45%的经验阈值：如果单Agent在同类任务上的基础成功率高于45%，增加Agent通常只会产生很小的收益，甚至降低表现；如果单Agent明显低于这条线，多Agent才有更大的改善空间。
这条规则在SWE-bench Verified和Terminal-Bench的16种模型—任务验证配置中，对多Agent收益正负方向的预测准确率达到94%。结合协调效率、错误放大、消息密度和重复率等指标后，研究团队建立的模型还能在87%的域内留出配置中选出表现最好的架构。
不过，作者特别强调，45%不是适用于所有任务和未来模型的“自然定律”。相关阈值来自这组实验，部分涉及团队规模的统计关系在按照数据集聚类进行稳健校正后，没有达到显著水平。因此，它更适合作为工程筛选规则：先测试一个强单Agent，如果它已经表现不错，不要在缺乏证据的情况下直接增加多个Agent。
多Agent最危险的问题是错误扩散
多个Agent除了增加成本，还会改变错误传播方式。
如果独立Agent各自产生答案，最后直接投票或汇总，一个错误结论可能因为表达得更自信、出现得更早，或者被其他Agent重复，而变成团队共识。论文的轨迹分析显示，独立式多Agent架构的错误放大系数达到17.2倍；带有中心协调和验证节点的架构则降至4.4倍。
这意味着管理Agent的价值不只在分配任务，还在充当验证瓶颈：检查子Agent使用的证据、识别状态冲突，并阻止错误结果直接进入最终答案。
但中心化也不是万能方案。管理Agent本身可能成为信息瓶颈，需要阅读大量中间消息；如果它的判断错误，整个团队会在同一方向上偏离。实验中，混合架构产生的协调开销达到515%，平均成功率却与开销为285%的中心化架构没有显著差异。发送更多消息、运行更多回合，并没有按比例带来更好的结果。
研究还估算，随着团队扩大，交互轮数可能呈超线性增长：六个Agent约需69轮，十个Agent约需157轮，分别相当于单Agent基准的9.5倍和21.8倍。在固定预算下，Agent越多，分配给每个Agent真正思考和操作的资源反而越少。
Token成本揭示了协作的真实价格
如果只观察任务成功率，多Agent增加的推理成本很容易被忽略。论文用“每1000个Token获得多少次成功”衡量效率：单Agent达到67.7次，中心化架构降至21.5次，去中心化架构为23.9次，混合架构只有13.6次。
换言之，中心化、去中心化和混合系统的Token效率分别约为单Agent的三分之一、三分之一和五分之一。
在某些高价值任务中，这笔支出完全合理。例如，一份投资分析报告的错误成本可能远高于多调用几次模型。但如果Agent只是执行简单、连续、容易验证的工作，额外协调就可能成为昂贵的仪式：系统看起来更复杂、更“自主”，实际产出却没有改善。
正确做法是先判断任务，再决定是否组队
这项研究给Agent开发者带来的结论，不是应当放弃多Agent，而是不能把多Agent当成默认升级选项。
如果任务能够自然分解成相互独立的调查方向，需要同时访问多类信息源，而且各子任务的结果容易验证，多Agent通常更有吸引力。金融尽调、广泛资料研究、多个假设的并行实验以及不同专业视角的交叉检查，都可能属于这一类。
如果任务依赖同一份持续变化的环境状态，步骤之间具有严格先后关系，并且一个强模型已经可以在统一上下文中完成，多Agent则更可能造成信息碎片、重复操作和状态冲突。代码库修改、终端操作与顺序规划任务尤其需要谨慎。
更实际的开发流程是：先建立强单Agent基线，记录成功率、成本、工具调用和常见失败；只有当失败确实来自搜索覆盖不足、缺少并行探索或验证能力时，再加入有明确职责的Agent。增加之后，还要重新测量端到端成功率和总成本，而不是用“Agent数量”代替能力证据。
论文真正否定的不是协作，而是把组织复杂度误认为智能。随着底层模型变强，过去需要多个Agent互相补救的任务，可能逐渐被一个拥有完整上下文的强Agent完成。未来Agent系统的竞争重点，或许不是谁能同时启动最多助手，而是谁能更准确地知道什么时候需要团队、应该怎样分工，以及什么时候让一个模型安静地把事情做完。