智能体在读完同伴消息前就替全组下了单

一组人凑一单外卖，各让自己的智能体往同一个购物车里加菜，其中一人只要一份配菜。这条消息发出去了，负责结账的智能体却在读到它之前就付了款。

这是 Anthropic Fellows 项目 11 月 11 日发布的研究里反复出现的一幕。研究把「每人一个智能体、共用一份资源」放进四个模拟环境，各为其主的团队结果都不如一个替所有人办事的总管。

我们的判断是，这类产品的可靠性不能交给模型自觉，平台必须在提交前设硬关卡。

要求送到了，下单的智能体还没读

据 Anthropic 博客，在外卖、订餐厅和订行程这组 25 个场景里，一个总管兑现那条特别要求的次数，约是每人一个智能体的团队的两倍。

问题出在时间差。论文给出的数字是：

• 那条要求在 94% 到 99% 的情况下已经发给了下单的智能体；
• 下单那一刻，它真正在上下文里的只有 47% 到 67%；
• 读到了的，要求被兑现 56% 到 68%；没读到的，只剩 19% 到 36%。

团队里还常有人改掉别人的要求。至少一次这类改动出现在 65% 到 77% 的团队回合里。

16 人共用预算时，多数智能体一直没动手

另一个环境是研究员共用一晚的模型调用预算，预算不够所有任务用。据 arXiv 论文，Claude Opus 5 的团队只拿到最优结果的 30%，它当总管时是 64%；Claude Sonnet 5 是 12% 对 32%。

团队越大越不动。从 4 人到 16 人，Sonnet 5 团队里出过手的智能体从 66% 降到 10%，OpenAI 的 GPT-5.6-sol 从 82% 降到 25%。另一种失败是乱动手：GPT 和阿里 Qwen 的智能体每回合未经同意砍掉别人任务 3.9 到 7.1 次，Sonnet 5 是 0.59 次，Opus 5 一次没有。

这一点 Anthropic 的模型确实做得更好，但它的团队照样远远落后于总管。

管用的是一道结账关卡，不是多写几条规矩

修法因环境而异。共用预算时，加一个按价值排优先级的组长，差距就能补上。到了凑单场景，组长没用：只让组长结账，挽回的失败回合和重跑一遍差不多。

真正起作用的是平台层的一道关卡：没读完所有待读消息，就不准结账。论文称，它挽回了 Opus 5 失败回合的 73.1%、Sonnet 5 的 62.3%。把「别覆盖同伴、别提前结账」写进 AGENTS.md 也有改善，但仍明显不如总管，覆盖行为依旧存在。

这正是产品已经走到的地方。博客自己举了 DoorDash 的命令行工具：几个人的智能体可以往同一个群购物车里加东西。

裁判也是 Claude，这份成绩单要打折读

这项研究出自 Anthropic 自己的项目，裁判也用自己的模型。智能体有没有编造关于别人的说法，由 Claude Opus 5 判定：至少出现一次的回合，Opus 5 团队占 58%，Sonnet 5 团队占 53%，单个智能体是 17% 到 20%。

论文在局限一节承认，这些 Claude 裁判没有和人工判断做过比对。Brocker 的解读同样指出，Claude 当裁判可能影响跨厂商比较，需要外部复跑。

有人会说，这只是模拟环境。我们接受这一点：场景由大模型流水线生成，环境也是简化的。但这些场景本来就设计成单个总管能做好，团队的失分主要来自协调本身。它削弱的是跨厂商排名，削弱不了「团队不如总管」这个方向。

另一个让人不舒服的事实是，Anthropic 在博客里把跨会话消息等功能写成趋势，自家项目却测出自家模型组队时，一半以上回合出现编造。

功能上线的速度已经跑在这类关卡前面，这是分析推断，依据是博客列举的群购物车、频道智能体等产品都已发布，而它找到的修法只在实验环境里验证过。

回到那张只要配菜的购物车

那个只要配菜的人，消息已经送达，结账的智能体也读得懂。它缺的是一条规则：没读完就不许付钱。多人共用的智能体产品，先该装的是这道闸，不是一个更会聊天的模型；没有这道闸，每个人的要求都只是发出去了，没人保证被读到。