2026年10月28日，旧金山Universe大会，GitHub照例发布年度Octoverse报告。开发者社区讨论最多的是一组比例：2026年9月，超过40%的拉取请求（PR）出自AI代理之手，总数逾1.1亿个。往回数六个月，3月时这个数字还只有17%。
半年时间翻了一倍多，这不是慢慢爬坡，是一个拐点。
数字背后的机制：为什么是现在
GitHub官方博客的说法是，这轮加速不是由某个模型或某个产品单独带起来的，整个代理生态都在同步提速。最能说明问题的是仓库配置这一层：2026年新建仓库中，带代理配置文件（agent configuration file）的那部分，提交量是不带此类文件的普通仓库的8倍。增长是开发者主动铺出来的路，不是自己长出来的。
同期披露的另一组数字是：Copilot月活用户里，55%已经在用代理功能，一年前这项占比是35%；云端自主代理的使用量比去年同期涨了230%。三组数字放在一起，指向的判断很清楚——代理进生产环境的门槛已经低到主流开发者愿意大批量部署，不再只是早期极客的玩具。
质量上，代理提交的PR和人类提交的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还有一组数据：在主动选过模型的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%对79%），审查难度是结构性地往上走的。逐行审查的老办法前提是审查者能看懂每一行的意图，可代理几秒钟就生成几百行跨文件改动，这个前提已经站不住了。
合并率偏高，一部分原因可能是审查标准在悄悄放松，也可能审查环节本身越来越依赖AI帮忙。这个推断目前还没有足够数据支撑，但代码质量和安全责任会受到什么长期影响，一张合并率图表装不下。
独立判断
GitHub Octoverse 2026是目前规模最大、来源最权威的一份"AI代理进入生产环境"佐证。它说明了两件事。代理早已走出概念验证，在实际软件开发中承担起了可测量的生产份额；平台层面和工程团队层面的现有基础设施，都还没为这种量级做好准备。高合并率、高提交量反映的是活跃度，跟质量是两回事。缺陷率、安全漏洞率、回滚率这些数据缺位，"代理PR合并更快"说明的只是流程在提速，软件有没有变好无从判断。GitHub在Octoverse里挑了速度和数量来讲，没披露上述几个维度，这个叙事取舍本身就值得留意。
真正的拐点不在代理占了多少PR。工程团队怎么重新定义"交付标准"才是关键——大量变更来自一个你没法完整追溯其推理过程的系统时，"完成"的含义就必须跟着变。年度报告没回答这个问题，可它已经迫在眉睫。
