你是不是也想过：把 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 接收。
先把三个结论放在前面，每一个都和流行叙事有点出入：
-
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。
图注：过滤后的数据集概览。时间窗口为 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 进了仓库，但没有进入大多数人的日常。
图注：项目团队规模与 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，拉高了整个均值。
图注：三类项目规模下 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 平均产出超过了这条线。
图注：各项目 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、多人修改"。
图注：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%。
图注：不同项目规模下人机协作模式的分布。"审改同一人"的单人模式在所有规模的项目中都占绝对主导；中大型项目的多人协作比例略高，但仍是少数。
大型项目的多人协作比例确实略高一些，但即便在大项目里，单人监督依然是绝对主流。
这组数据揭示的现实是：**当前的"人机协作"，主要不是"团队 + 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% 里的"一人乐队"。乐队规模迟早会扩大，但指挥棒怎么交接，行业才刚刚开始摸索。