有人评，才合得进去：智能体拉取请求怎么过代码评审

本文是论文 When AI Teammates Meet Code Review: Collaboration Signals Shaping the Integration of Agent-Authored Pull Requests 的中文译文，由智测团队翻译。会议是第 23 届国际软件仓库挖掘会议（MSR 2026），2026 年 4 月 13 日至 14 日，巴西里约热内卢。DOI 是 10.1145/3793302.3793561。作者是爱达荷州立大学的 Costain Nachuma（costainnachuma@isu.edu）和 Minhaz F. Zibran（zibran@isu.edu）。许可是 CC BY。参考文献未逐条展开。这是对公开 AIDev 数据集的经验研究，不是新的编程智能体实验。回归结果是关联，不是因果。森林图里的优势比没有以数字写进正文，译文不补图上读不出的数值。

摘要

自主编程智能体越来越多地在 GitHub 上提交拉取请求，但这些贡献如何进入由人驱动的评审工作流，所知仍然很少。作者用公开的 AIDev 数据集，对智能体撰写的拉取请求做大规模经验研究，看集成结果、解决速度，以及评审时的协作信号。逻辑回归使用按仓库聚类的标准误。评审者是否介入，与成功集成的相关最强；变更更大，以及破坏协调的动作（例如强制推送），与更低的合并可能相关。一旦把协作信号放进模型，迭代强度本身的解释力有限。定性分析进一步表明，成功集成发生在智能体进入可行动的评审回路、并且向评审者的预期收敛的时候。有效集成不只取决于代码质量，还取决于是否对齐既有的评审和协调实践。

关键词：人工智能；拉取请求；自主编程智能体；合并；接受；协作；代码评审；代码搅动；GitHub；经验研究。

1 引言

自主编程智能体正在参加日常软件开发。它们不只是代码生成工具，还会在 GitHub 上提交修缺陷、加功能和扩展测试套件的拉取请求。人因此经常要评审、仔细解释，并集成非人类贡献者写的变更。

基于 AIDev 的近期大规模研究，记录了智能体撰写的拉取请求增长很快，也给出了跨项目的合计合并率。作者指出，采用本身不等于有效协作。在基于拉取的开发里，集成结果既反映变更在技术上对不对，也反映贡献者如何进入评审工作流、迭代周期和协调规范。自主智能体能不能在这些社会技术过程里当有效协作者，而不只是产出正确补丁，仍然不清楚。

两个缺口推动这项研究。第一，智能体拉取请求越来越常见，但还缺少对它们有多可靠地被集成、以及要多久才有决定的清楚了解。第二，在智能体身份之外，关于哪些评审时协作信号与成功集成相关，经验证据有限。这些信号包括迭代行为、评审者参与、测试活动和协调稳定性。尽管基于拉取的开发已有大量研究，自主智能体如何进入这些评审时协作过程，经验证据仍然少。

软件开发转向人与人工智能混合的团队时，补上这些缺口是必要的。智能体要当有效协作者而不是孤立的补丁生成器，就必须对齐代码评审里隐含的社会期望和程序期望。本文把集成看成由人的评审和协调居中调节的社会技术过程，而不是只把拉取请求当代码制品。两个研究问题是：

RQ1：在智能体撰写的拉取请求里，合并、关闭但未合并、仍然开放的比例各是多少？已经有决定的请求要多久才到达决定？度量是三类份额，以及决定时间的平均数和中位数。

RQ2：哪些评审时协作信号与智能体拉取请求的集成相关？焦点是迭代强度、测试行为、评审者参与和协调稳定性，都来自 GitHub 的评审时痕迹。信号包括：提交次数（分桶）、代码行变化量、改动文件数、是否添加了测试、是否强制推送、是否有评审，以及到第一次评审的时间。

2 数据集与操作定义

数据集快照用的是 AIDev 里智能体撰写的拉取请求，来自 Zenodo 第 3 版，访问时间是 2025 年 11 月。同时引用数据集记录和配套预印本（Li、Zhang 和 Hassan，2025a、2025b）。全部 Parquet 表从 Zenodo 第 3 版取得，在内存里的 DuckDB 上绑成视图。用到的表包括 pull_request、pr_task_type、pr_commits、pr_commit_details、pr_reviews、pr_timeline、repository 和 user。

分析聚焦数据集作者建议的热门仓库子集：至少 100 个 GitHub star。这个子集有 33,596 条智能体撰写的拉取请求，来自 1,797 名不同开发者、2,807 个仓库，跨越多个编程智能体。

一条请求算智能体撰写，是指它出现在 pr_task_type 里，且智能体标签非空。除非另有说明，所有统计都在这个集合上计算。数据集不区分自主提交和由人唤起的智能体提交，因此作者把所有智能体撰写的请求一视同仁。

结果直接从 GitHub 时间戳推出，以避免接口状态字段的含糊。merged_at 非空则合并。closed_at 非空且 merged_at 为空则关闭但未合并。两者都为空则仍开放。对已解决的请求，决定时间在有合并时间时取合并时间，否则取关闭时间。时间戳都归一化到 UTC。

决定时间是从 created_at 到决定时间戳的经过时间，只对已解决的请求计算。生存时间右偏，所以同时报告平均数和中位数。份额使用 Wilson 得分 95% 置信区间。相对正态近似，它在二项比例上覆盖更可靠，尤其靠近边界时。

复现包包含重现结果所需的全部脚本（Nachuma 和 Zibran，2026）。RQ1 用 python run_rq1.py --config config.yaml。RQ2 先构造特征，再用所给脚本拟合回归。

3 集成与解决（RQ1）

3.1 动机

拉取请求是现代基于拉取的开发里集成变更的主导机制。先前工作表明，合并与否既反映技术过程，也反映评审中的社会过程。自主编程智能体已在大规模提交请求，因此需要一条基线：不同智能体的集成率是否可比，以及它们多快到达决定。这条基线锚定后面的分析。

3.2 方法

对每条请求，结果仍按上一节的时间戳规则定义。总体和分智能体报告份额，并给比例配 95% 置信区间。已解决请求（合并，或关闭但未合并）的决定延迟用平均数和中位数概括，以照顾拉取请求生存时间常见的偏态。

关于回退的探索性说明：回退是合并后问题的不完美代理。仓库级信号可能来自重构、重新设计或其他维护，而不一定是缺陷。因此作者不把回退当主要结果，分析集中在评审时的集成和协作动态。

3.3 结果

33,596 条请求跨越 5 个编程智能体。71.5% 被合并，21.6% 关闭但未合并，6.9% 在数据采集时仍开放。合并份额的 95% 置信区间是 [0.710, 0.720]。多数请求到达了集成，但仍有相当一部分没合并或尚未解决。

分智能体的结果率相差很大，说明拉取请求质量和与评审者预期的契合都不均匀。正文给出的例子是：OpenAI Codex 合并份额最高，82.6%；Copilot 低得多，43.0%；Devin 在中间，53.8%。开放份额也不同，例如 Copilot 的仍开放比例明显高于其他智能体，说明解决动态或分诊实践不同。图 1 还列出 Cursor 和 Claude Code。这两个的合并率、关闭率和开放率只画在图里，HTML 正文没有印出数字，译文不从图上估读。

决定延迟的差别比合并率更大。在已解决的请求里，OpenAI Codex 到达决定极快：中位数小于 1 小时，平均数约 19.4 小时。Copilot 和 Devin 更慢：中位数分别是 13 小时和 9 小时，平均数都超过 80 到 100 小时。原文把两个平均数写成同一个区间，没有分别给出，译文保持这个写法。这暗示评审努力和与仓库规范的对齐程度不同。

3.4 小结

RQ1 建立了智能体拉取请求集成和解决动态的基线。总体而言多数会合并，但成功与否和决定速度在智能体之间差得很大。这些差别推动下一问：除了智能体能不能产出能工作的代码，人的评审者承担的交互和协调成本，可能是决定是否集成、以及多快集成的关键因素。

4 协作信号（RQ2）

4.1 动机

RQ1 已经显示集成结果和决定延迟在编程智能体之间差很大。在身份之外，问题是哪些评审时协作信号与成功集成相关。先前工作表明，评审者同时依靠技术和社会线索，例如变更大小、评审者参与和协调稳定性。作者检验类似信号是否也塑造智能体请求的接受。

4.2 方法

把集成建成二元结果：合并，对关闭但未合并。仍开放的请求不进这个回归。预测变量限于最终决定之前、在 GitHub 痕迹里可见的评审时信号，抓住三件事：迭代和变更幅度、协调稳定性和过程信号、评审者参与。用逻辑回归估计这些信号与合并决定之间可解释的关联。智能体指示变量用来控制不同编程智能体之间的系统差异。Claude Code 是智能体指示变量的参照类。

变更幅度用对数变换的代码搅动，即 log(1 加行变化量)，以及修改的文件数。协调稳定性用评审期间是否发生强制推送的二元指示。测试行为用测试文件是否被修改的二元指示。评审者参与用是否至少收到一次评审，以及到第一次评审时间的对数。迭代强度在模型 A 里用提交次数分桶，在模型 B 里用提交次数的对数。与规模有关的变量都做 log(1+x)，以处理偏态。模型使用按仓库聚类的标准误，报告优势比。结果解释为关联，不是因果效应。

4.3 结果

图 2 是逻辑回归预测变量的森林图。横轴是对数尺度上的优势比。两个模型里方向一致的效应，被作者当作稳健性。正文没有列出各系数的优势比数值，下面只转述方向和相对强度。

评审者参与主导集成结果。两个模型里，至少收到一次评审是与合并相关最强的因素。得到评审者注意的请求，集成的优势大幅更高。作者的解释是：评审者会选择性地把努力投到他们认为可行的变更上。

破坏协调的行为受到惩罚。评审期间的强制推送稳定地与更低的合并可能相关。强制推送有时是仓库卫生所要求的，例如压缩或变基政策，但在评审进行中改写历史，会扰乱共享理解，提高评审者的协调成本。

变更越大，评审负担越重。即使控制了智能体身份和评审者参与，更大的变更仍更不容易被合并。这与先前的拉取请求研究一致，也说明评审者对智能体贡献和人类贡献使用类似的风险启发式。

迭代和测试的独立效应有限。一旦计入评审者参与和协调稳定性，迭代强度和添加测试都与合并结果没有显著关联。多改几版或加上测试，若没有降低评审者的不确定性，本身不会提高集成可能。

到第一次评审的时间反映的是工作流动态。在已经收到评审的条件下，到第一次评审的时间更长，与合并正相关。作者认为这更可能反映仓库层面的优先级，而不是推迟评审本身有好处。

综合起来，评审者奖励那些降低协调成本的智能体行为，惩罚那些扰乱共享理解的行为。成功集成较少取决于活动量，较多取决于是否对齐代码评审的社会规范和程序规范。把这些模式和完全由人撰写的拉取请求比较，是重要的未来工作。本文没有做这个对照。

4.4 定性跟进

回归指出哪些信号与结果相关，但没有解释这些信号在评审中如何显现。作者因此分析了 60 条智能体拉取请求，抽样同时是随机的和有目的的，合并与未合并都有。编码本事先根据拉取请求评审文献和对智能体评审线程的试探性检查订好。每条请求只赋一个主代码，抓住影响结果的主导评审时机制。分歧通过讨论解决。表 1 汇总结果。

可行动的评审回路是主导的成功模式：32 条里 30 条合并、2 条未合并。样本里全部 30 条被合并的请求都落在这一类。这些情形里，评审者给出具体反馈，智能体用有针对性的修订向接受收敛。这解释了评审者参与与合并之间很强的正相关。

所有未合并的请求都对应失败机制。设计或架构分歧反映与项目原则不对齐。协调中断（例如强制推送）扰乱评审上下文。这些模式直接对应回归模型里的负关联。

被标成不完整的解，或被流程约束挡住的请求（例如政策或仓库状态），一致地没能合并。这说清了为什么在计入参与和协调稳定性之后，单靠迭代不能改善结果。

与定量结果一致：额外的提交或添加测试，除非直接回应评审者的关切并降低不确定性，否则不会导向集成。

定性发现合在一起是：评审者参与只有在智能体参加稳定、目标对齐的评审互动时才有效。集成成功取决于通过反馈达到收敛，而不是活动量。

跨 RQ1 和 RQ2，智能体拉取请求的集成主要由评审时协调塑造，而不是由迭代量塑造。定量模型把评审者参与和协调稳定性识别为主导信号。定性分析解释可行动反馈如何通过收敛带来成功合并。反过来，设计错位、不完整的解和协调中断一致地解释拒绝。

5 相关工作

先前研究把拉取请求评估刻画成社会技术过程：集成既取决于技术因素，也取决于社会因素。变更大小影响接受，评审时互动在集成决定里居中。评审者参与、讨论动态和协调实践帮助评审者评估信任、协调成本和感知到的风险，常常超出代码正确性本身。

大语言模型的进展让自主编程智能体能大规模提交拉取请求。AIDev 数据集提供了这一转变的第一批系统证据，记录采用模式和合计合并结果。但已有研究大体把智能体请求当技术制品，留下它们如何参加既有社会技术评审过程的问题。本文在这条文献上追问：塑造人类拉取请求集成的那些评审时协作信号，是否同样影响智能体撰写的贡献。

6 效度威胁

构念效度：协作是从 GitHub 制品推断的，例如评审、提交和强制推送。这些可能不能完全抓住评审者意图或互动质量。缓解办法是用事先订好的编码本做互补的定性编码，分歧通过讨论解决。

内部效度：研究是观察性的，不支持因果主张。虽然控制了智能体身份和仓库效应，未观察到的项目规范或评审者实践仍可能影响结果。特别是「收到评审则更可能合并」，也可以读成评审者挑选了看起来可行的变更，而不只是评审本身造成了合并。

外部效度：分析聚焦大型公开 GitHub 仓库里的智能体拉取请求。发现未必推广到私有项目、更小的社区，或行为不同的未来智能体。数据集也不区分自主提交和由人唤起的提交。

7 结论

本文用 AIDev 数据集研究智能体撰写的拉取请求如何进入由人驱动的开发工作流。集成成功主要取决于评审时协作信号，而不是迭代量。评审者参与在带来可行动反馈和收敛时提高合并可能；更大的变更和破坏协调的行为降低成功。有效的智能体式软件工程，需要对齐既有的代码评审和协调实践。

复现包已公开，便于核验和重复这项工作。