GitHub报告：AI代理贡献四成PR，平台急扩400万核心

2026年10月28日，旧金山Universe大会现场，GitHub照例交出了年度Octoverse报告。有个数字让开发者社区炸开了锅：2026年9月，平台上由AI代理发起的拉取请求（Pull Request，PR）占比突破40%，数量超过1.1亿个。往回看仅仅六个月，3月时这个比例才17%。

半年时间翻了一倍多。这不是慢慢爬坡，是拐点到了。

数字背后的机制：为什么是现在

GitHub官方博客给出的解释是，这轮上涨不是哪个模型或哪款产品单独带起来的，整个代理生态在同步提速。最能说明问题的是仓库配置这一层：2026年新建的仓库里，配了代理配置文件（agent configuration file）的，提交量是没配这类文件的普通仓库的8倍。换句话说，开发者是主动给代理铺路，增长是被搭出来的，不是自己冒出来的。

同期披露的还有两组数：Copilot月活用户里55%已经开始用代理功能，一年前这个数字是35%；云端自主代理的使用量同比涨了230%。三组数据摆在一起，指向的是同一件事——代理进生产环境的门槛已经低到主流开发者愿意大规模部署，不再只是早期极客的玩具。

质量维度上，代理PR和人类提交之间也存在可以量化的差别。Octoverse数据显示，代理发起的PR有87%涉及多文件修改，人类开发者这边是79%；两周内完成合并的比例，代理PR从今年2月的83%升到9月的90%，同期人类PR的合并率在86%左右。

合并率更高，就能说明代理质量更好吗？不能这么直接推。高合并率也许是代理产出的代码确实更靠谱，也许是审查者对机器生成的代码门槛放得更低，还可能是代理接的多是例行、低风险的变更。这三种情况，光看数据分不出来。不过三种情况同时存在的可能性更大。

基础设施的代价

增长从来不白给。据The Register报道，GitHub今年已经宣布紧急扩容400万颗CPU核心和160PB高速存储，同时把计算和存储功能拆开做解耦，目标是拿到"35倍的吞吐量提升"。另外，GitHub承诺2027年初完成向多区域Azure架构的迁移。

2026年10月7日，GitHub出过一次全球性宕机，持续两个多小时，Actions、PR、Issues、Webhooks等核心功能都受了影响，Downdetector上的故障报告一小时内超过2500条。服务后来恢复了，但根本原因GitHub没有公开。据DevX等科技媒体报道，这次宕机和全年多次可用性下滑有关联，根源指向AI代理流量的爆炸式增长。GitHub自己也承认，对AI驱动流量的规模"准备不足"。

说到底，GitHub的基础设施是按人类开发者的节奏搭的。代理没有时区，不睡觉，也不用等，能以机器速度全天候提交代码。9月单月7.38亿次提交，是上年同期的五倍多——人类工程师的手速，物理上跑不出这种斜率。

全平台的量级跃升

代理PR只是整体爆发的一个切面。Octoverse报告显示，截至2026年9月的12个月里，GitHub平台总推送量179亿次，比2024年（52亿次）和2025年（67亿次）加起来还多；总提交量343亿次，是2024年（100亿次）的三倍有余；合并PR总量13亿个，摊到每天约350万个；GitHub Actions任务执行量454亿次，相当于每秒1440个任务。

这些数字有个统计口径的变化：2026年的数据把公开和私有仓库活动都算进去了，而早前的Octoverse报告主要统计公开数据。也就是说，历史数字没法直接拿来比，实际增幅可能比表面看到的低一些。但方向上的结论没问题——代理活动正以非线性速度改变平台活动的体量。

模型不再单选

Octoverse报告还有一组数据：在主动选过模型的GitHub Copilot用户中，61%在2026年9月跨会话用了不止一个模型，四个月前这个比例是50%。付费用户5月用了29种不同模型，到9月已经扩到47种，而且当月没有任何单一模型的请求份额超过25%。

这说明"用哪个模型"正在变成开发者主动做的策略选择，不再是默认配置。不同任务配不同模型，真正的生产力入口落在调度层，而不是某一个模型上。GitHub在同次大会上发布的Copilot Fusion——一个自动为每步任务挑最优模型或模型组合的系统——和这个趋势对得很齐。据VentureBeat报道，Copilot Fusion Max在编程代理评测里的表现接近业界顶尖水平，成本却低了约77%，任务耗时少了40%。

对开发者来说，会不会选模型，本身正在变成工程素养的一部分。

开发者角色的实质性变化

微软CEO萨蒂亚·纳德拉（Satya Nadella）在Universe大会上引用了上面这些数据，并把当前阶段概括为："开发者从编写每一行代码，到与AI助手协作，再到编排代理舰队的演变。开发者负责定向、做决策、对交付结果负责，而代理负责实现和验证变更。"

这话带着商业叙事的味道，但数据确实给了它一些支撑。关键是"负责"两个字。40%的PR由代理发起时，审查者拿到的代码往往牵扯多个文件、横跨多个模块——代理更高的多文件PR比例（87% vs 79%），意味着审查难度在结构上抬高了。逐行审查的老办法，前提是审查者能看懂每一行的意图；代理几秒钟就生成几百行跨文件变更，这个前提已经站不住了。

合并率更高，可能有一部分反映的是审查标准在悄悄放松，也可能审查本身越来越依赖AI辅助。这个推断目前还没有足够数据支撑，但代码质量和安全责任的长期影响，一张合并率图表是盖不住的。

独立判断

GitHub Octoverse 2026是到目前为止规模最大、来源最权威的一份"AI代理进入生产环境"的数据佐证。它证明了两件事：其一，代理早已走出概念验证阶段，在实际软件开发中承担起了可测量的生产份额；其二，眼下无论是平台层面还是工程团队层面的基础设施，都还没为这种规模做好准备。

合并率高、提交量大，反映的是活跃程度，跟质量是两回事。缺陷率、安全漏洞率、回滚率这些数据没有摆出来，所谓“代理PR合并更快”就只说明流程提速了，说明不了软件变好了。GitHub在Octoverse里突出速度和数量，这些维度的数据却没披露，这个叙事选择值得留意。

更关键的转折点，其实不在代理拿下了多少PR，而在工程团队怎么重新划定“交付标准”。大量变更出自一个你没法完整追溯其推理过程的系统时，“完成”的定义就得跟着改。年度报告没回答这个问题，可它已经迫在眉睫。