当两个AI程序员挤在同一个屋子里写代码，会发生什么

你有没有遇到过这种场面：两个人一起收拾房间，结果谁都不知道对方在干什么，一个刚把书架擦干净，另一个转头就把一摞书堆了上去，两人还互相以为对方已经处理完了。

现在把这个场面搬到编程世界里。让两个AI一起写代码，理论上应该是好事,一个人写前端，一个人写后端，效率翻倍。但现实往往是另一个版本的故事：两个AI各自埋头干活,谁也不知道对方写了什么,最后一个AI的文件把另一个的覆盖了，整个项目直接崩掉。

这就是一篇叫《AgentRoom》的论文想解决的问题。它的作者来自Holistic AI公司和加州大学伯克利分校，研究的核心问题是：怎么让多个AI程序员像真正的团队一样协作写代码,而不是各干各的、互相拆台。

大模型写代码,天生就是"一个字一个字"的

要理解这篇论文的价值，得先弄清楚一件容易被忽略的事情。

大语言模型生成代码的方式，本质上是逐字生成的（这里说的"字"其实是token，也就是词元）。

**token**：大语言模型处理文本的最小单位，可以理解成一个词或者一个词的片段，模型每次只能吐出一个token，再根据这个token继续生成下一个。

这个"一个字一个字"的限制，直接决定了目前多智能体编程系统的两种主流套路。一种是像流水线一样，设计智能体先画蓝图，实现智能体照着写代码，审查智能体最后把关，一个接一个地干,前一个不做完,后一个就干等着。另一种是让几个智能体各自独立完成任务，然后把结果凑在一起,谁也不知道别人干了什么。

论文里提到一个很扎心的数据：单个AI智能体面对难任务时，有多达一半的情况会写出一个文件的骨架就撂挑子不干了，判定这个任务太难，直接退出。这种现象论文里给它起了个名字，叫"stub-and-exit"（骨架退出）。

这就好比让一个人独自去装修整套房子，他刚砌完一面墙的地基，觉得工程量太大，直接甩手走了，留下一堆没用的水泥。

如果不解决这个问题会怎样？答案是：单智能体系统在困难任务上会大量浪费算力,机器跑了半天，最后只交出一个能编译但完全没用的空壳。

那为什么不直接借鉴人类团队协作的经验呢？现实世界里，多人同时编辑同一份文档早就有解决方案了，叫CRDT。

**CRDT（无冲突复制数据类型）**：一种数据结构，让多个人（或多个程序）同时修改同一份内容时，各自的修改最终都能自动合并，不会互相覆盖、不会丢数据。Google文档、多人协作白板背后都用了类似的技术。

论文的作者们观察到,已经有人尝试把CRDT用在AI多智能体编程上了，一篇叫CodeCRDT的论文做了这个尝试，让智能体通过读取共享的代码文件来"隐式"推断队友在干什么，结果却是好坏参半：有的任务快了21%，有的任务反而慢了39%。

这个结果挺让人意外的。你可能会想，CRDT不是应该解决合并冲突的问题吗，为什么用上之后反而有一半的情况变慢了？

论文给出了一个关键的洞察：CRDT解决的是"字节层面"的冲突，不是"意图层面"的冲突。

字节合并得了,但"意图"合不上

这里要讲清楚一个非常反直觉的事实，也是整篇论文最核心的技术判断。

CRDT有一个学术上的正式保证，叫"强最终一致性"（Strong Eventual Consistency，简称SEC）。

**强最终一致性（SEC）**：一种技术保证，意思是不管几个人同时怎么改一份文件，最终所有副本都会收敛到同一个结果，不会因为并发编辑而丢失任何一次修改。

这个保证听起来很强大，实际上它只保证了"字节不丢",没有保证"逻辑合理"。

举个论文里的例子：两个AI智能体同时在同一个位置插入了不兼容的函数签名。CRDT会很忠实地把两段代码都保留下来，字节层面完美无损，双方的修改都活下来了。但结果是什么？代码根本编译不过，因为同一个函数被定义了两次，逻辑上互相矛盾。

这就像两个室友同时往冰箱门上贴便利贴留言。一个写"周三倒垃圾"，另一个写"周三我不在家"，纸条都好好地贴在门上，谁都没把对方的纸条撕掉,但这两条信息拼在一起完全是矛盾的，没人知道到底该怎么办。CRDT保证的是"纸条不会消失"，但它没办法让两张纸条的内容自动协调一致。

论文用一个公式来量化这种冲突发生的概率。如果有N个智能体、Kt个候选文件，两个智能体撞上同一个文件的概率大概是：

$$p_{collision}(N, K_t) = 1 - \prod_{k=0}^{N-1}\left(1 - \frac{k}{K_t}\right)$$

在论文的实验设置里（2个智能体、大约5个候选文件），这个碰撞概率大约是20%。也就是说，如果什么都不做，每5次并发写代码的尝试里，大概有1次会撞车。

那怎么解决这个问题？作者们的答案不是继续在CRDT层面做文章，而是给AI团队装一个"协调员"。这个协调员不负责写代码，只负责管理"谁在写什么"。

AgentRoom：给AI团队装一个"任务认领板"

AgentRoom的核心设计其实很朴素，说白了就是给多个AI智能体搭建了一个共享的"房间"，房间里有一块任务认领板。

这个房间由三个部分组成：一个CRDT驱动的共享文件系统（负责字节层面不丢数据）,一个协调接口，暴露给智能体五个工具:room_claim（认领文件）、room_release（释放文件）、room_state（查看房间状态）、room_broadcast（广播消息）、room_read（读取消息）。

**MCP（模型上下文协议）**：一种让AI模型调用外部工具的标准接口协议，可以理解成AI和外部系统之间的"通用插座"，不管是文件系统还是数据库，只要符合这个协议就能被AI直接调用。

这套工具的关键在于room_claim这个动作。当一个智能体想写某个文件之前，先在房间里"认领"这个文件，如果这个文件已经被别人认领了，系统会直接告诉它"这个文件被占了"，而不是让它自己去猜、去读代码推断。

这就是论文里反复强调的一个设计哲学：把"谁负责什么"这件事从依赖AI的智能程度，变成一个系统层面强制执行的规则。

具体来说，两个AI智能体如果都要动同一个文件，系统层面就会直接拒绝其中一个的认领请求，逼着它去找别的活干，而不是任由两人各写各的，最后再靠CRDT去"和稀泥"。

这就像公司里的会议室预订系统。如果没有这个系统，两个部门可能都以为周三下午三点这个会议室是自己的，结果两边人马都杀到现场，尴尬得不行。有了预订系统，一个部门想订这个时间段，系统直接告诉他"已经被占用了"，逼着他去改时间或者换房间。系统本身不聪明，它不理解会议内容，它只是死板地执行"一个时间只能一个人用"这条规则,但恰恰是这种死板，避免了现场撞车的尴尬。

值得注意的是，这个"锁"是"劝告性"的，不是强制的。论文管这叫Chubby式的建议性锁（借鉴了Google内部一个叫Chubby的分布式锁服务的设计思路）。也就是说，即便系统告诉某个智能体这个文件被占了，它理论上仍然可以强行去写，CRDT不会阻止它,只是这种行为会被记录在日志里，事后可以追溯。

为什么不做成完全强制的锁呢？论文给出的理由挺有意思：完全强制的锁会挡住一种特别有价值的行为，就是"跨智能体修bug"。论文附录里有个真实的案例，一个智能体发现队友写的路由代码有语法错误（用了Express 5不支持的写法），它直接冲进去改了队友的文件，改完之后还专门在聊天记录里道了个歉："我动了你的文件，抱歉，是为了修一个卡住所有测试的严重bug"。如果锁是强制的，这次救场式的修复根本不可能发生。

这个设计选择也暴露了论文作者的一个判断：协作规则应该是"建议"而不是"禁止"，因为AI智能体之间偶尔的"越界"行为反而可能是有价值的。这跟人类团队管理有点像，规矩定得太死，反而会错失一些临场应变的机会。

实验怎么测的：五个模型，四个任务，跑了一大圈

说清楚了设计思路，接下来看看这套系统到底管不管用。

论文用了五个主流的编程AI模型：Anthropic的Claude Sonnet 4.6和Haiku 4.5，OpenAI的GPT-5.4和GPT-5.4-mini，谷歌的Gemini 3 Flash。因为GPT-5.4-mini在并发场景下容易崩溃，最终的核心对比只用了四个"CLI稳定"的模型。

任务方面，论文设计了几个不同难度的后端编程任务：T1是做一个JWT身份验证系统（6个文件），T2是做一个市场交易API（至少10个文件），T4是做一个双式记账的金融账本系统，要求支持多币种、哈希链审计、对账和欺诈检测（至少15个文件），T5是做一个算法交易平台（也是至少15个文件的大工程）。

**JWT**：JSON Web Token，一种常用的身份验证令牌格式，服务器发给用户一个加密的"通行证"，用户之后每次请求都带着这个通行证证明自己的身份。

评分方面，论文用了三种打分方式互相印证：一个是LLM裁判打分（用Sonnet 4.6按照固定的评分标准打分），一个是正则表达式扫描代码特征打分，一个是用TypeScript编译器的语法树分析打分。三种方法互相验证的相关系数在0.67到0.79之间，说明结论不是靠单一评分方式撑出来的。

第一个发现：两个AI一起干，比一个AI干更稳、更少放弃

论文里最硬核的一个结论，是关于"放弃率"的。

单个AI在困难任务上，经常会写一个文件的骨架就退出，判定任务太难。论文用一个专门的统计方法（叫Cochran-Mantel-Haenszel检验，简称CMH，一种能把多组不同条件下的数据汇总分析的统计工具）分析了12个"模型×任务"的组合，结果是：单个AI放弃任务的概率，是两个AI组队时的13.7倍。这个结果的置信区间是3.9到48倍，统计上非常显著（p值小于十万分之一）。

换句话说，如果单个AI干这活容易半途撂挑子，那给它配个搭档，撂挑子的概率会直接掉到原来的十几分之一。

具体到某个模型上看更直观。Haiku 4.5单独干活时，35次尝试里有12次直接放弃（放弃率34%），配上搭档之后，17次尝试里只放弃了1次（放弃率6%）。Codex GPT-5.4更夸张，单独干活17次里放弃9次，配对之后21次里只放弃2次。

除了放弃率下降，论文还发现两个AI组队之后，结果的"波动性"也明显变小了。以Sonnet 4.6为例，单独干活的时候，任务质量分的标准差是0.23，配对之后降到0.14，波动幅度收窄了大概40%。Haiku 4.5和Codex GPT-5.4也有类似的表现，标准差都降了30%到45%。

这个现象其实很好理解。一个人单独做事，状态好的时候能超常发挥，状态不好的时候可能直接崩掉，结果忽高忽低。两个人一起做事，即便其中一个状态不好，另一个人也能兜底，整体结果就会更稳定，不会出现太极端的失败。

这就像考试的时候一个人答题和两个人分工答题的区别。一个人独立答一整张卷子，如果碰上不会的题，可能干脆放弃整张卷子交白卷。两个人分工，一个负责选择题一个负责大题，即便其中一人某道题卡住了，也不至于让整张卷子交白卷，因为另一个人负责的部分是独立完成的。

第二个发现：光有CRDT没用,关键在"协调层"

如果第一个发现说的是"人多力量大"，第二个发现要更进一层：光是把两个AI塞进同一个共享工作区里，效果并不好,真正起作用的是那套认领和广播的协调机制。

论文设计了一个六条件对比实验，全部用同一个模型（Sonnet 4.6）在同一个任务（T4金融账本）上跑，保证消耗的计算资源基本相同。六个条件从差到好排列是这样的：

ChatDev式的顺序流水线（设计、实现、审查三个阶段依次交接）得分最低，0.333分。并行合并（两个AI各自独立干活，事后把文件合并起来，谁的时间戳晚就用谁的）得分0.456，这个分数甚至低于单个AI独立干活的0.544分。共享工作区但没有协作提示和工具的条件得分0.575。加上协作提示但没有MCP工具的条件得分0.588。完整的AgentRoom（CRDT加协调工具加协作提示）得分最高，0.669分。

这组数据里最扎心的一条是,并行合并这种"各干各的、最后拼一下"的方式，居然比单个AI单独干活还差。

论文给出的解释是：没有协调机制的时候，第二个智能体的文件会悄悄覆盖第一个智能体的文件,这种并行不但没有把两份工作叠加起来，反而把"半途放弃"这个坏习惯放大了。用论文的话说，"并行合并放大了骨架退出行为，而不是把结果平均化"。

这个发现很有意思，因为它打破了一个直觉上的假设：很多人会觉得，只要让多个AI并行工作，总归比一个AI慢慢磨要快、要好。但数据说明，如果没有协调，并行反而可能比单干更差。这就好比两个人同时往一个水桶里倒水，如果不商量好谁负责倒多少、什么时候停，很可能出现一个人倒得太满溢出来，另一个人干脆没倒进去多少，最后的水量还不如一个人认真倒的多。

那最关键的对比来了：并行合并和完整AgentRoom之间的差距是多少？论文测出来是0.213分的提升，统计检验（Welch's t检验）的t值是3.35，p值是0.003，统计上很显著。因为这两个条件用的是同一个模型、同样的算力预算，唯一的区别就是有没有CRDT共享工作区和MCP协调工具，这个对比干净地证明了：让效果变好的不是"多找一个AI来干活"，而是"给这些AI装了协调机制"。

论文里还专门做了一个"拆解探针"实验，想搞清楚CRDT基础设施和MCP协调工具各自的贡献有多大。结果是：保留CRDT共享区和协作提示、但去掉MCP工具的条件，只比"纯共享无提示"提升了0.013分,而完整AgentRoom比这个条件又多提升了0.081分。换句话说，最大的一步提升发生在加上MCP工具的那一刻,虽然由于样本量较小，这个区间的置信区间跨过了零，作者们谨慎地表示这是一个"排序"结论而不是精确的"百分比拆分"结论,但方向是清楚的：协调层比基础设施本身贡献更大。

第三个发现：结构化状态管理，比自然语言聊天靠谱

论文还做了一个特别直观的对比实验，比较"用自然语言聊天来协调"和"用结构化状态管理来协调"哪个更靠谱。

在T5任务上，用纯聊天方式协调的两个AI（两次跑的样本），失败了一次,失败的原因是两个智能体同时用自然语言喊出了"我要占用这个文件"，结果谁都没意识到对方也在说同样的话，两人写了同一个文件，代码互相冲突，最后测试全部失败，得分只有0.088。而用CRDT状态管理协调的AgentRoom，跑了7次，7次全部成功。

这里的关键区别在于：自然语言的声明，需要对方"理解并解析"才能起作用，而room_claim这个工具调用，是直接返回一个系统级的错误码,你不需要理解对方说的话，系统本身会告诉你"这个文件已经被占了"，不需要任何语言理解的环节。

这就好比两个人抢占停车位。一个人喊了一嗓子"这个位置我先看到的"，另一个人可能没听清、可能没在意、也可能听到了但觉得自己更有理，双方各自开车过去，结果两辆车都堵在那儿。而如果换成一个电子系统，你扫码占位的瞬间系统直接锁定，后面的人扫码时屏幕直接显示"车位已被占用"，根本不需要靠嗓子喊，也不需要对方"理解"你的意思。系统层面的硬性反馈，比语言层面的软性沟通要可靠得多。

第四个发现：多少个AI一起干活是最优解？

论文还测试了智能体数量从1个到4个的变化，结果发现了一个有意思的"倒U型"曲线。

在T4任务上，质量分数随着智能体数量的变化是这样的：1个智能体0.544分，2个智能体0.669分（达到峰值），3个智能体回落到0.553分，4个智能体继续下滑到0.489分。

但如果换一个指标来看，比如测试通过数量，峰值出现在3个智能体的时候。

论文对这个现象的解释和"沟通渠道过载"有关。随着智能体数量增加，广播消息的数量呈超线性增长（不是简单的正比例增加，而是增长得更快），这暗示着单一的广播频道可能存在瓶颈,当所有人都往同一个频道里发消息的时候，信息量爆炸式增长，反而没人能真正跟上进度。

这就像一个项目组开会的场景。两个人开会效率很高，信息传递清楚。三个人开会开始需要有人主持，否则容易同时抢话。到了五六个人开会，如果没有明确的会议规则，很可能开成了一场谁都听不清谁说什么的混乱现场,增加人手带来的是信息过载，而不是效率提升。论文里的智能体数量增长曲线，跟这个道理很像。

不过作者也很坦诚地说，他们并没有专门做过"多广播频道"的对照实验来验证这个猜想，所以这只是一个开放性的推测，留给未来的研究去验证。

和另一位"同行"的比较：CodeCRDT

论文里专门拿出一段来对比CodeCRDT这篇之前的工作，因为两者都用了CRDT作为底层技术，很容易让人以为是同一个思路的延伸。

CodeCRDT走的是"隐式观察"路线：智能体通过读取合并后的工作区代码，自己去推断队友在干什么，而且角色是提前分配好的（一个负责列大纲，一个负责实现细节）。这种方式测出来的效果是"速度提升"或者"速度下降"的两极分化，21%的加速和39%的减速都出现过，语义冲突率在5%到10%之间。

AgentRoom走的是"显式协商"路线：智能体通过房间里的工具主动声明自己要干什么，而不是被动地读代码猜测。测出来的效果差异体现在"文件层面的认领"直接把并发写同一个文件的冲突降到了0%，衡量的重点也不是速度提升，而是"失败模式的消除"。

论文强调这两种思路是互补的，而不是互相替代的。CodeCRDT的字符级合并技术，理论上可以用在AgentRoom内部，服务于"已经被认领的文件"里的细粒度编辑。

跨语言跨领域的验证

一个只在TypeScript和Express.js框架上跑通的结论，说服力有限。论文因此额外做了两个跨领域的验证。

一个是把T4任务从TypeScript转移到Rust和axum框架下重新跑一遍，用Codex GPT-5.4测试。结果是AgentRoom（0.740分）和单智能体（0.714分）基本持平，方向上和TypeScript的结论一致，只是因为样本量太小（4次对5次），统计上没法下定论，只能作为描述性的参考。

另一个是用Python的DevBench测试集（10个真实的多文件Python项目），用Haiku 4.5测试。结果是双智能体版本通过了8个任务，单智能体版本通过了7个，并且整个测试过程中零CRDT语义冲突。有一个任务特别值得一提，叫geotext，单智能体在600秒的预算里超时失败了，双智能体版本用390秒就搞定了。

这两个跨领域实验都是小样本，论文自己也承认单独看都不够有说服力，但两个方向一致的信号叠加起来，说明这个结论不是TypeScript这一个语言生态里的特例。

一些没解决的问题

论文在结尾部分也很诚实地列出了一堆局限性。

比如所有的核心实验都发生在同一个Express.js/TypeScript的运行环境里，跨语言的验证只是初步的、小样本的补充证据，不能说这个结论对所有编程语言都适用。

评分标准是用另一个LLM来打分的，不是靠真实的执行结果来验证正确性，虽然论文交叉验证了三种打分方式，但这终究不是"跑起来能不能用"的硬指标。

同一个模型家族的裁判打分，天然可能会偏爱和自己同源的模型生成的代码，虽然论文专门做了跨供应商的裁判对照实验（用Claude Haiku和OpenAI的Codex GPT-5.4分别再打一次分），发现排序结论基本稳定，但这个潜在偏差没法完全排除。

而且，模型都是托管在云端的商业产品，没法固定随机种子来保证结果完全可复现,如果厂商悄悄更新了模型，实验结果理论上也会跟着变化。

写在后面

读完这篇论文，最让我意外的其实是那个"并行合并反而比单干还差"的结果。我原本的直觉是，只要给AI多配几个搭档，就算彼此不沟通，好歹是多个人在干活，结果应该比一个人强。但数据说的是相反的事情：没有协调机制的并行，反而会把"半途放弃"这个坏习惯放大。

这个发现让我想到一个更普遍的问题：我们在评价"团队协作"的价值时，常常默认"人多"本身就是价值，却忽略了协调本身才是那个真正花钱、真正决定成败的东西。AgentRoom这篇论文的价值，某种程度上就是把这句听起来像常识的话，用实验数据钉死了。

还有一个细节值得单独说一说，就是那份AI之间互相道歉、互相补位的聊天记录。一个智能体闯进队友的文件里改bug，还专门留言道歉，说"抱歉动了你的文件"。这种行为完全没有被明确写进提示词里，是AI自己"学"出来的协作礻仪。这多少让人有点意外,这些语言模型不光是在完成任务，还在模仿人类团队协作时那种"越界了要打个招呼"的社交本能。这算不算是训练数据里那些人类程序员协作记录留下的印记，值得再琢磨。

Q&A

Q1：AgentRoom是什么？

A：AgentRoom是一套让多个AI编程智能体在同一个共享工作区里协作写代码的系统，核心是在CRDT（无冲突复制数据类型）共享文件系统基础上，加了一层文件认领、状态广播的协调工具，让AI之间能像团队一样明确分工，而不是各自埋头干活最后互相覆盖。

Q2：为什么两个AI一起写代码，效果比一个AI单独写更稳定？

A：因为单个AI面对困难任务时，经常会写一个文件骨架就直接放弃（论文里的统计显示放弃概率是双AI协作模式的13.7倍）,配上搭档之后，即便一方状态不好，另一方也能兜底，整体结果的波动性（标准差）也降低了30%到45%。

Q3：光靠CRDT共享工作区，AI协作就能变好吗？

A：不能。论文的实验发现，只给AI一个共享工作区、没有明确的文件认领和消息广播机制，效果反而不如单个AI独立干活,真正让协作变好的是那套显式的"认领文件、广播状态"的协调工具，而不是CRDT这个底层技术本身。