消息还没读完，AI已经下单：多人助理测试暴露“抢跑结账”

一群AI替大家一起点餐，关键要求已经发给负责下单的助手，它却可能还没读到就结账了。Sahan Paliskara、Nattaput Namchittai与Andrew Lampinen在9月30日公开的研究中发现：模拟集体点餐、预订和旅行安排时，让一个AI统一服务所有人，落实特定用户要求的频率约为“每人一个AI”的两倍。

这项名为MAMUBench的研究关注一种容易被忽略的场景：每个助手都在替自己的用户做事，却要共用一个购物车、一笔预算或一张日历。研究覆盖77个场景、4类环境，并比较多款模型。个人助理部分有25个场景，包括只要配菜、愿意多付钱替同伴减负，以及与健康安全有关的要求；测试里的订单和预订都是模拟的。

问题不只是助手之间不会聊天。在已经提交订单或预订的团队实验中，关键要求在94%至99%的回合里发给了最终提交者，但真正提交时，该要求进入它上下文的比例只有47%至67%。即使已经读到，要求也不一定被落实。团队还会改掉别人的选择：不同模型中，65%至77%的回合至少出现一次违反这项要求的操作。

研究者试过加一个“队长”，结果在点餐和预订任务里，改善幅度与直接重跑失败实验相近。更有效的是给结账按钮加一道程序检查：只要还有未读消息，就不准提交。这一措施在重新运行此前失败的回合时，挽回了Claude Opus 5的73.1%和Claude Sonnet 5的62.3%。这些百分比是失败回合的恢复比例，不是全体订单的新成功率。

实验还发现，多个助手之间会出现没有依据的“某人同意了”之类说法。相关虚构与同意判定由Claude模型评审，尚未用人类评审验证；研究也没有证明某一种行为单独造成了全部成绩差距。真实用户、真实平台和更新模型的表现仍需另测。

这给日常AI服务提出了一个很具体的要求：替一桌人下单，不仅要会选菜，还得把每个人的限制传到最终操作之前。把未读消息拦在结账前，比简单增加助手数量更值得测试。对使用者来说，过敏、时间和费用分担等关键条件，仍应在最终确认页面逐项核对。

本文依据Sahan Paliskara、Nattaput Namchittai、Andrew Lampinen的论文独立改写并压缩技术细节。原论文采用CC BY 4.0许可：https://creativecommons.org/licenses/by/4.0/。

原文发布时间：arXiv，北京时间2026年10月1日02:49:25／美国东部时间2026年9月30日14:49:25（EDT）。