四成 PR 由 agent 起草之后，谁来点那个“合并”

10 月 28 日，GitHub 在旧金山开年度大会 Universe，同一天发布了 2026 年的 Octoverse 报告。报告里最受关注的一个数字是：到今年 9 月，GitHub 上超过 40% 的 pull request（PR，也就是“请把我的改动合进主干”的申请）初稿来自编码 agent。今年 3 月，这个比例是 17%。

单看 9 月，agent 起草的 PR 有 1.1 亿个，大约是 3 月的 6 倍。

六个月，从不到五分之一到超过五分之二。这个速度比我预想的快得多。但我读完报告，印象最深的不是这个比例，而是报告里没有的东西：它统计了代码写了多少、合并了多少，却没有一个数字告诉你，这些代码有多少人认真看过。

一年里翻了快三倍的东西

先看报告给出的总量。Octoverse 的统计窗口是 2025 年 10 月 1 日到 2026 年 9 月 30 日，包含公开和私有仓库。GitHub 说明，上一年度的数字已经按同一窗口重新计算过，所以可以直接比较。

• 推送 179 亿次。 上一年度是 67 亿次，再往前一年是 52 亿次。今年一年比前两年加起来还多。
• 提交 343 亿次。 上一年度 129 亿次。
• 合并的 PR 13 亿个。 上一年度 5.38 亿个，折合每天约 350 万个。
• GitHub Actions 任务 454 亿个。 上一年度 140 亿个，相当于每秒 1440 个。

同一时期，平台上的开发者从去年 Octoverse 报告里的“超过 1.8 亿”增加到“超过 2.25 亿”。两份报告的统计窗口不完全一样，我只把它当作一个量级参考：人大概多了四分之一，合并进主干的代码改动多了一倍半。

多出来的部分是谁写的，报告给了几条线索：

• agent 起草的 PR 改动更大。 87% 的 agent PR 改了多个文件，没有检测到 agent 参与的 PR 是 79%。
• 用 agent 的仓库提交多得多。 今年新建的仓库里，带 agent 配置文件的仓库，平均提交量是不带的 8 倍。报告没有控制仓库规模和类型，这只是相关，不是因果。
• Copilot 用户在转向 agent 用法。 月活用户中有 55% 用了 agent 功能，一年前是 35%。

还有一点要注意：GitHub 对“agent 起草”的定义是“初稿来自我们能检测到的编码 agent”。报告的术语表里也写明，并非所有 agent 的使用都能被检测到。我理解，在本地借助编码工具写完、再由人自己提交的代码，很可能就在这个盲区里。所以 40% 是下限。

合并率 90%，说明不了什么

报告里唯一和质量沾边的指标，是两周内的合并率。有 agent 参与的 PR，2 月份两周内合并的比例是 83%，到 9 月升到 90%；没有检测到 agent 参与的 PR，两个时间点都在 86% 左右。

这个数字很容易被读成“agent 写的代码已经比人写的更靠谱”。我的看法是，它最多说明 agent 的 PR 更容易被接受，至于为什么更容易被接受，有好几种解释：

• agent 真的写得更好了。 半年里模型和工具都在进步，这是可能的。
• 任务更好挑了。 大家逐渐摸清了什么活适合交给 agent，交出去的多是边界清楚的小修小补。
• 审的人放松了。 PR 多了、改动大了，人不可能每一行都看，点“批准”的门槛在下降。

这三种情况在合并率上看起来一模一样。报告自己也没有回避这一点，它没有给出任何关于 agent PR 缺陷率、回滚率或安全问题的数据。

外部的数据给了另一面。Linux 基金会 10 月 20 日发布了一份由 Red Hat 资助的开源维护者调查（据报道样本为 234 人，4 月到 6 月做的网络问卷）：

• 59% 的维护者说，生成式 AI 兴起后，收到的贡献变多了。 大型项目（贡献者超过 50 人）里这个比例是 69%。
• 维护者估计，收到的 PR 里约 25% 是低质量的“AI slop”。 大型项目估计是 31%。
• 只有 35% 的项目有允许使用 AI 的正式规定， 32% 的项目既没有规定，也不打算制定。
• 53% 的维护者不同意“AI 提升了社区信任”。

这是自报的估计，不是测量，样本也有限，不能直接和 GitHub 的全量数据对比。但它说明了一件事：在开源这一侧，最先感到压力的就是看代码的人。

我做个粗略的估算，只为了感受一下量级：9 月 1.1 亿个 agent PR，如果每个只花 5 分钟审，就是 900 多万小时，按每月 160 小时算，相当于 5 万多个全职工程师什么都不干，只看 agent 交上来的 PR。5 分钟显然是很乐观的假设。写代码的成本在快速趋近于零，读代码的成本没有。

8 月 17 日那次宕机

压力最先落在 GitHub 自己身上。

今年 8 月 17 日，GitHub 宕机 7 小时 47 分钟，github.com、登录、Actions、API、PR、Copilot 都受到影响，这是当月第二次大故障。CTO Vlad Fedorov 在 8 月 20 日的复盘里写得很直接：“两次事故的根本原因都是容量不足。”“我们没能在需求超过容量之前扩容关键组件。”

复盘里有两个细节我印象很深：

• 月提交量从 4 月的 14 亿涨到 29 亿，只用了四个月左右。 一个运行了将近二十年的平台，四个月提交量翻倍，原来的扩容节奏跟不上。
• 恢复过程中，Copilot 客户端的报错触发了自动重试，重试又放大了流量。 机器在故障时不会像人一样等一等再试，它们会一直试。

这次大会上，GitHub 说今年已经新增了 400 万个 CPU 核、160 PB 高速存储和 50 Tb/s 网络带宽，正在迁到 Azure 的多区域部署，预计明年初完成。GitHub 工程团队 10 月的一篇文章，把 agent 驱动的开发称为“下一次架构转变”，并且说，比起读取，“写入要难得多”。

我觉得这件事本身就是一个提醒。GitHub 是全世界最懂代码协作的公司之一，它的系统是按“人写代码”的节奏设计的，换成“agent 写代码”，八月就扛不住了。大多数公司内部的代码评审流程、CI 资源、发布节奏，也是按人的节奏设计的。

GitHub 的答案：让 agent 去审 agent

GitHub 这次的产品发布，基本都在回应这个问题：

• Copilot 应用。 可以在多个仓库里并行跑 agent 会话，同一个会话能在 GitHub 应用、VS Code、命令行和网页之间接着用。
• Copilot Fusion。 按任务的每一步自动选模型。GitHub 说，Fusion Max 在 Artificial Analysis 的编码 agent 榜单上，和 Claude Opus 5.5 Max 只差两分，成本减半，每个任务少用 40% 的时间。这是厂商自己的说法。
• Copilot 代码审查 Max。 GitHub 称它在 ReviewBench 上发现高危问题的 F1 分数最高。
• 定价改成按用量。 GitHub 企业版客户不用再单独订阅 Copilot，所有功能按消耗的 AI 额度付费。目前通过销售开通，自助购买“即将上线”。

把这几条放在一起看，GitHub 的逻辑很清楚：写代码的 agent 制造了审查压力，那就再卖一个审代码的 agent，按用量收钱。报告里也有呼应：AI 辅助代码审查和 GitHub Advanced Security 的用量都比去年增长了 90% 以上。

我不认为这是错的。机器审查确实能挡掉大量低级问题，而且不会累。但它解决的是“看不过来”，不是“谁负责”。一个 PR 由 agent 写、由 agent 审、再由人点一下合并，出了问题，点合并的那个人能说清楚自己批准了什么吗？这是工具层面回答不了的问题。

前任 CEO 的另一个答案：不要 PR 了

就在 Universe 开幕前两天，10 月 26 日，GitHub 前 CEO Thomas Dohmke 的创业公司 Entire 发布了自己的 Git 托管平台。

Entire 今年 2 月拿到了 6000 万美元种子轮，估值 3 亿美元，由 Felicis 领投。当时 Dohmke 在新闻稿里说：“大量代码的生成速度，已经超过任何人能合理理解的速度。”

这次发布的核心叫 Trails，用来取代传统的 PR。按 Entire 的说法，它不再让人逐份审一个个改动申请，而是在每次推送时由 agent 跑一组可自定义的评估、打分，人看的是一块“类似飞行员抬头显示”的仪表盘。Entire 还说自己的推送速度最高是 GitHub 的 89 倍，这同样是厂商自测，没有第三方验证。

我理解 Dohmke 的判断是：PR 这种“一个人提交、另一个人逐行看”的形式，本来就是给人和人协作设计的，agent 时代应该换掉。GitHub 的判断是：PR 还在，只是审的人换成了 agent。两个答案方向不同，但承认的是同一件事：按人的速度逐行审代码，已经跟不上了。

我自己更倾向于 Entire 的方向，但它目前只是一个刚上线的产品，私有仓库能用，公开仓库和自建节点还在路线图上。真正值得关注的，是它提出的那个问题：如果人不再逐行看代码，人到底应该看什么。

写给带研发团队的人

我之前在《AI 原生，本质是组织的重写》里写过，AI 最先放大的，往往是一个组织原有的瓶颈；编码快了十倍，整体速度还是被编码之外的环节卡住。现在 GitHub 的数据把这个环节指得很明确，就是审查。几条我认为现在就能做的事：

• 先量一下自己团队的数字。 agent 起草的 PR 占多少，平均改动多大，从提交到合并要多久，每个审查人一周要看多少。不量，就只能凭感觉说“效率提高了”。
• 把“谁对合并负责”写下来。 agent 写的、agent 审过的 PR，最后点合并的人对什么负责，要有明确的约定。至少要求合并的人能用自己的话讲清楚这个改动做了什么、风险在哪里。
• 按风险分级，不要一刀切。 文档、测试、依赖升级这类改动，可以多交给机器审；涉及权限、支付、数据删除、对外接口的改动，必须有人认真看。Octoverse 显示，依赖机器人 Dependabot 的 PR 今年合并了 3000 多万个，这类改动本来就适合高度自动化。
• 限制单个 PR 的大小。 agent 很容易一次改几十个文件。改动越大，人越容易直接点批准。把任务拆小，比事后要求“仔细看”有用。
• 要求 agent 留下“为什么”。 改动背后的需求、提示词、试过但放弃的方案，应该和代码一起留下。Entire 第一个产品 Checkpoints 做的就是这件事。即使不用它的产品，也可以在 PR 描述模板里强制要求。
• 算一下审查的成本。 按用量付费之后，agent 写代码和 agent 审代码都在消耗额度。别只算“写代码省了多少人”，也要算“审代码多花了多少钱、多占了多少人”。

如果你是开源项目的维护者，Linux 基金会的数据说明你不是一个人在面对这个问题。尽早定下项目对 AI 贡献的规则，比如要求披露、要求贡献者自己先跑完测试，会比事后一条条拒绝省力得多。

写在最后

几天前我写过一篇关于 AI 找漏洞的文章：AI 一周找到的漏洞，人类修了两个月。今天这组数字讲的是同一件事的另一面。AI 让“产出”变得很便宜，但“确认产出是对的”这件事，还是要花人的时间，而人的时间没有变多。

40% 这个数字明年大概率会变成 60%、70%。到那时候，一家公司研发能力的上限，可能不取决于它有多少人写代码，而取决于它有多少人、多少机制能为合并进去的代码负责。

我觉得现在最值得问自己团队的问题是：上个月合并的代码里，有多少是有人真正看懂了的？

---

参考资料

• GitHub, Octoverse: Commits, pushes, reach new highs in 2026 as developers build with agents, 2026-10-28
• Jay Parikh（GitHub Blog）, GitHub Universe 2026: Evolving every layer of the stack, 2026-10-28
• Vlad Fedorov（GitHub Blog）, The August 17 outage, and the work ahead, 2026-08-20
• Brian Celenza（GitHub Blog）, Building Git infrastructure for agent-scale development, 2026-10-06（10-26 更新）
• The Next Web, GitHub launches Copilot Fusion as agents start 40% of pull requests, 2026-10-28
• The Linux Foundation, New LF Research survey shows generative AI cuts open source coding time in half, but 25% of incoming pull requests are considered AI slop, 2026-10-20
• TechCrunch, Former GitHub CEO raises record $60M dev tool seed round at $300M valuation, 2026-02-10
• ITPro, Former GitHub CEO Thomas Dohmke’s startup just unveiled a GitHub alternative – and AI agents are front and center, 2026-10-26
• GitHub, Octoverse: A new developer joins GitHub every second as AI leads TypeScript to #1, 2025-10-28