25,264 个 Agent PR 揭开真相：88.7% 的“人机协作”，其实只有一个人在兜底

AI 编码工具最容易制造一种错觉：

代码在自动生成，测试在自动运行，PR 在自动提交，于是软件开发已经从“人写代码”进入了“Agent 自己交付”。

2026 年 7 月 15 日公开的一项新研究，给这幅图景泼了一盆冷水。

研究者分析了 2,361 个热门 GitHub 仓库中的 25,264 个 Agent PR。结果显示，Agent 确实进入了真实开源项目，但大规模采用只集中在少数仓库，更关键的是：绝大多数所谓人机协作，最终仍由一个人完成评审、修改或合入。

先看三个最反直觉的数字

1. 中位数只有 1 到 2 个 Agent PR

研究观察的是 2025 年 5 月、6 月和 7 月，覆盖 Copilot、Codex 和 Claude Code 创建的已关闭或已合并 PR。

虽然总量达到 25,264 个，但按仓库看，中位数在三个月内只有 1 到 2 个 Agent PR。

这说明“Agent 已经遍布 GitHub”和“Agent 已经成为每个项目的主力开发者”是两件完全不同的事。

2. 只有 25 个项目超过参考产出线

论文用“三个月每位参与者 36 个 PR”作为上下文参考线，并明确说明它不是通用生产力标准。

2,361 个项目中，只有 25 个，也就是约 1%，超过这条线。大多数项目都在其下方。

3. 88.7% 是单人监督模式

19,488 个 PR，也就是 78.9%，由同一个人同时承担 Reviewer 和 Committer。

另有 9.8% 的 PR 是一个 Reviewer、没有额外 Committer。两类加起来，88.7% 的 Agent PR 主要依赖单个人类参与者监督。

真正有两名及以上人类参与的 PR 只占 11.3%。

问题不是 Agent 生成得慢，而是责任集中得太快

传统 PR 至少在流程上默认作者和评审者是两个角色。

但在 Agent PR 里，发起 Agent、阅读输出、修改代码、点击批准的人，很可能是同一个开发者。Agent 看起来增加了一个“协作者”，实际却可能让一个人同时成为需求解释者、代码作者代理、测试判断者和最终审批者。

这会出现三个风险：

• 评审者已经被 Agent 的解释和摘要锚定，很难独立判断；
• 自动生成的测试可能只证明实现符合自己的假设；
• PR 数量上升后，人类为了跟上速度，更容易把检查退化成点击批准。

所以 Agent PR 的治理重点，不应该只是“再加一个代码审查 Agent”。

如果两个 Agent 使用相似上下文、相似模型和相似提示，它们可能只是在更快地重复同一个错误。

一个更现实的 Agent PR 流程

我更建议把责任拆成三层。

Agent 负责生成和补证据

• 变更必须绑定明确 Issue 和验收标准；
• 标记 AI 生成来源；
• 同时提交测试、风险说明和回滚方式；
• 回应评审问题，而不是只给一段“修改总结”。

Reviewer 负责独立理解

• 不先看 Agent 摘要，先看需求、Diff 和测试；
• 判断测试是否覆盖真实风险，而不是只看是否通过；
• 对关键逻辑要求可复现证据；
• 发现不确定内容时，要求缩小变更范围。

Owner 负责生产结果

• 决定变更是否能进入灰度；
• 关注发布后的业务指标和异常；
• 确保回滚可执行；
• 对鉴权、支付、数据迁移等高风险模块升级为双人批准。

别再用 PR 数量证明 Agent 提效

论文自己也指出，它使用“每位人类参与者对应的 Agent PR 数量”作为产出代理指标，但没有考虑 PR 的大小、复杂度、质量和评审工作量。

这恰好说明，企业内部如果只统计“Agent 生成了多少 PR”，很容易得到一个漂亮但无用的数字。

更值得记录的是：

• Agent PR 从创建到合并的周期；
• 人类实际评审和修改时长；
• 自动生成代码被人类重写的比例；
• 测试补充率与缺陷逃逸率；
• 高风险变更触发二次评审的比例；
• 发布后的回滚、告警和事故数量；
• 同类任务在使用 Agent 前后的总交付时间。

如果 Agent 让编码从两天缩短到两小时，却让评审、返工和线上排障增加三天，那不是提效，只是把成本从“写代码”移动到了更难看见的环节。

对小团队来说，这项研究反而更重要

研究发现，小型项目，也就是 1 到 5 名贡献者的项目，Agent 参与率和平均活动水平更高。

这并不奇怪。小团队决策链短，一个人就能让 Agent 进入真实仓库，也能快速合并变更。

但同样因为人少，角色分离最难实现。

一个独立开发者很难凭空找出第二名 Reviewer。可行做法不是假装有完整团队，而是增加补偿性控制：

1. 高风险目录默认禁止 Agent 自动合并。
2. 重要变更至少隔一段时间再做二次阅读。
3. 使用与生成模型不同的方法做测试和静态检查。
4. 对部分 PR 做外部或交叉抽样评审。
5. 把灰度、监控和回滚视为评审流程的一部分。

这项研究也不能被过度解读

它是一张早期快照，不是 Agent 编码的最终结论。

数据来自 2025 年连续三个月，只统计已关闭或已合并 PR；研究没有直接衡量每个 PR 的代码质量、复杂度和真实评审负担；“36 PR”只是外部参考线，不是所有团队都应该追求的目标。

但它至少证实了一件事：

Agent 已经能够制造大量代码活动，却还没有消除人类监督。相反，监督责任正在快速集中到少数个人身上。

下一阶段真正稀缺的能力，可能不是让 Agent 再快一倍，而是建立一条能证明“谁理解了变更、谁批准了风险、上线结果如何”的责任链。

参考资料

• Early Adoption of Agentic Coding Tools by GitHub Projects
• KDD 2026 Agentic Software Engineering Workshop