你是不是也想过把 issue 直接丢给 Claude Code 或 Codex让它自己写代码、自己提 PR你只负责 review 和 merge一个人过上一个团队的日子社区里到处是这样的叙事AI 编程 Agent 正在接管 GitHubAgent 提的 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 EngineeringSE 3.0Workshop 接收。先把三个结论放在前面每一个都和流行叙事有点出入Agent 铺得很广但用得很浅——中位数**的仓库三个月只产生了 1 到 2 个 Agent**PR只有1%的项目里Agent PR 的平均产出量超过了行业观察里人类开发者的 PR 产出基准线78.9% 的 AgentPR**是同一个人自己审查、自己修改、自己合入的**——所谓“人机协作”现阶段主要是“一个人 一个 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——GitHubCopilot、**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% 的参与率差异所有两两比较的效应量Cliffs 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 个 PR78.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% 里的“一人乐队”。乐队规模迟早会扩大但指挥棒怎么交接行业才刚刚开始摸索。