Why Are AI Agent Involved Pull Requests (Fix-Related) Remain Unmerged? An Empirical Study
这项实证研究分析了来自五个 AI 编程智能体（AI coding agents）的 8,000 多个与修复相关的拉取请求（pull requests），旨在指出测试用例失败和重复的问题解决是阻碍合并的主要障碍，而构建失败却很少见，从而凸显了当前 AI 智能体的关键局限性以及改进软件维护中人机协作的方向。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下，一个软件项目就像是一个繁忙且巨大的建筑工地。其中的“维护者”（maintainers）是现场经理，他们决定哪些蓝图可以被建造，哪些应该被扔进垃圾桶。最近，他们开始雇佣 AI 智能体（就像是机器人助手）来绘制修理计划（称为“拉取请求”或“PR”）以修复建筑中损坏的部分。
这篇论文就像是一份侦探报告，在追问：“这些机器人助手提交的修理计划到底有多少会被批准？当它们没被批准时，原因又是什么？”
以下是他们的研究结果，使用了简单的类比：
1. 大局观：成功率
研究人员观察了超过 8,000 份由五种不同类型的 AI 机器人（OpenAI Codex、GitHub Copilot、Devin、Cursor 和 Claude Code）提交的修理计划。
- 好消息： 大约有 65% 的时间，现场经理说：“好，按这个建！”并合并了修复方案。这些机器人做得相当不错。
- 坏消息： 大约有 26% 的时间，经理们说：“不行”，并在没有建造方案的情况下将其关闭。另有 9% 的方案仍停留在候诊室，尚未定论。
- 机器人的差异： 并非所有机器人都是平等的。
- OpenAI Codex 是优等生：它的批准率高达 81%。
- Devin 表现最差：它的批准率仅为 43%，这意味着它一半以上的修理计划都被拒绝了。
2. “为什么”：为什么计划会被拒绝？
研究人员深入挖掘了这 326 份被拒绝的计划，以找出失败的具体原因。他们发现了 12 个不同的原因，并将它们归纳为三大类：
A. “修错地方”的问题（技术问题）
有时机器人试图修复一个漏水点，但实际上却弄坏了水管。
- 测试失败（最常见的技术原因）： 机器人的修复方案通过了它自身的逻辑检查，但未能通过项目严格的安全测试。这就像一位厨师做了一道菜，看起来很棒，但当卫生检查员（测试套件）品尝时，味道却很糟糕。
- 不完整或错误的修复： 机器人猜错了问题所在，或者只解决了一半的问题。
- 构建/部署失败： 在极少数情况下，修复方案极其糟糕，以至于整个建筑甚至无法组装起来（无法编译或运行）。
B. “时机不对”的问题（流程问题）
有时修复方案本身是好的，但时机不对。
- 有人抢先一步（拒绝的首要原因）： 这占到了案例的 22%。机器人正努力修复一扇破损的窗户，但人类（或另一个机器人）早在五分钟前就已经把它修好了。机器人的计划被拒绝仅仅是因为它是多余的。
- 不活跃： 机器人提交了一个计划，但随后就保持沉默。经理们等得不耐烦了，于是关闭了该工单。
- 优先级低： 机器人尝试修复的问题已经不再重要，或者项目经理决定忽略它。
C. “沟通中断”的问题
- 无人评审： 机器人请求进行评审，但从未有任何人类经理查看它。
- 无解释的拒绝： 计划被关闭了，但没有任何解释，让机器人（以及研究人员）对失败的原因一头雾水。
3. “速度”因素
研究人员还测量了从计划提交到获得批准所需的时间。
- 快速合并： 许多优秀的修复方案很快就得到了批准。
- 缓慢合并： 一些修复则耗时较长。有趣的是，“优等生”（OpenAI Codex）的审批时间最为稳定且快速，而其他机器人则表现出更不可预测的等待时间。
总结
论文的结论是，虽然 AI 机器人写代码的能力正在提高，但 仅仅会写代码是不够的。
要在现实世界中获得一份修理计划的批准，机器人需要：
- 通过严格的安全测试（而不只是看起来不错）。
- 不重复人类或其它机器人已经完成的工作。
- 与人类经理保持积极的沟通。
目前，最大的障碍不在于机器人能否编写代码，而在于它们经常无法通过测试，或者在工作流程的节奏中被他人抢占先机。这项研究表明，要让 AI 真正成为可靠的“虚拟队友”，它不仅需要提升写代码的能力，还需要更好地理解项目的上下文环境以及工作流的时机问题。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。