想象一个规模宏大、繁忙的建筑工地，这里没有人类工人，取而代之的是数十个高度专业、相互独立的机器人（AI 编程智能体），它们都在同一时间试图建造或修理同一栋房子。
这篇论文是一份成绩单，记录了当这些机器人在互不沟通的情况下尝试协作时会发生什么。研究人员观察了 GitHub 上数千个真实的开源项目，以了解这些机器人发生冲突的频率、冲突的形式以及造成的混乱程度。
以下是他们研究结果的拆解，使用了简单的类比：
1. 机器人的“交通拥堵”
第一个大问题是：这些机器人在同一时间处理同一栋房子的频率有多高？
答案是：几乎总是如此。
- 研究发现： 在大约 40% 的项目中，有两个机器人正在同一秒钟对同一栋房子进行作业。如果你给它们多一点时间（一个星期的窗口期），这个数字会跃升至接近 95%。
- 类比： 想象一个繁忙的厨房，90% 的厨师都在同一时间对着同一块案板切菜。这很混乱，但却是常态。
- 谁在打架？ 令人惊讶的是，这很少是不同类型的机器人（比如一个“Devin”机器人与一个“Copilot”机器人）之间的战斗。这几乎总是同一种类型机器人在进行自我博弈。在 99.5% 的案例中，冲突发生在两个并行的相同 AI 模型实例之间。这就像是有两对完全相同的双胞胎在试图同时粉刷同一面墙，却没有任何协调。
2. “冲突”（合并冲突）
当两个机器人试图将它们的更改保存到同一个文件时，计算机必须决定保留哪个版本。这被称为“合并”（merge）。如果它们修改了相同的行，计算机就会感到困惑并抛出“冲突”（Conflict）标志。
研究人员模拟了这些合并过程，以观察出错的频率：
- 同类机器人 vs 同类机器人： 当两个相同的 AI 实例尝试合并时，它们大约有 20% 的时间会发生冲突。
- 异类机器人 vs 异类机器人： 当两种不同类型的 AI 尝试合并时，它们的冲突率约为 42%。
- 核心结论： 不同类型的机器人发生分歧的可能性是相同机器人的两倍。然而，由于相同类型的机器人工作最频繁，因此整体上的混乱主要还是由它们引起的。
3. 它们在为什么而争吵？
当机器人发生冲突时，冲突的本质是什么？
- 位置： 大多数冲突发生在源代码（软件的实际指令）中，而不是“购物清单”（依赖文件）或文档中。大约 84% 的冲突发生在代码本身。
- 冲突类型：
- 内容冲突 (58%)： 两个机器人试图修改同一个段落中的同一句话。
- 结构冲突 (42%)： 这是最奇怪的部分。一个机器人决定删除一个文件，而另一个机器人决定修改它。或者，两个机器人都试图创建一个具有相同名称但内容不同的新文件。
- 类比： 这就像一个机器人说：“我要拆掉厨房”，而另一个说：“我要装修厨房”，第三个又说：“我要就在这儿建个新厨房”。他们不可能全都对。
4. 为什么这很重要？（隐藏的成本）
论文指出，虽然我们只测量了“文本层面”的争吵（代码行），但实际成本要高得多。
- “浪费时间”的成本： 因为机器人不知道其他机器人的存在，它们浪费了大量时间去构建那些永远无法合并的功能。
- “人工清理”的成本： 最终，必须由人类介入来收拾残局。人类必须决定哪个机器人是对的，保留哪个文件，以及如何撤销被删除的内容。这完全违背了让机器人干活的初衷。
总结
论文得出结论，目前的 AI 编程智能体就像是在一个共享房间里工作的孤独天才。它们个体表现极其高效，但由于它们互不沟通（即使是同一个模型），它们经常会自己绊倒自己的脚。
- 频率： 它们几乎总是在并发工作。
- 冲突率： 同类机器人冲突约 20%，异类机器人冲突约 42%。
- 混乱程度： 冲突主要集中在代码结构上（如删除 vs 添加文件），而非简单的拼写错误。
研究人员建议，为了让 AI 真正能够协助构建软件，我们需要教会这些机器人如何协调各自的进度，并在开始对同一段代码“挥锤施工”之前学会互相交流。
技术摘要：GitHub 上的 AI Agent 拉取请求 (Pull Requests)
问题陈述
尽管 AI 编程智能体（AI coding agents）已经进化到能够独立进行问题评估、编写修复方案并自主提交拉取请求（PR），但理解并发智能体活动（concurrent agent activity）的影响仍存在一个关键空白。以往的研究主要关注单个智能体输出的质量，或单个智能体的 PR 与其基础分支之间的冲突。然而，目前尚缺乏对多个智能体（或同一智能体的多个实例）同时在同一个仓库中工作的现象进行实证研究。具体而言，现有文献缺乏关于以下方面的数据：
- GitHub 上并发智能体工作流出现的频率。
- 这些同时进行的工作流发生相互冲突的可能性。
- 这些冲突的结构性质（例如：文本冲突 vs. 语义冲突）。
本文旨在解决自主开发中“架构”与“文本”之间的“协调差距”（coordination gap），指出虽然版本控制工具可以检测行级别的文本冲突，但它们无法本质上解决多个自主开发者之间冲突的意图。
研究方法
本研究利用了 AIDev-pop 数据集，该数据集包含 2,807 个仓库中的 33,596 个 PR。作者采用了由四个部分组成的实证方法：
- 共活动性形式化（Co-activity Formalization）： 作者根据时间重叠定义“共活动”（co-active）PR。一个 PR Pi 由其所属仓库、作者智能体、开启时间（Topen）和关闭时间（Tclose）定义。如果两个 PR 的活动窗口 [Topen−k,Tclose+k] 重叠，则认为它们是共活动的。研究针对四种时间填充阈值（k∈{0,1,3,7} 天）进行了分析。
- 分层抽样（Stratified Sampling）： 为了避免受高活跃度仓库的影响而导致结果偏差，作者创建了一个用于合并回放（merge replay）的分层样本：
- A 层（智能体内/Intra-agent）： 625 个仓库，每个仓库贡献一对来自同一智能体的 PR 对。
- B 层（跨智能体/Cross-agent）： 所有显示出跨智能体活动的 122 个仓库，每个仓库贡献一对来自不同智能体的 PR 对。
- 总样本： 747 个唯一的共活动对。
- 大规模合并回放（Large-Scale Merge Replay）： 作者开发了一个使用 headless
git merge-tree 功能的自动化多线程处理过程。该过程在内存中模拟三路合并，而不触碰工作目录。该过程获取两个 PR 的头提交（head commits），识别共同祖先，并尝试进行合并。
- 冲突检测： 返回码
1 表示存在文本冲突。系统会提取冲突的文件路径和冲突类型（例如：content、modify/delete、add/add）。
- 范围： 本研究严格关注文本冲突（第 1 层）。作者指出，这提供了一个总系统摩擦力的“保守下界”，因为构建冲突（第 2 层）和语义冲突（第 3 层）只有在文本合并成功后才可能发生。
- 分类法分析（Taxonomy Analysis）： 冲突按文件类型（源代码、依赖项、配置等）和结构类型（内容重叠 vs. 结构性变化，如文件删除）进行分类。
核心贡献与结果
1. 并发频率 (RQ1)
并发的智能体活动普遍存在。
- 严格重叠 (k=0)： 40.2% 的仓库包含至少一对共活动 PR。
- PR 级普遍性： 79.4% 的智能体生成的 PR 与另一个智能体 PR 同时处于开启状态。
- 扩展窗口： 当允许 ±7 天的窗口时，53.4% 的仓库和 95.0% 的 PR 表现出共活动性。
2. 共活动性的构成 (RQ2)
绝大多数并发属于智能体内（intra-agent），而非跨智能体（cross-agent）。
- 智能体内： 99.5% 的共活动对由同一个智能体模型生成。
- 跨智能体： 仅有 0.5% 的对涉及不同的智能体，分布在仅有的 122 个仓库中（约占 4.3%）。
- 主导地位： OpenAI Codex 是并发的主要驱动力，由于其高吞吐量，它在跨智能体交互中充当了“多数锚点”（majority anchor）。
3. 合并冲突率 (RQ3)
在合并并发的智能体 PR 时存在显著摩擦，且在智能体内与跨智能体场景之间存在明显区别：
- 智能体内冲突率： 19.8% (119/601 对)。
- 跨智能体冲突率： 41.7% (48/115 对)。
- 统计显著性： 这两种速率的 95% 置信区间互不重叠，表明两类场景在冲突可能性上存在明确差异。
4. 冲突结构与分类学
冲突的本质揭示了深层的协调失败：
- 文件类型： 84.4% 的冲突文件是源代码，这反驳了“依赖项清单（dependency manifests）是冲突主要来源”的假设。
- 结构 vs. 内容：
- 57.6% 是内容冲突（对相同行进行不同的更新）。
- 41.9% 是结构冲突（26.8% 为
modify/delete，15.1% 为 add/add）。
- 启示： 智能体经常在“一个文件是否应该存在”的问题上产生分歧，或者独立创建了同一个新文件的不同版本，这表明它们缺乏对并行操作的感知。
5. 相关性分析 (RQ4)
- 吞吐量： PR 级的共活动性随仓库吞吐量的增加而增加（从低吞吐量仓库的 ~53% 增加到高吞吐量仓库的 ~90%）。
- 智能体： Devin (82.5%) 和 OpenAI Codex (80.9%) 显示出最高的 PR 级共活动率。
- 语言： Go (92%) 和 Ruby (87%) 仓库显示出最高的共活动率，而 C++ (56%) 和 HTML (44%) 最低。
重要性与主张
本文声称提供了首次对并发智能体提交的实证检查。其主要意义在于挑战了这样一个理论假设：即多智能体编排目前是一个异构厂商协调的问题。相反，数据表明，主要的运营问题在于管理来自单个智能体框架的高频输出。
作者断言：
- 缺乏感知： 当前的智能体在运行时是孤立的，缺乏“水平意识”（horizontal awareness），无法感知正在修改相同文件的其他智能体（即使是同类型的智能体）。
- 保守估计： 报告的冲突率（19.8% 和 41.7%）是保守下界。它们仅代表文本冲突；实际成本还包括未衡量的构建失败、语义矛盾、CI/CD 计算资源浪费以及 Token 预算消耗。
- 结构性分歧： 高比例的结构冲突（modify/delete, add/add）表明，智能体不仅仅是在编辑行，而是从根本上对仓库的结构产生了分歧，这是一个简单的代码审查难以解决的问题。
研究结论认为，对于现代自主工程而言，未经协调的反应式开发范式是不够的，未来的研究必须聚焦于程序化编排（programmatic orchestration）和实时工作空间通信协议（live workspace communication protocols），以减轻这些集成摩擦。
每周获取最佳 computer science 论文。
受到斯坦福、剑桥和法国科学院研究人员的信赖。
请查收邮箱确认订阅。
出了点问题，再试一次？
无垃圾邮件，随时退订。