GitHub 年度报告：9 月 4 成 PR 的第一稿是 agent 写的，合并率反比人写的还高

GitHub 10 月 28 日发布的 Octoverse 2026 年度报告（统计年度为 2025 年 10 月 1 日至 2026 年 9 月 30 日）给出了一个里程碑数字：到 2026 年 9 月，GitHub 上超过 40% 的 Pull Request 是以 agent 的第一稿开头的，高于 3 月的 17%；仅 9 月一个月就有约 1.1 亿个 agent 起草的 PR，是 3 月的约 6 倍。平台全年的量级也跟着变了：推送 179 亿次、提交 343 亿次、合并 PR 13 亿个、开发者超过 2.25 亿人。报告还给出了三个配套数字：9 月 agent 参与的 PR 在两周内合并的比例是 90%，高于无 agent 参与的 86%；Copilot 月活用户里用 agent 功能的比例从一年前的 35% 升到 55%，云端 agent 交办任务同比增长 230%；9 月自己选模型的 Copilot 用户里，61% 在会话中用了不止一个模型，付费用户当月用了 47 个不同模型、没有哪个模型占比超过 25%。

我的核心判断是：agent 写代码已经从“效率工具”变成了“产能主体”，而人的主业正在从“写代码”滑向“审代码”。90% 对 86% 的合并率差最值得琢磨——它不是说 agent 写得比人好，而是说 agent 起草的 PR 更容易过审：格式规整、测试齐全、改动描述完整，这些恰恰是人工 PR 最容易被打回的地方。但这也意味着审查成了新的瓶颈：当 4 成 PR 都由 agent 起草、且合并率更高时，审查者的时间会被 agent 产出填满，真正稀缺的不再是“写代码的人手”，而是“能判断这段代码该不该进主干的人”。对小团队来说，可落地的动作有三条：第一，给仓库配好 agent 配置文件——报告里说，2026 年新建、带 agent 配置文件的仓库，平均提交数是没配的 8 倍，配置文件就是 agent 的工作说明书；第二，把审查清单写进流程（测试、权限、依赖变更三项必查），别只看 PR 描述写得漂不漂亮；第三，别把模型选型押在一个模型上——47 个模型、没谁超过 25% 的分布说明，多模型混用已经是常态，按任务挑模型比“全队统一用一个”更划算。

边界也要讲清楚。GitHub 自己承认，它的 agent 信号只是“下限”——只能统计到它能检测到的 agent 使用，真实比例只会更高；反过来，合并率 90% 对 86% 的比较也受任务类型影响，agent 接的多是规整任务，不能直接读成“agent 代码质量全面超过人类”。另外，报告里的 40% 是 9 月单月数字，不是全年平均，全年口径要等 GitHub 拆分公布。还有一点：这份报告是 GitHub 自家平台的数据，反映的是 GitHub 生态，不是整个软件行业的普查——不用它去论证“全世界 4 成代码都是 AI 写的”，那是把平台数据泛化了。

什么情况下这个结论不成立：如果你团队根本不用 agent 起草 PR，这组数字对你只是行业背景，不是待办事项；如果你把 90% 的合并率当成“agent 代码不用审”，那正好反了——报告的潜台词是审查量暴涨，审得越快、放进主干的风险越大；如果你只看 40% 这个 headline 数字、忽略“9 月单月、GitHub 平台、可检测信号下限”这三个限定词，结论就会被夸大；最后，如果你的仓库没有 agent 配置文件、没有审查清单，照搬“多模型混用”也不会见效，先补齐这两样再谈模型选型。