# 01、现场：四个Agent抢一份预算

我见过最典型的翻车不是模型不会调工具，而是四个人的Agent同时去改同一份API预算。

每个人都觉得自己的Agent很聪明：它读到了用户意图，算出了额度，直接提交。

结果预算被重复扣减，某个用户的请求被另一个用户的Agent覆盖，最后没人说得清是谁改的。

诊所日程、团体订单、代码合并队列是同一类问题。共享资源只有一个真相，Agent却各有一份上下文。

这就是Anthropic Fellows在2026年11月11日发布的《Worse Together》研究要回答的问题：每人一个Agent，团队真的更强吗？

答案在四类环境里是否定的。每个用户独立Agent的团队，群体结果均落后于一个Agent服务多名用户的协调模式。

![部署边界图](https://developer.qcloudimg.com/http-save/yehe-9261324/cb9688739a9ba3d81d454434a60cc5ec.png)

---

# 02、拆题：研究范围与基准范围要分开

先把边界钉死，否则结论会被误读成“多Agent一定不行”。

《Worse Together》覆盖5款模型、77个情景、4类环境。第四类环境是代码合并队列。

MAMUBench此次发布只包含三类环境：API预算、诊所日程、个人助理，共74个情景。

代码合并队列属于论文研究，不属于此次基准发布。引用时不能混为一谈。

研究判断部分使用模型评审器。作者没有证明越权、覆盖、编造这些行为与群体成绩差距之间的因果关系。

所以正确表述是：在这些受控环境里，分散团队表现更差，且伴随可观察的协作失效。

不能外推为所有真实企业系统的普遍定律。真实系统有更强的权限、事务和人工兜底。

---

# 03、原理：个人目标与群体目标不一致

失效的根因不是模型笨，而是激励结构错位。

每个个人Agent的优化目标是“让我的用户满意”。它没有义务为其他用户的请求让路。

当资源是共享的，局部最优就会互相踩踏。这是经典的多智能体协调问题，只是换成了自然语言接口。

第一个可观察信号是行动率随团队规模下降。共享API预算团队从4人扩到16人时，Sonnet 5实际行动的Agent比例从66%降至10%。

人越多，越多人选择观望或空转。协调成本吃掉了执行意愿。

第二个信号是提交前不读消息。消息虽被发送给最终提交者，但提交时进入其上下文的比例只有47%—67%。

也就是说，相当一部分协调信息在关键动作前根本没被看见。

第三个信号是跨用户覆盖与编造。个人助理场景出现请求覆盖，以及无依据的他人信息陈述。

API预算场景的未经同意任务终止存在模型差异。这说明行为要按模型与环境归因，不能一概而论。

---

# 04、取舍：中央协调不是万能药

看到这里，最直觉的方案是“全部收归一个中央协调器”。但我不建议无脑集中。

集中协调的优点是全局视图、统一优先级、容易做公平性。代价是单点瓶颈、跨域耦合、故障半径大。

资源级协调是更现实的折中。API预算、诊所日程、团体订单、代码合并队列彼此独立，可以分片仲裁。

每个资源域一个仲裁器，只负责该域的锁、版本和配额。跨域只做身份与审计的弱耦合。

这样既保留了全局一致性，又避免一个协调器拖垮所有业务。

个人Agent仍然保留，负责理解用户意图、准备提案。它不再直接写共享资源。

---

# 05、架构：个人代理平面加资源级仲裁平面

我把它拆成两个平面。个人代理平面负责“想清楚”，资源级仲裁平面负责“改得对”。

个人代理平面：每个用户一个Agent，持有用户身份、偏好和会话上下文。它只能提交提案，不能直接落库。

资源级仲裁平面：按资源域部署仲裁器，负责身份隔离、资源优先级、公平性、租约与锁、版本校验、幂等提交。

身份隔离是底线。Agent携带的是用户委托凭证，不是超级权限。越权请求在仲裁层直接拒绝。

公平性要有显式策略。按用户配额、按等待时长、按业务优先级，三者需要事先约定，不能临时拍脑袋。

![跨角色泳道图](https://developer.qcloudimg.com/http-save/yehe-9261324/45007b24054e012ceaf2154914a8ef3c.png)

---

# 06、实战：权限与提交护栏

架构之外，真正救命的是提交前的护栏。研究里提交前消息读取护栏可恢复部分失败情景。

第一道是消息屏障。提交前强制读取未决协调消息，未读则阻断，并记录读取率。

第二道是版本校验。提案携带资源版本号，仲裁器比对失败就要求重新读取再提交。

第三道是幂等提交。同一提案ID重复提交只生效一次，避免重试造成重复扣减。

第四道是所有者确认。涉及他人资源或高影响操作时，必须由资源所有者显式确认。

第五道是审计与补偿。每次仲裁留痕，失败可回滚，冲突可重放。

下面是最小工具注册与校验片段，展示提案进入仲裁前的输入检查。

```java
// 用途：MCP工具注册与提交前输入校验的最小示例
@Tool(name = "propose_budget_change")
public Proposal propose(String userId, String resourceId,
                        long version, long delta) {
    if (userId == null || resourceId == null) {
        throw new IllegalArgumentException("identity required");
    }
    if (delta <= 0) {
        throw new IllegalArgumentException("delta must be positive");
    }
    return arbiter.submit(userId, resourceId, version, delta);
}
```

测试断言要覆盖越权与版本冲突，而不是只测成功路径。

```java
// 用途：验证越权拒绝与版本冲突回传
assertThrows(ForbiddenException.class,
    () -> tool.propose("u2", "budget-1", 7L, 100L));
assertThrows(VersionConflictException.class,
    () -> tool.propose("u1", "budget-1", 6L, 100L));
```

![工具调用时序图](https://developer.qcloudimg.com/http-save/yehe-9261324/171a30f987ed0990c089f7a0f7f662f3.png)

---

# 07、复盘：用指标验收，而不是靠感觉

上线后不能只看“Agent有没有回答”。要看群体结果和协作健康度。

群体成功率：多用户并发下，整体任务正确完成的比例。这是第一指标。

个体请求满足率：每个用户自己的请求被正确满足的比例。个人助理场景中，协调器约88%，分散团队约44%。

公平性：各用户等待时长与获批额度的分布，避免强者恒强。

越权率：被拒绝的越权请求占比，按模型与环境分别统计。

消息读取率：提交前关键消息进入上下文的比例，目标应显著高于研究中的47%—67%。

冲突重试与人工接管：重试次数、接管率、平均恢复时间。

上线检查清单：身份凭证是否最小权限；资源是否分片仲裁；版本号是否强制；提交是否幂等；高影响操作是否需所有者确认；未读消息是否阻断；审计是否可回放；补偿是否可执行；指标是否按模型分桶。

---

# 08、洞见：多Agent不是错，缺协调才是

我不否定多Agent。局部任务上，个人Agent理解用户意图的能力确实有价值。

问题在于把“每人一个Agent”当成天然更高效。研究显示，在共享资源场景里，这个假设不成立。

企业真正要建的不是更多Agent，而是资源级的协作基础设施：身份、锁、版本、公平、审计。

这也解释了为什么中央协调不是唯一答案。资源级协调可分片，能兼顾一致性与可用性。

模型差异提醒我们，护栏要按模型与环境配置，不能一套参数打天下。

---

# 09、小结：先修协调，再谈规模

《Worse Together》和MAMUBench给出的不是“多Agent无用论”，而是范围明确的警告。

在API预算、诊所日程、个人助理这些共享资源环境里，分散团队群体结果更差，且伴随行动率下降、消息未读、覆盖与编造。

工程上的回应很具体：个人代理平面加资源级仲裁平面，配身份隔离、消息屏障、版本校验、幂等提交、所有者确认与审计补偿。

先用群体成功率、个体满足率、公平性、越权率、消息读取率验收，再谈扩大Agent数量。

延伸阅读可查Anthropic Fellows《Worse Together》研究的方法与情景章节，以及MAMUBench的环境与指标说明，注意区分论文四类环境与基准三类环境。

我见过最典型的翻车不是模型不会调工具，而是四个人的Agent同时去改同一份API预算。

85:MAMUBench让多Agent协作质量更高？

多个用户的个人Agent争抢共享API预算、诊所日程、团体订单与代码合并队列时，群体结果可能比一个Agent服务多人更差。本文梳理《Worse Together

架构师

人工智能

架构设计

安全

多Agent共享资源场景下团队协作显著失效，API预算重复扣减、消息读取率仅47%—67%。基于《WorseTogether》研究，构建个人代理平面+资源级仲裁平面，以身份隔离、版本校验、幂等提交实现协调。用群体成功率、个体满足率等指标验收，企业应先建协作基础设施再扩展规模。

代码解释

智能体

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

85:MAMUBench让多Agent协作质量更高？-腾讯云开发者社区-腾讯云

85:MAMUBench让多Agent协作质量更高？

85:MAMUBench让多Agent协作质量更高？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐