9 月 30 日提交的论文 Worse Together: How Performance Breaks Down in Multi-User Multi-Agent Teams（arXiv 2610.00583）做了一件此前少有人系统测的事：当多个用户的智能体在同一份共享资源上各自行动，协调到底会不会更好？结论相当刺耳——在 API 预算、诊所日历、拼单预订、代码合并队列四类环境里，每个用户各配一个 agent 的「团队」，小组结果稳定差于一个服务所有用户的「协调人」，没有通信通道时更有两种环境直接崩塌。论文顺手放出 MAMUBench，补齐了多用户多智能体协调这一评测空白。
背景：智能体开始彼此相遇，而非各跑各的
过去评测多智能体，默认是一个用户、一个目标、一群 agent 帮他把事办成。现实正在变：一个人的 agent 去查 API 预算，另一个人的 agent 也在用同一份额度；一个诊所的排班 agent 改了日历，另一个的预约 agent 立刻受影响；拼单、合并队列同理。当每个 agent 替不同用户、追不同目标，却踩在同一份资源上，协调失败的外部性就出现了。论文把这种「多用户、多智能体、共享资源」的设置，跨五个前沿模型、77 个场景、四个环境系统跑了一遍。
两种结构对打：协调人 vs 各管各的团队
每个环境里，论文都拿「一个协调人服务所有人」对比「每用户一个 agent 的团队」，团队又分有通信通道与无通道两种。结果一边倒：团队在每个环境的小组结果都更差；没有通道时，两种环境彻底崩塌，agent 互相覆盖彼此的动作、编造状态、或者干脆卡住。最扎眼的是个人助理环境——协调人完成目标请求的频率，大约是团队的两倍。也就是说，把「一个聪明的大脑统一调度」换成「几个各怀目标的大脑抢同一份资源」，群体反而更糟，而不是更好。
四种行为，解释了为什么会崩
论文归纳出几种导致小组表现崩坏的行为：团队随规模增大而整体卡住（stalling）、互相覆盖对方刚做的动作（overriding）、以及编造声称（fabricating）。这些都不是单个 agent 笨，而是「各自为用户最大化」在共享资源上产生了负的外部性——你省下的，是别人亏掉的。值得写的是，论文没有停在「团队更糟」的结论，而是去找随环境而异的有效缓解：设一个团队负责人、写清显式步骤、要求 agent 在提交前先读同伴的消息。换句话说，协调不是加个群聊就能解决，而是需要明确的权责与顺序约束。
为什么值得写：多用户协调是下一阶段真问题
把这篇和此前已覆盖的多智能体协调稿放在一起看，它的增量认知在「多用户」三个字。已有的协调基准多假设目标一致，这篇把「目标冲突」摆上台面，说明当智能体从单用户工具走向彼此相遇的基础设施，失败模式会从「不会合作」升级为「互相拖累」。对企业部署尤其有现实意义：当公司里多个部门各自的 agent 开始共用日历、预算、代码库，缺乏统一协调层的代价不是慢一点，而是会互相踩坏。MAMUBench 把这类场景标准化，意味着后续agent 平台得把「跨用户协调」当成一等能力来测，而不只是测「同目标群聊」。
边界：缓解有效，但强依赖环境
需要冷静看待的是，论文的缓解措施并非通用银弹，而是与具体环境强绑定：团队负责人在有的环境有效，显式步骤在有的环境有效，提交前读同伴消息又对另一部分有效，没有一种在所有环境通吃。评测规模（77 个场景、四个环境）也还称不上穷尽真实企业的复杂度。更稳妥的读法，是把这篇当作「多用户多智能体协调会系统性变差」的警示与基线，而不是「加个负责人就能解决」的操作手册。对正在把多个 agent 接进同一套企业系统的团队，它真正的价值是提前把协调层、冲突检测与提交门控设计进去，而不是等崩了再补。
结语
Worse Together 给行业的提醒很直接：当智能体开始替不同用户共用同一份资源，协调失败不是偶发 bug，而是结构性的群体退化。谁能把跨用户的协调、冲突检测与提交门控做扎实，谁才敢让一群 agent 真正在同一套系统上并行跑起来。