一、四成改动的初稿不是人写的
GitHub 在 10 月 28 日的 Universe 大会上放出今年的 Octoverse 报告，统计窗口是 2025 年 10 月到 2026 年 9 月，覆盖公开与私有仓库。报告里最硬的一句：到 2026 年 9 月，平台上超过 40% 的拉取请求，初稿由编码智能体写出，同年 3 月这个数字是 17%。9 月单月智能体起稿的拉取请求有 1.1 亿个，约为 3 月用量的 6 倍[1][2]。
半年时间，从不到两成到超过四成。GitHub 在术语表里把“智能体起稿”定义为初稿来自它能识别的编码智能体，方法章节紧接着补了一句限定：这是下限，因为并非所有智能体使用都能被检测到。用开发者自己的账号提交、在遥测里不留痕迹的那部分，它数不到[1]。
活动量的其余计数同样在跳。这一年开发者推送代码 179 亿次，比 2024 年的 52 亿次和 2025 年的 67 亿次加起来还多；提交 343 亿次，上一年是 129 亿次；合并的拉取请求 13 亿个，日均约 350 万个；GitHub Actions 跑了 454 亿个任务，约合每秒 1440 个。平台开发者总数超过 2.25 亿，美国 3830 万、印度 3200 万[1][8]。
二、曲线在六月拐了个弯
比例不是匀速爬上去的。报告把加速点放在今年六月，给出的理由是底层模型变强、编排工具变成熟，加上智能体开始能跨天跟踪进度并在云端运行。六月之后约 55% 的提交来自全新仓库，新仓库的创建速度翻倍到每月 3030 万个；今年新建的仓库里，带智能体配置文件的提交量约为不带配置文件的 8 倍[8][9]。
后面这组数字要小心读。8 倍是相关性：愿意一开始就配好智能体的团队，本来也可能就是最活跃的那批人。提交计数也不挑内容，废弃分支、测试仓库、机器生成的重复改动一并算进去[9]。
同一天 GitHub 把 Copilot Fusion 从预览转成了正式可用。形态很直接：用户不再挑模型，只在 Standard、High、Max 三档里选一个力度，剩下的交给系统。官方说明写了三条执行路径——单模型直接做、先让成本更低的模型起草再由质量检查决定是否升级、以及一个模型起草另一个模型评审后由前者修订。GitHub 引用 Artificial Analysis 的编码智能体指数说，Fusion Max 得 60 分，比 Claude Code 配 Opus 5.5 Max 低约两分，平均每任务 API 成本 5.59 美元对 11.42 美元，token 约为一半，耗时少约 40%[3][4][5]。这套对比是 GitHub 自己选择引用的评测，不是独立第三方委托做的。
付费 Copilot 用户的行为能解释为什么要做这个收敛。9 月这批人一共用了 47 个不同的模型，没有任何一个占到请求量的 25% 以上；在自选模型的用户里，61% 用了不止一个模型[6][7]。
报告今年还做了一件以前没做的事：用一套行业分类把公开仓库按所属行业分了组，方法是让模型读仓库的名称、描述、标签和说明文件再归类。结果里有一个反差值得记一下——建筑业约 9% 的仓库能检出智能体开的拉取请求，是所有行业里最高的；行政支持、采矿、医疗、农业这几个行业有超过四成的仓库提到 AI，其中能检出智能体拉取请求的不到 3%[1]。提 AI 和让智能体动手改代码，中间还隔着一段路。
三、合并得快，不等于没问题
报告里能沾上“质量”边的只有合并速度。智能体参与的拉取请求在两周内合并的比例，从 2 月的 83% 升到 9 月的 90%，同期未检出智能体参与的对照组维持在约 86%。改动范围也更大：87% 的智能体起稿请求会改动多个文件，对照组是 79%[1][7]。
这两组数字能说明智能体的产出越来越容易被接受，说明不了更多。报告没有回滚率、没有缺陷率，也没有合进去几周后又返工的比例。合并率衡量的是一次改动在落地那一刻是否通过了当时的检查，而一个功能通常要跨好几次改动才成立，最后能不能跑是合完之后才看得出的问题[10]。
对开发者，位置变了。GitHub 在报告里写的那句是：第一步现在是给智能体下指令，评审是开发者塑造结果的方式。Copilot 月活用户里 55% 已经在用智能体功能，一年前是 35%；最放手的一种形态，云端智能体，同比增长 230%，智能体对话是 85%[1]。
对模型厂商，Fusion 这类编排层把“选哪个模型”收进了系统，成本口径从每百万 token 挪到了每任务。47 个模型、无一超过 25% 的份额分布，说明模型这一层在开发者侧已经在被摊薄。同日微软通过 Foundry 开放的 Copilot harness 是同一方向的另一半：编排、上下文、沙箱那一层被做成现成的托管服务[11]。
四、接下来看三件事
一是明年的报告会不会补上质量口径。如果 Octoverse 下一版仍然只有合并率和活动量，那么“四成”这个数字就始终回答不了代码好不好。反过来，一旦出现回滚率或缺陷密度的统计，争论就能从“用不用”转到“用在哪”。
二是这个比例的天花板。40% 是官方自称的下限，真实值只会更高。若明年过半，评审环节的人员配置就得按新的比例重算；若停在四成到五成之间，说明有一类改动智能体接不过去，那类改动的边界值得单独拎出来看。
三是模型选择的归属会不会继续上移。Fusion 把选择权收走之后，厂商在开发者侧的存在感还会继续下降。可跟踪的指标就是那 47 个模型的份额分布：继续分散，说明编排层拿到了定价权；向少数几个集中，说明编排层的调度最终还是绕不开头部模型。
来源与说明
检索截止：2026-10-29 20:10（Asia/Shanghai）。
[1] Octoverse: Commits, pushes, reach new highs in 2026 as developers build with agents｜GitHub Blog｜2026-10-28 [2] GitHub Octoverse 2026｜Simon Willison’s Weblog｜2026-10-28 [3] Route and orchestrate models with GitHub Copilot Fusion｜GitHub Blog｜2026-10-28 [4] GitHub debuts Copilot Fusion, a new model selection & orchestration system｜The New Stack｜2026-10-28 [5] GitHub Copilot Fusion mixes models to achieve near-Opus 5.5 coding performance at half the per-task cost｜VentureBeat｜2026-10-28 [6] GitHub’s artwork for Universe 2026｜The Next Web｜2026-10-29 [7] GitHub Octoverse 2026: Agents Now Start Over 40% of Pull Requests, Up From 17% in March｜AI Bacon｜2026-10-28 [8] GitHub developers pushed code 17.9 billion times in 2026 as AI agents reshape how software gets built｜LavX News｜2026-10-29 [9] GitHub Octoverse 2026: 7.4 Billion Commits a Month, 40% of Pull Requests Start With an Agent｜ExplainX｜2026-10-29 [10] GitHub Octoverse 2026: merged PRs triple to 220M a month｜Glonce｜2026-10-28 [11] Introducing the Microsoft Copilot harness in Foundry Agent Service｜Microsoft Foundry Blog｜2026-10-28