四成 PR 由智能体起稿
10 月 28 日，GitHub Universe 2026 在旧金山举行，同日发布 Octoverse 2026 年度报告，覆盖截至 9 月 30 日的十二个月。报告最硬的一个数字是：到 9 月，超过 40% 的 pull request 起始草稿由智能体写出，而 3 月这个比例还是 17%。9 月单月约 1.1 亿个，约为 3 月量的六倍。
口径要先说清楚，否则这个数字容易被夸大。GitHub 的定义是「初始草稿来自官方能够检测到的编码智能体」的 PR，因此官方自己说这是下限；而且一个 PR 即便后来被人大幅改写，仍计入这一类。换句话说，它衡量的是谁起的头，不是谁完成的。
其余体量数字同样创了纪录：全年 179 亿次 push，超过 2024 与 2025 两年总和；343 亿次 commit；13 亿个合并 PR，日均 350 万个；GitHub Actions 跑完 454 亿个任务，平均每秒 1440 个。开发者总数超过 2.25 亿，美国 3830 万、印度 3200 万。
模型忠诚度没了，路由层就有了位置
另一组数字解释了为什么 GitHub 要在同一天发布 Copilot Fusion。9 月，自己选过模型的 Copilot 用户里有 61% 用了不止一个模型，四个月前是 50%。付费开发者在 5 月用到 29 个不同模型，到 9 月是 47 个，而当月没有任何一款模型承载超过四分之一的请求。每 100 次开发者自选请求里，38 次给通用模型，37 次给深度推理与规划模型，25 次给快速轻量模型。
这组数据说的不是哪个模型更好，而是开发者已经不再忠于任何一款。这恰好是路由层存在的理由：既然选择本身就是分散的、且随步骤变化的，那就把它交给系统。
Fusion 由微软 CoreAI 负责人 Jay Parikh 在 GitHub 博客中介绍，当日正式可用。它按每一步的需要——推理、代码生成、调试还是工具使用——把工作路由到一个或多个模型，提供 Standard、High、Max 三档，后端可走 Single（单模型直解）、Cascade（较弱模型起草、质检不通过再升级）、Critique（一个写一个审、原模型改）三种工作流。
官方口径的成绩，与没人复核的部分
官方称 Fusion Max 在 Artificial Analysis 编码智能体指数上与对照的 Opus 5.5 Max 相差两分以内，成本约为一半、每任务耗时少约四成。纳德拉在社交平台上的表述是前沿水准的质量、快四成、最多降低 77% 成本。
这些数字有三个要分开看的地方。其一，全部是公司自述，没有独立第三方复核。其二，两个来源的降本幅度不一致——博客说成本约一半，社交平台说最多 77%，口径差异未见说明。其三，对照基准是编码智能体指数，与真实仓库上的表现是两回事。
产品侧还有几件：Copilot app 把跨项目的智能体与工具连到同一个界面；Copilot projects 支持跨多个仓库的并行会话；云端智能体会话可以在 app、VS Code、命令行与网页之间迁移；Copilot automations 能从自己的运行结果中学习并提出改动供人批准；代码评审新增 Max 档，官方称在 ReviewBench 的高危问题上取得最高 F1，做法是综合多家模型供应商的评审者。
承压的地方挪到了评审
把这些连起来看，GitHub 真正在说的是重心的移动。起稿环节被智能体接走之后，人的时间越来越集中在审查、批准与判断上，于是这一环成了新的约束。
几个数字支持这个判断。9 月检测到的智能体起稿 PR 中，有 90% 在两周内合并，2 月是 83%；没有检测到智能体的 PR 两个月都约为 86%。同时，智能体起稿的 PR 里 87% 改动多于一个文件，无智能体的只有 79%——改动面更大，审起来更费劲。
三盆冷水，和一条实操建议
冷水有三盆，都该浇。其一，报告没有公布回滚率与缺陷率，两周内合并比例高说明的是流程顺畅，不说明改动正确——这两件事在数据里被混在一起了。其二，今年新建仓库中带智能体配置文件的平均提交数约为无配置新仓库的八倍，但这是自选人群里的相关性，官方也没有主张因果：一开始就按智能体优先搭仓库的团队，可能本来就更熟练、目标更清楚。其三，计费方式的变化值得警惕——企业客户改为按 AI 积分付费，支出从此随用量波动，一个忙碌的智能体机群可能比固定席位更贵。对已在受监管代码库上验证过特定模型的团队，档位化还可能绕过既有的偏好设置，需要在管理策略里单独关掉。
基建侧的压力是同一件事的另一面。官方称今年新增 400 万 CPU 核、160PB 高速存储与 50Tb/s 网络容量，并正向 Azure 多区域部署迁移，预计明年初完成；有媒体报道称智能体流量曾造成多次服务中断。当四成的 PR 由智能体起稿时，可用性本身就变成了开发工具链的一部分。
给团队的实操建议其实很朴素：盯每个合并 PR 的成本，而不是基准分差；已经在手工混用模型的团队，先拿自己的 PR 跑一遍 Fusion 再动合同。至于报告里那些漂亮的体量数字，它们证明了事情正在发生，还没证明事情正在变好。