你是不是也想过：把 issue 直接丢给 Claude Code 或 Codex，让它自己写代码、自己提 PR，你只负责 review 和 merge，一个人过上一个团队的日子？

社区里到处是这样的叙事：AI 编程 Agent 正在接管 GitHub，Agent 提的 PR 满天飞。但热闹归热闹，一直缺一个视角：**落到一个个具体的项目上，Agent 到底被用到了什么程度？谁在用？用的时候，人是怎么盯着它的？**

罗切斯特理工学院（RIT）的两位研究者最近给出了一份实证答案。论文「Early Adoption of Agentic Coding Tools by GitHub Projects」分析了 2,361 个 GitHub 热门仓库里的 25,264 个 Agent PR，专门回答三个问题：项目层面的采用程度、Agent PR 的产出水平，以及人和 Agent 之间的协作模式。这篇论文已被 KDD 2026 的 Agentic Software Engineering（SE 3.0）Workshop 接收。

先把三个结论放在前面，每一个都和流行叙事有点出入：

1. Agent 铺得很广，但用得很浅——**中位数****的仓库，三个月只产生了 1 到 2 个 Agent** **PR**；
    
2. 只有 **1%** 的项目里，Agent PR 的平均产出量超过了行业观察里人类开发者的 PR 产出基准线；
    
3. **78.9% 的 Agent** **PR****，是同一个人自己审查、自己修改、自己合入的**——所谓“人机协作”，现阶段主要是“一个人 + 一个 Agent”的独角戏。
    

下面我们把数据一层层展开。

### 数据从哪来：25,264 个真实 PR，不是 benchmark

先交代数据底座，因为这篇论文的说服力全在数据的“真实”上。

研究用的是 AIDev-pop 数据集——一个专门收集 GitHub 上 Agent 生成 PR 的公开数据集，只收录 100 star 以上的活跃仓库。和 SWE-bench 这类在受控任务上评测 Agent 能力的 benchmark 不同，AIDev-pop 记录的是真实开发现场：真实的仓库、真实的 PR、真实的人类 review 和 commit 记录。

作者在此基础上做了几步筛选：只看 2025 年 5 月到 7 月这三个月内创建、且已经 merge 或 close 的 PR（保证每个 PR 的结局是可观察的）；只看三个使用最广的编程 Agent——**GitHub** **Copilot、****OpenAI** **Codex 和 Claude Code**。筛完之后是 2,361 个仓库、25,264 个 Agent PR、291,866 个 commit。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/04ed6eb0a0f035433a18c967178dce52.png)

图注：过滤后的数据集概览。时间窗口为 2025 年 5-7 月，覆盖 Copilot、Codex、Claude Code 三个 Agent，包含 PR、commit、review、评论等多类工件。

这里有一个方法细节值得一提：怎么区分“人”和“Agent”？作者把每个 PR 关联的 commit、review、评论和时间线事件全部拉通，通过 Codex、Claude、Copilot、bot、mergify 这类关键词把 Agent 和机器人账号剔除，剩下的去重后就是这个 PR 的真实人类参与者集合——谁 review 了、谁改了代码、谁点的 merge，都有据可查。

另外，作者还通过 GitHub API 拉取了每个仓库的贡献者数量，把项目分成三档：小型（1-5 个贡献者，343 个）、中型（6-15 个，456 个）、大型（16 个以上，1,562 个）。后面所有结论都会沿着这个“团队规模”的维度展开——这也是这篇论文和之前那些只看单个 PR 成败的研究最大的不同。

### 发现一：铺得很广，用得很浅

**第一个问题：Agent 到底被采用到什么程度了？**

答案有两面。一面是“广”：Agent PR 出现在了数千个热门项目里，说明工具确实已经铺开。另一面是“浅”，而且浅得超出预期——**在整整三个月的观察期里，****中位数****仓库只产生了 1 到 2 个 Agent PR。**

也就是说，对一个典型的采用了 Agent 的项目而言，Agent 并不是每天在干活的“团队成员”，更像是被偶尔叫出来试了一两次的新工具。

参与面也是同样的故事。论文定义了一个“人类参与率”指标：一个仓库的贡献者里，有多大比例参与过至少一个 Agent PR。结果是：42.27% 的项目参与率不到 5%，70.18% 的项目不到 20%。换句话说，**在超过三分之二的项目里，10 个贡献者中最多只有 2 个人碰过 Agent** **工作流****。**Agent 进了仓库，但没有进入大多数人的日常。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/925f813fa095f481d5d253306ae87854.png)

图注：项目团队规模与 Agent PR 人类参与率的关系。小型项目（蓝色）参与率显著更高，大型项目普遍聚集在低参与率区间。

那么，谁在重度使用？数据指向了小团队。小型项目（1-5 人）的参与率显著高于中大型项目——这个差异不是碰巧：Kruskal-Wallis 检验显示项目规模能解释约 61.6% 的参与率差异，所有两两比较的效应量（Cliff's Delta）都在 0.9 以上，属于统计上“大得不能再大”的那种差异。作者还换了一套规模划分标准重跑了一遍，结论不变。

更有意思的是 PR 数量的均值：小型项目平均每仓库产生 **50.2** 个 Agent PR，而中型和大型项目分别只有 5.6 和 6.7 个。注意，小型项目的中位数同样只有 1-2 个——均值和中位数差出几十倍，说明分布极度偏斜：**少数几个“梭哈型”小项目贡献了海量 Agent PR，拉高了整个均值。**

![](https://developer.qcloudimg.com/http-save/yehe-12464096/bad43ec2355528311e2ab40e21a4a2ea.png)

图注：三类项目规模下 Agent PR 数量的分布（不含离群点）。三类项目的中位数都停留在 1-2 个，但均值差异巨大，反映出重度使用集中在极少数项目。

这幅图景其实很符合工程直觉。一个人或者两三个人的小项目，决策链短，没有流程包袱，想让 Agent 放开手脚就能放开；而团队越大，代码规范、review 流程、责任边界这些组织因素越重，Agent 就越难“批量放进来”。

值得交叉参照的是，同期另一项研究《Agentic Much? Adoption of Coding Agents on GitHub》（Robbes 等人，已被 ACM TOSEM 接收）对 128,018 个 GitHub 项目做了大规模扫描，通过配置文件、commit 元信息等痕迹估算出：编码 Agent 的项目采用率已达 22%–29%，且仍在上升。该团队 6 月发布的后续研究还发现，在更新创建的项目中，Agent 采用率高出两倍以上，AI 辅助 commit 的占比也明显更高——增长曲线仍在变陡。两条线放在一起看，结论更完整了：**采用率的增长非常快，但采用强度还很低**——大多数项目处在“试了，但还没敢多用”的阶段。

### 发现二：只有 1% 的项目跑赢了那条基准线

**第二个问题：在用了 Agent 的项目里，Agent PR 的到底能有多少产出？**

论文的衡量方式是：每个人类参与者在三个月里对应产生了多少个 Agent PR。作为参照，作者引入了一条来自行业观察报告的基准线——人类开发者的 PR 产出中位水平约为**三个月 36 个**。

结果：2,361 个项目里，只有 **25 个（约 1%）**的 Agent PR 平均产出超过了这条线。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/e08481a2cab5717fb3592a4c388c2c27.png)

图注：各项目 Agent PR 总量与人类参与者数量的关系。红色虚线为“三个月 36 个 PR”的参照线，黑色实线为均值。绝大多数项目落在参照线之下，少数小团队项目远超该线。

这里必须停一下，把这个数字掰清楚，因为它非常容易被误读。**这条线不是在说“Agent 拖了后腿”。**作者自己也强调，36 这个数只是一个语境参照，不是普适的生产力标准。它衡量的是“Agent PR 的产出量”，不是项目的总产出——一个项目 Agent PR 人均只有 3 个，完全可能是因为人类还在正常干活，Agent 只承担了边角任务。所以正确的读法是：**目前绝大多数项目里，Agent 的贡献量还远没有达到“顶得上一个人类开发者”的水平；Agent 是补充，不是替代。**

但反过来，那 1% 也很值得注意。图中确实存在一批远超参照线的项目——个别只有一两个人类参与者的项目，三个月里管理了几百个 Agent PR。这说明“让 Agent 大规模产出”在工程上是可行的，只是目前高度依赖具体项目的工作流设计和维护者的投入方式。差距不在模型能力，而在用法。

顺带一提一个有趣的张力。微软的三位研究者最近发布了对自家早期推广的观察研究《Adoption and Impact of Command-Line AI Coding Agents》：追踪数万名工程师在 2026 年初使用 Claude Code 和 Copilot CLI 的遥测数据后估算，采用这些命令行 Agent 的工程师，合并的 PR 比不采用的反事实情形多出约 24%，且这一提升在四个月的观察窗口内持续未衰减。个体层面的提效信号是真实存在的——而本文的项目层面数据却显示，大多数项目的 Agent 产出量还很低。两者并不矛盾：**个体尝到了甜头，不等于项目层面已经完成了规模化**——中间隔着的，正是下一节要讲的东西。

### 发现三：78.9% 的 Agent PR，是一个人自己审自己合

**第三个问题最有意思：Agent 提交的代码，人是怎么把关的？**

作者把每个 Agent PR 按“谁 review、谁 commit”分成了五种协作模式，从“一个人 review 但不改代码”到“多人 review、多人修改”。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/0356ec17e0e69f7e400d3961b4305e8c.png)

图注：Agent PR 中五种人类参与模式的定义：从单人 review 不改码，到审改同一人，再到审改分离和多人协作。

分布结果非常一边倒：

**最常见的模式是“1 个 Reviewer + 1 个 Committer，且是同一个人”，占了 19,488 个 PR，78.9%。**也就是说，将近八成的 Agent PR 里，review 代码的人和修改代码的人是同一位开发者——他让 Agent 干活，自己检查，自己改，自己合。排第二的是“1 人 review、无人改码”（9.8%）。两者相加，**88.7% 的 Agent PR 全程只有一个人类经手。**

涉及两个及以上人类的协作模式，加起来只占 11.3%。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/3023fc9db666bf926300a87ebdf7786c.png)

图注：不同项目规模下人机协作模式的分布。“审改同一人”的单人模式在所有规模的项目中都占绝对主导；中大型项目的多人协作比例略高，但仍是少数。

大型项目的多人协作比例确实略高一些，但即便在大项目里，单人监督依然是绝对主流。

这组数据揭示的现实是：**当前的“人机协作”，主要不是“团队 + Agent”，而是“个人 + Agent”。**Agent 没有取代人的监督，反而把监督责任高度压缩到了单个开发者身上——他既是 Agent 的“产品经理”，又是它的 QA，还是最终背责的人。

从工程治理的角度看，这里藏着一个值得警惕的点（这一段是我的延伸解读，论文本身没有展开）：78.9% 的“自己派活、自己审查、自己合入”，本质上意味着这些 Agent 代码**没有经过独立的第二双眼睛**。传统 code review 的价值恰恰在于“写的人”和“审的人”利益分离，而在单人 + Agent 的模式里，这道防线是缺位的——尤其当开发者对 Agent 产出逐渐建立信任、审查越来越松时。论文作者的表述更克制一些：当前的 Agent 工作流把“相当大的责任压在了单个开发者身上”，团队级的监督结构还没有跟上。

### 对工程团队的启发

把三组数据合起来看，这篇论文对正在（或打算）把编程 Agent 引入团队的读者，至少有三条可以带走的判断。

**第一，Agent 规模化的瓶颈已经不是模型能力，而是人的 review 带宽和组织流程。**论文反复出现的模式是：工具在场，但没有进入多数人的工作流；产出可以很高（那 1% 证明了可行性），但多数项目没有跑起来。作者的结论是，Agent 的成功整合“不仅取决于 Agent 能力的进步，同样取决于治理其使用的人类与组织流程”。换句话说，如果你的团队用 Agent 用不起来，先别急着换模型，先看看 review 流程、责任分配和工作流设计。

**第二，如果你在小团队或个人项目里，你正处在 Agent 红利兑现最快的位置。**数据清楚地显示，参与率和人均产出的高地都在 1-5 人的小项目。没有流程摩擦的地方，Agent 的杠杆最大。

**第三，如果你在中大型团队里推 Agent，“谁来审、谁背责”要先于“用哪个 Agent”来设计。**当下的默认演化路径就是滑向“一人自审自合”——这在个人项目里无伤大雅，但在有质量与安全要求的团队代码库里，可能需要主动设计对冲机制，比如对 Agent PR 强制要求独立 reviewer，或对高风险路径的 Agent 变更加一道人工门禁。

### 边界：这是一张“早期快照”

按照咱们解读论文栏目的惯例，也需要把这篇论文的适用边界说清楚。

首先，观察窗口是 **2025 年 5-7 月**——那正是编程 Agent 爆发的早期阶段。Agent 工具在此之后迭代极快，今天的采用格局很可能已经和数据里不一样了。作者自己也把这项研究定位为“早期快照”，并呼吁持续追踪。读这篇论文的正确姿势，是把它当作一个基线，而不是终局。另外前面也提到了扩展的研究，从时间上看是更接近于现在的，后续我们也会考虑进一步去解读那两项研究。

其次，样本只覆盖 100 star 以上的热门开源仓库，以及 Copilot、Codex、Claude Code 三个 Agent。私有仓库、商业团队内部的使用方式（很可能激进得多）、以及 Cursor 等其他工具的贡献，都不在数据里。识别人类参与者依赖关键词过滤机器人账号，也可能有漏网之鱼。

第三，“每人 Agent PR 数”是一个数量代理指标，不含 PR 的大小、复杂度和质量。一个改 README 的 Agent PR 和一个重构核心模块的 Agent PR 在统计里权重相同。所以本文的“产出”结论应读作“活动量”，而非严格意义的生产力。

最后，这是观察性研究，所有结论都是相关而非因果——“小项目用得多”不等于“项目小导致用得多”。

### 小结

这篇论文可以用一句话概括：**编程 Agent 已经无处不在，但还远未被真正用起来——典型项目三个月只让它发 1-2 个 PR，产出超过人类基准线的项目只有 1%，而近八成的 Agent 代码由同一个人自写指令、自审、自合。**

它最大的价值，是把讨论从“Agent 能不能写好代码”往前推了一步，推到了“组织如何消化 Agent 的产出”。模型能力每几个月上一个台阶，但 review 带宽、责任结构和协作流程的演化要慢得多——这个剪刀差，可能才是未来一两年 Agentic 软件工程真正的主战场。

下一次当你把任务丢给 Claude Code、看着它刷刷提出 PR 的时候，可以想想这组数据：此刻的你，大概率正是那 78.9% 里的“一人乐队”。乐队规模迟早会扩大，但指挥棒怎么交接，行业才刚刚开始摸索。

你是不是也想过：把 issue 直接丢给 Claude Code 或 Codex，让它自己写代码、自己提 PR，你只负责 review 和 merge，一个人过上一个团队的日子？

2.5 万个 AgentPR的实证：AI 涌入GitHub一年，到底做出多少产出？

RIT研究团队分析25,264个真实Agent PR发现：AI编程代理已广泛落地（覆盖2361个热门仓库），但应用极浅——中位数项目3个月仅提交1–2个PR；仅1%项目产出超人类基准；78.9%的PR由同一开发者审、改、合，凸显当前“人机协作”实为“单人+Agent”模式。

人工智能

开发工具

职业发展

研究发现：AI编程助手在GitHub项目中应用广泛但深度不足，78.9%的AI生成PR由单人完成审查与合并。数据显示，仅1%的项目AI产出超过人类基准，小团队采用率更高。研究揭示AI编程工具规模化瓶颈在于组织流程而非技术能力，为开发者引入AI工作流提供重要参考。

人机协作

软件工程

AI编程

GitHub

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

2.5 万个 AgentPR的实证：AI 涌入GitHub一年，到底做出多少产出？-腾讯云开发者社区-腾讯云

2.5 万个 AgentPR的实证：AI 涌入GitHub一年，到底做出多少产出？

2.5 万个 AgentPR的实证：AI 涌入GitHub一年，到底做出多少产出？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐