[Paper] 合作者还是 Assistnant？AI 编码代理在 Pull Request 生命周期中的工作划分

Source: arXiv - 2605.08017v1

Overview

本文研究了 AI 驱动的编码助手和协作者在 Pull Request（PR）整个生命周期中的参与方式。通过对五种流行工具（OpenAI、Claude、GitHub Copilot、Cursor 和 Devin）中近 30 K 个 PR 的分析，作者绘制出谁发起工作、谁授权合并的图谱，揭示了从“助手”（人类驱动）到“协作者”（代理驱动）行为的连续谱。

关键贡献

• 发起者 × 批准者分类法，定义了 PR 的六种交互场景（例如，代理发起 + 人工批准，人工发起 + 代理批准）。
• 对 29,585 个 PR 生命周期的实证分析，展示了每种工具如何分配主动权和监督。
• 每种工具的状态机模型，展示了典型的操作序列（分支创建、提交、评审、合并）。
• 开放的复现包（数据、脚本和分类法），以支持对软件开发中自动化和治理的进一步研究。
• 发现 即使在代理主导操作工作的情况下，合并治理仍以人为中心。

方法论

1. 数据收集 – 作者从使用这五种 AI 工具的公共仓库中收集 PR 元数据（事件、时间戳、参与者）。
2. 角色推断 – 他们将每个事件分类为 initiated（谁打开了分支/PR）或 approved（谁执行了最终合并），并映射到分类法。
3. 生命周期重建 – 通过对事件排序，构建每个工具的状态机，捕获典型的 PR 流程（例如，“代理打开 → 人类审查 → 人类合并”）。
4. 统计分析 – 计算每个工具的各交互场景频率，并进行跨工具比较，以突出协作者‑助手光谱。

该方法刻意保持工具无关：任何记录 PR 事件的系统都可以套入相同的分类法。

结果与发现

• 协作工具（Cursor、Devin、Copilot）将操作主动权交给 AI：它们打开分支、推送提交，并在最少人工提示的情况下保持 PR 活跃。
• 助理工具（OpenAI、Claude）保持支持角色：人工打开 PR 并决定何时合并；AI 仅提供代码片段或重构建议。
• 合并权限在所有工具中几乎都是人工的；只有极少数 PR 显示“agent‑approved” 合并，而这些案例缺乏明确的决策者日志。
• 通过分类发现 六种不同的交互模式，但超过 95 % 的观察到的 PR 落入两类：agent‑initiated + human‑approved（协作）和 human‑initiated + human‑approved（助理）。

实际影响

• 工具选择: 想让 AI 主导例行 bug 修复或脚手架的团队可以采用协作式代理（Copilot、Cursor）。需要对合并内容进行严格人工控制的团队则应优先使用助理式工具（OpenAI、Claude）。
• 工作流设计: 了解合并仍以人为中心后，组织可以设计审查门（例如强制代码所有者批准），而无需担心 AI 驱动的“静默合并”。
• 可观测性与审计: 论文指出了一个盲点——当 AI 执行合并时，日志记录了执行者但未记录决策逻辑。公司应在 CI/CD 流水线中加入显式的决策记录（例如签名的合并请求）。
• 合规性与安全: 在受监管的环境中，协作光谱可能引发对“未认证”代码更改的担忧。研究结果表明，加入最终人工批准步骤可以降低大部分风险。
• 产品路线图: 供应商可以利用状态机模型识别缺失的交接点（例如添加“AI 建议合并”检查点），以提升透明度和用户信任。

限制与未来工作

• 工具范围 – 只研究了五个 AI 代理；更新的或小众的工具可能表现出不同的模式。
• 数据集偏差 – 拉取请求来自已经采用这些代理的公共仓库，可能过度代表了热情的早期采用者。
• 决策者可见性 – 当执行者是代理时，研究无法可靠地将合并决策归因于 AI，导致治理分析出现空白。
• 未来方向 作者提出的包括：将分类法扩展到 CI/CD 流水线，研究 AI 驱动的合并对代码质量和缺陷率的影响，以及构建更丰富的审计日志，捕获执行者和决策权威两者信息。

作者

• Young Jo
• Chung
• Safwat Hassan

论文信息

• arXiv ID: 2605.08017v1
• 分类: cs.SE
• 发布日期: 2026年5月8日
• PDF: 下载 PDF