MIT 让三个 AI 合装一间房，斯坦福让两个 AI 共改一个代码库：差的 30% 不是模型，是组织

公司里最容易通过的一笔 AI 预算，常常长这样：一个智能体已经能做事，再加几个，让它们彼此检查、互相补位，效率自然会继续上升。

这个想法太符合人的经验。一个程序员要两周的工作，两个程序员也许能更快；一个人容易漏掉的错误，第二双眼睛可以发现。于是，我们很自然地把人数当成能力，把对话当成协作，把一串在屏幕上滚动的“我同意”“我来处理”当成团队正在形成。

但 2026 年的两组研究，给出了近乎相反的现场。

在麻省理工学院团队开发的 SceneSmith 中，三个承担不同角色的 AI 智能体，可以从一句自然语言描述出发，逐步搭起墙面、摆入家具、填充小物件，最后得到能接受碰撞和稳定性检查的室内仿真场景。论文报告，这些场景里的物体数量是此前方法的三到六倍，物体之间的碰撞低于百分之二，约百分之九十六的物体在物理仿真中保持稳定。

而在斯坦福等机构提出的 CooperBench 中，两名代码智能体各自实现一个功能。两个功能单独做都没有问题，却可能在同一个开源代码库里发生冲突。结果是，它们一起工作时的平均成功率，比让单个智能体把两项任务都做完低了百分之三十。多了一个“同事”，团队反而更差。

这不是一道“哪个模型更聪明”的选择题。两项研究的任务、模型、指标都不相同，不能把一边的成功简单归功于角色设计，也不能把另一边的失败推广成所有机器团队的宿命。

真正值得比较的，是它们怎样组织工作。

多智能体的稀缺资源，可能从来不是更多人手，而是把角色、共享对象、工作次序、承诺和停止条件组织成一个能被核验的过程。

把讨论绑在一个能碰撞、能失败的房间上

SceneSmith 要解决的是一个很具体的难题：家用机器人需要在各种房间里练习，但真实家庭太昂贵、太慢，也太难覆盖世界上千差万别的布置。仿真可以大量制造练习场，可已有的自动生成场景往往过于空旷，缺少抽屉、柜门、杂物和可移动物体。一个对人看起来像样的三维渲染，并不一定经得起机器人伸手。

研究团队没有让一个模型一次性“画完”房间，而是把它拆成连续阶段：先确定建筑布局，再放家具，最后加入小物件。每一阶段，都有三个角色参与。

设计者提出具体布置；批评者寻找不合理之处；协调者根据前两者的意见决定下一步动作。场景也不是漂在聊天记录中的抽象想法，而是一个不断变具体、可以被检查的共享对象。椅子是否穿过桌面，柜门能否打开，物体有没有悬空，都能转化为物理约束。

这里最重要的，不是三个模型“像人一样开会”，而是讨论被牢牢绑在产物上。

建筑阶段结束后，墙和门成为家具阶段的边界；家具摆好后，又成为小物件阶段的支撑面。前一步不是一段容易被遗忘的意见，而是下一步必须服从的世界。批评也不是泛泛地说“请改进真实感”，而要在一个可见场景中指出碰撞、尺度或摆放问题。协调者更像工序控制器：它限制什么时候讨论什么，避免所有角色同时改动所有部分。

论文用二百一十条提示生成环境，并让二百零五名参与者比较视觉结果。相对基线，SceneSmith 的平均真实感胜率为百分之九十二，提示遵从胜率为百分之九十一。团队还把场景接入自动机器人策略评估流程，展示它们可以作为测试环境。

这些数字令人印象深刻，但各自回答的问题必须分开。

用户研究说明参与者更偏爱或更认可这些场景，不等于房间与现实分布完全一致；低碰撞和高静态稳定说明场景更适合物理仿真，不等于机器人在真实厨房就会成功；端到端策略评估说明工具链可以连起来，不等于只用这些合成环境训练的机器人已经获得可靠的家庭能力。

甚至生成本身仍可能需要数小时，柔性物体等复杂对象也在未来工作之列。SceneSmith 不是一个已经替代真实数据的机器世界工厂。它更像一次组织实验：当工作被拆成有顺序的阶段，每个角色拥有明确职责，而且所有意见都要落到一个能碰撞、能失败的共享对象上，多智能体才显出价值。

652 个任务里，AI 同事栽在三件事上

CooperBench 选择了另一种更接近日常办公室的任务。

研究者从十二个开源软件库中构造了六百五十二个协作编码任务，覆盖四种编程语言。每个任务分给两名智能体不同功能。两个功能分别看都能实现，但它们可能修改相同文件、共享接口或影响彼此假设，因此需要沟通和协调。测试由专家编写，用来检查最后的代码能不能同时满足两项要求。

这比让两个模型分别回答两道题更接近真正的团队工作。团队能力并不是答案相加，而是修改共享世界时仍能保持一致。

结果出现了研究者所说的“协调诅咒”：受测智能体一起工作时，平均成功率比单体独立完成两项任务低百分之三十。研究团队把失败拆成三类。

第一类是消息堵塞。智能体会发送模糊、过早、过晚或不准确的信息。“我已经处理好了接口”可能没有说明改了什么；一段关键提醒可能在对方作出冲突修改后才送达。通道里字很多，能改变对方行动的信息却很少。

第二类是承诺漂移。即使沟通看起来有效，智能体也可能不按刚刚商定的方案工作。它答应保留某个函数签名，随后又在局部修改中破坏它。对人类同事而言，承诺是协调未来行动的社会工具；对当前智能体而言，它常只是一段上下文，很容易被下一轮局部目标覆盖。

第三类是错误预期。智能体以为对方会修改某个模块，或以为对方已经理解某项依赖，于是省略必要工作。最危险的并非不知道，而是不知道自己正在依赖一个未经核验的假设。

研究也观察到少数有趣的自发协作，例如角色划分、资源划分和谈判。这说明能力不是完全不存在。但“偶尔出现”与“可以作为生产系统依赖”之间，还有很长距离。

六百五十二个任务也不是整个软件行业。它们来自特定开源库，冲突被有意设计出来，结果受模型、工具、上下文和评测设置影响。我们不能因此说两个 AI 永远不如一个，更不能把百分之三十写成任何企业都将遭受的生产率损失。

CooperBench 真正测出的，是一个经常被产品演示跳过的问题：单体能力通过了测试，并不意味着多个单体放进同一个工作空间后，团队能力也会自动通过。

别比谁更聪明，先答这五个问题

把 SceneSmith 与 CooperBench 放在一起，不是为了做胜负排名。前者生成三维场景，后者修改代码；前者的角色和阶段由系统预先安排，后者故意把可能冲突的工作交给两个自主执行者。它们没有控制相同变量，不能构成严格因果对照。

但这种并置提供了一张很有用的编辑地图。机器团队至少要回答五个问题。

第一，共享对象是什么？

SceneSmith 的共享对象是一间逐步成形、可做物理检查的房间。CooperBench 的共享对象是代码库，但智能体对接口、文件和测试的理解可能不同。如果团队不能指向同一状态，“我们谈的是同一件事”就只是一种礼貌想象。

第二，角色是否真的互补？

给三个智能体分别贴上“研究员”“评论家”“经理”的名字，并不自动产生互补。角色必须对应不同权限和动作：谁可以提出，谁必须检查，谁决定接受或退回，谁不能越过哪个阶段。否则多个角色只是同一模型换了三张名片。

第三，工作是否有可执行的次序？

房间先有墙，再有家具，最后有小物件。这个次序不是开会讨论出来的偏好，而是对象本身的依赖关系。软件开发同样有依赖，只是更隐蔽：接口、测试、数据结构和迁移顺序若没有显式化，两个智能体会把各自合理的局部修改拼成一个不工作的整体。

第四，承诺能否被机器核验？

“我不会改这个接口”不应只留在聊天记录里。它可以变成受保护的文件、接口契约、测试、类型约束或变更锁。人类团队用评审、版本控制、持续集成和责任制度，把语言承诺转换成可见痕迹。机器团队更需要这种转换，因为它们善于生成听起来完成了的叙述。

第五，谁知道什么时候停止？

批评者可以永远找到改进意见，生成者也可以永远重写。没有验收条件，团队会把时间消耗在互相说服上；条件过松，又会把碰撞的椅子或冲突的接口交给下游。停止规则不是琐碎工程，它决定一支机器团队何时把不确定性转移给人。

别数智能体数量，要那张协作证据表

今天的多智能体产品，常用一张组织结构图说服客户：上面是主管智能体，下面有研究、写作、分析、审校多个角色。图看起来像一家公司，因此也暗示它拥有公司的协调能力。

可组织结构图只说明名字和箭头，不说明承诺如何保存、冲突如何发现、权限怎样执行、失败由谁接住。

企业真正需要索取的，不是“智能体数量”，而是一份协作证据表：每个角色能做什么、不能做什么；共享状态放在哪里；一次修改如何让其他角色知道；消息丢失或错误时怎样恢复；冲突由测试、规则还是人解决；最后一次人类批准发生在何处。

如果供应商只能展示几段流畅对话，却不能重放产物状态和决策轨迹，那么团队感很可能只是界面效果。

这也会改变人的工作。多智能体未必立刻减少管理，反而可能制造一种新的协调劳动：核对机器之间的承诺，清理重复或冲突的修改，辨认哪条消息只是自信表达，决定何时撤回权限。过去，经理协调的是有记忆、有声誉、会为失约承担后果的人；未来一段时间，他们可能还要协调不会真正“在意”承诺、却能高速制造承诺文本的系统。

于是，多智能体的社会问题并不在于机器是否已经拥有人的社会性，而在于组织是否把责任错交给了拟人化语言。一个智能体说“我会负责”，责任仍然属于部署它、授予权限并接受结果的人。

先关掉对话气泡，只看三样东西

工业史上，协作效率从来不只是增加工位。流水线的关键是工序，航空安全的关键是检查单与权限，开源软件的关键是版本、测试和评审。组织把个人能力变成共同能力，靠的是一整套常被忽略的中间结构。

AI 让我们重新看见这些结构，因为它先拆掉了人类合作中那些默认存在的部分：共同常识、长期记忆、声誉压力、对失约的羞耻、对同事处境的理解。剩下的每一项，都必须被明确写成系统。

SceneSmith 给出的启示不是“三个 AI 已经会装修房子”，而是当角色围绕一个逐步成形且可检查的世界工作时，协作有机会变成生产力。CooperBench 给出的警告也不是“AI 永远不适合团队”，而是如果我们只把两个能独立完成任务的系统接上聊天通道，冲突不会自动消失，反而可能多出一层看似合作的噪声。

下一次有人展示十个智能体同时工作的宏大屏幕，不妨先关掉对话气泡，只看三样东西：它们共同修改的对象、约束这些修改的规则、失败后留下的可追踪记录。

如果这三样东西不存在，屏幕上再热闹，也未必是一支团队。

参考资料清单

• 《SceneSmith 原论文》，麻省理工学院团队，2026 — https://arxiv.org/abs/2602.09153
• 项目页，2026 — https://scenesmith.github.io/
• 《CooperBench 原论文》，斯坦福等机构，2026 — https://arxiv.org/abs/2601.13295
• 公开数据集，2026 — https://huggingface.co/datasets/CooperBench/cooperbench-dataset