GitHub 2026 年度报告:超四成合并请求由智能体起笔,老板要补的是评审产能

数字先摆出来：一年推送 179 亿次，合并请求 13 亿个

报告统计的是截至 2026 年 9 月 30 日的 12 个月：开发者向 GitHub 推送代码 179 亿次，比 2024 年和 2025 年两年加起来还多；提交 343 亿次，是两年前的三倍多；合并请求 13 亿个，平均每天 350 万个。GitHub 现在服务超过 2.25 亿开发者，美国 3830 万、印度 3200 万，仍是最大的两个群体。

6 月是一个拐点：活动量在 6 月前后明显加速，GitHub 自己的解释是模型、支架和能跨天跟踪任务的持久 Agent 在同一时期集中成熟。拐点之后的新仓库占了 6 月以来全部提交的约 55%——新项目从第一天就按 Agent 的方式搭，老项目则在后面追。

起笔变了：从人写第一行，变成人给 Agent 下第一道指令

最值得老板看的数字是起笔方式的变化：3 月份智能体起笔的合并请求占 17%，到 9 月份超过 40%。按微软在 Universe 大会上的说法，9 月份单月智能体起笔的合并请求达到 1.1 亿个，大约是 3 月份的 6 倍。GitHub 的原话是：对越来越多的工作，第一步不再是写代码，而是指挥 Agent，评审成了开发者塑造结果的方式。

还有一个配套数字：带智能体配置的新仓库，平均提交量是无配置新仓库的 8 倍。9 月份 61% 的 Copilot 用户用了不止一个模型，模型选择本身也在从“定一个”变成“按任务换”。写代码的起点变了，管理方式必须跟着变。

行业扩散：一边喊得多，一边落地少

报告第一次按行业拆了公开仓库，结果有个反差值得注意。行政服务、采矿、医疗、农业这些行业，超过四成的仓库提到 AI，但智能体提交的合并请求不到 3%。建筑业反过来：提到 AI 的仓库约四分之一，但智能体合并请求占比约 9%，是所有行业里最高的，制造业排第二。

翻译成老板的话：喊 AI 的行业不一定真的在用 Agent 干活，真正落地的地方往往不在口号里。评估自家进度时，别数“提到 AI 的项目数”，数“智能体起笔、经过评审、合并上线的改动数”。

边界：量大不等于质好，报告没说的两项指标

两处边界。第一，8 倍提交量只是相关性，不是因果：从第一天就配智能体的团队，本来就更愿意尝试、跑得更快，不能直接推出“上了 Agent 就快 8 倍”。第二，报告没有直接给出合并后的返工率和线上故障率——代码多、合并快，如果返工也多，交付速度并没有真的变快。只看产出数字做预算，会把钱花在错误的地方。

转型落点：补评审产能，而不是补写代码的人

正在推进 Agent 编程的企业，预算和人力应该往三处倾斜。第一，评审人力：按合并请求增速配评审员，评审排队超过两天就要加人或分流，而不是催写代码的人写更快。第二，合并标准：多文件改动必须过清单——影响面、回滚方案、测试覆盖，缺一项不合。第三，度量口径：每周看三个数——智能体起笔占比、评审通过率、合并后 30 天返工率，前两个涨、第三个不涨，才算真的快。写代码的人不用再加，审代码的规矩必须先加。