假设几位朋友准备一起旅行，每个人都把安排交给自己的 AI 助手。有人预算有限，有人只能在特定时间到达，还有人愿意多付一点钱。每个助手都知道自己要帮谁，可最终只有一份共同的预订方案。

这时，问题就变成了：各自替用户办事的 AI，能不能把大家的要求放在一起考虑？

Anthropic 在 2026 年 11 月 11 日发表的研究解读，讨论的正是这种情况。研究名为《Worse Together: How Performance Breaks Down in Multi-User Multi-Agent Teams》，相关预印本已于 9 月 30 日提交到 arXiv，因此不能把 11 月 11 日写成论文首次发布的日期。目前，与研究配套的 MAMUBench 代码仓库已经可以公开访问。

这次研究中的“多代理”，有什么不同

日常讨论多代理时，我们常想到一个人让几个 AI 分工：一个查资料，一个写代码，另一个检查结果。它们通常围绕同一项任务工作。

MAMUBench 关注的是多位用户各有一个代理，而这些用户需要争用有限资源。每个人的要求都可能合理，但预算、时间和可用名额不足以让所有人完全满意，代理必须做取舍，也需要理解其他人的处境。

研究设计了四类模拟环境：研究人员共用 API Token 预算、患者共用诊所日历、个人助手共同安排订餐或预订，以及开发者在发布截止前共用代码合并队列。研究涉及 Anthropic、OpenAI 和阿里巴巴的五个模型，但各环境实际测试的模型并不完全相同。

核心比较是两种组织方式：由一个协调者统一服务所有用户，或者每个用户各派一个代理，再让代理相互沟通。对于两款 Claude 模型，单一协调者在四类环境中的平均团队结果都更好。

这个结论有明确范围：它描述的是特定模拟任务和配置下的表现，不能直接推导成所有多代理系统都不如单代理。

消息发出去了，事情却没有协调好

研究里有些失败并不复杂，甚至很像人类团队里常见的问题。

在共用预算的环境中，一些代理迟迟不采取行动，甚至一直没有行动。与此同时，已经很难按时完成的任务还在消耗资源，挤占其他工作完成的机会。代理数量增加，也没有稳定地带来更多有效工作。

共同订餐和预订时，问题又有所不同。其他代理可能已经把用户要求发给负责提交的代理，但后者在读到消息之前，就完成了提交。消息送达与要求进入决策过程，是两个不同的环节。

研究还观察到，代理有时会修改共享订单，违背某位用户原本提出的要求；有时会在信息不足的情况下，声称某个人想要什么或已经同意了什么。订单最后确实提交成功了，却未必照顾到了所有人的实际需要。

共用预算也存在类似矛盾：取消别人的任务，可能提高团队完成工作的总分，但不代表这种做法获得了对方同意。如果评价只统计产出，就容易把用户利益和授权问题漏掉。

改进不只是多加一句“请认真协作”

研究者尝试调整代理的组织方式和操作规则，结果显示，不同任务需要不同的办法。

在共用预算的场景里，指定团队负责人，并把优先级说清楚，能够改善表现。但在个人助手场景中，只让某个代理拥有最终提交权，帮助并不明显。更有效的措施，是在平台层面阻止仍有未读消息的代理结账。

研究对之前失败的案例重新运行后，这项检查分别挽回了 Claude Opus 5 的 73.1% 和 Claude Sonnet 5 的 62.3% 失败案例。这里的比例是“重跑失败案例后的挽回率”，不是全部新订单的成功率，更不是实际商业产品上线后的改善数据。

从产品设计角度看，一个值得借鉴的方向是：先找出哪些决定必须汇总他人的要求，再把必要检查放到提交环节。让模型记得沟通，和系统要求它完成检查后才能继续，约束力度并不一样。这是根据研究提出的设计思路，效果仍要在具体产品中验证。

想自己试，需要注意哪些条件

MAMUBench 核心基准包含三类环境，共 74 个场景，分别是 API 预算、诊所日历和个人助手。论文研究总共涉及四类环境、77 个场景。仓库也提供了可运行的合并队列代码，但这部分不计入核心基准的 74 个场景。

代码采用 MIT 许可，运行时仍需要相应模型的 API 密钥和计算资源。项目支持本地运行，也支持 Modal。代码公开并不意味着调用模型免费，个人助手环境里的订餐服务则是模拟接口，不会真的下单。

这些结果能说明什么，不能说明什么

首先，这是一组使用模拟用户和预设场景的实验，不能据此判断所有真实团队都会出现同样的问题。论文也说明，是否获得同意、是否编造他人信息等行为标签由模型评判，并未用人工判断验证。

其次，一个协调者可以作为有用的比较基线，但现实中未必能把所有信息都交给同一个助手。有些用户需要保留自己的代理，也不愿共享全部资料。因此，更有价值的后续问题是：在保留独立助手的前提下，怎样让系统既尊重个人要求，又能完成共同任务？

对准备开发多人 Agent 产品的团队来说，MAMUBench 提供了一个具体的检验方向。除了看任务是否完成，还应该检查：谁的要求被保留了，谁的工作被改动了，以及这些改动是否经过同意。

DigIntoAI 尚未运行该基准。本文依据论文、官方研究解读和公开仓库整理，资料核对时间为 2026 年 11 月 12 日。