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 接收。

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

Agent 铺得很广，但用得很浅——中位数****的仓库，三个月只产生了 1 到 2 个 Agent PR；

只有 1% 的项目里，Agent PR 的平均产出量超过了行业观察里人类开发者的 PR 产出基准线；

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。

1

图注：过滤后的数据集概览。时间窗口为 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 进了仓库，但没有进入大多数人的日常。

2

图注：项目团队规模与 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，拉高了整个均值。

3

图注：三类项目规模下 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 平均产出超过了这条线。