GitHub Octoverse 2026：开发活动创新高，超 40% 的 PR 由智能体起草

过去 12 个月，开发者向 GitHub 推送代码 179 亿次，超过 2024 年和 2025 年的总和。

这个数字背后，是开发者在打造自己感兴趣、也是社区需要的东西。在尼泊尔，一位开发者在 GitHub Pages 上搭建了一个洪水公告页面，发布经过核实的道路、救援、天气和电力信息。这个项目后来发展成了 Gati——一个以尼泊尔语为先的官方灾害警报转发服务，运行在 GitHub Pages 和 Actions 上。在别处，NASA 喷气推进实验室的开发者正在开发用于在航天器上运行程序的软件，爱好者们则打造了开源固件，让人们可以自定义自己的电子阅读器。好奇心指向四面八方，规模之大，是 GitHub 前所未见的。

这种增长来得很快。年中前后，GitHub 上的活跃度陡然上扬，恰逢智能体从开发者试用的新玩意，变成了与他们并肩工作的伙伴。开发者可选的模型比以往任何时候都多，涉足的行业也首次出现在本报告的聚光灯下，从医疗健康到农业。

Octoverse 让我们有机会退后一步，看清全貌。今年，这幅图景比以往任何时候都更大。以下是最值得关注的几点：

• AI 更多，一切都更多。在今年新建的仓库中，带有智能体配置文件的仓库平均提交次数，是不带该文件的新仓库的八倍。
• 截至 9 月，开发者发起的拉取请求中超过 40% 由智能体开头。3 月时这个比例还是 17%。对越来越多的工作来说，第一步已经变成指挥智能体，而审查则成了开发者塑造产出结果的方式。
• 开发者在模型选择上动作很快。9 月，61% 的 GitHub Copilot 用户使用了不止一个模型，请求分布在通用模型、深度推理与规划模型，以及快速轻量模型之间。
• 来自各个领域的构建者正在涌现。今年我们首次按行业分享对公开仓库的观察。自 2022 年以来，服务采矿、建筑、医疗健康和农业的仓库数量各自增长了好几倍。

在这一切之下，AI 模型及围绕它们构建的工具框架在过去一年里不断进步，开发者的选择也更多了。增长正在加速：去年我们做出五年开发者增长预测，仅过一年，我们预测的每个国家都已走完通往 2030 年目标的至少五分之一，而我们自己的预测模型对下一步走向已经不再一致。

这一年，开发者定下了新节奏

今年的一切都关乎势头。过去 12 个月，开发者向 GitHub 推送代码变更 179 亿次，超过 2024 年和 2025 年的总和。所有类型仓库（公开和私有）的提交量增长更快，达到 343 亿次，是两年前的三倍多。同期合并的拉取请求增长了两倍多，达到 13 亿次，平均每天 350 万次。

智能体是今年开发者最倚重的工具之一，把它们更深地带入了日常工作。在今年新建的仓库中，带有智能体配置文件的仓库平均提交次数，是不带该文件的新仓库的八倍，这表明从第一天起就用智能体构建的个人和团队，节奏明显不同。

开发者还借助自动化让项目持续推进。今年 GitHub Actions 每秒运行 1,440 次作业，相当于每天 1.24 亿次，是去年总量的三倍多。开发者合并了超过 3,000 万个 Dependabot 拉取请求，以保持依赖项最新、减少已知漏洞的使用，速度约为 2025 年的两倍。

我们的遥测数据显示，活动从 1 月起稳步攀升，到 6 月前后急剧上升，仿佛各地的开发者同时看到了新的可能。也正是在那时，一系列行业性变化集中落地：底层模型变得更强，围绕模型构建的框架和工具日趋成熟，运行其上的智能体也随之进化。智能体从单次会话的工具，变成了能跨天跟踪进度、还能调度其他专用智能体的持久化工具。同样重要的是，智能体开始大量使用云端，既能远程执行任务，也能在本地机器上运行。

这股势头既体现在全新的代码仓库上，也来自多年耕耘的开发者。从 6 月起，约 55% 的提交来自全新仓库。但更多提交来自老开发者：过去 12 个月推送过代码的开发者，平均已在 GitHub 上活跃 36 个月；而在 8 月提交过拉取请求的人中，超过 75% 在 9 月也推送了代码。他们的活动范围也在扩大：如今开发者平均参与的仓库数量比一年前多了 10%。

这种持续投入也体现在开源领域。2026 年公开贡献量飙升至 25 亿次，是去年总量（11.2 亿次）的两倍多。这些数字背后是持续活跃的开发者，比如 @kinlane， 他通过智能体工作流在自己的公开仓库中贡献超过 100 万次，让一份机器可读的公共 API 信息目录保持更新。另一个例子是 @kim-em，他在维护 mathlib（一个由计算机校验的数学社区库）期间贡献超过 17.8 万次。开源电动汽车充电控制器与家庭能源管理系统 evcc 的维护者 @andig 贡献超过 2.1 万次。

这些只是数百万开发者日常工作中的几个例子。对所有正在做这类工作以及更多事情的开发者：我们看到了你们，也很高兴你们在创造。

开发者正在更多地方构建

这份报告中的每个数字背后都是一位开发者。GitHub 目前服务超过 2.25 亿开发者，社区正在全球各地壮大。美国（3,830 万）和印度（3,200 万）仍是两大开发者社区，今年各新增超过 1,000 万开发者。巴西今年在 GitHub 上新增 328 万开发者，增量在各国中排名第三。

去年，我们预测到2030年印度开发者数量将达到5750万，美国将达到5470万。如今这个五年窗口才过去一年，我们预测中的每个国家都已经走完了通往各自2030年目标至少五分之一的路程。美国已走完38.6%，印度走完28.3%。

同样的势头也出现在各个地区，而每个地区都有自己的本地背景：

一年过去，增长相比去年的预测表现强劲，而要预测未来五年则越来越难。我们运行了40多个预测模型，外推到2031年，这些基于历史注册和使用数据的时间序列与回归模型，各自假设了不同的增长速度。约一半模型预测“极端”增长，即到2031年GitHub上的开发者数量增长两倍以上。略低于一半的模型预测“大幅”增长，即翻倍到增长两倍。只有三个模型预计增长接近温和水平，即不到2倍。

预测只是估计，如此大的分歧说明2026年的激增让2031年的可能区间变得多么宽泛。保持不变的是趋势的形态：开发者社区正在更多地方同时成长。

未来正在各处被构建

在过去的报告中，“各处”意味着更多开发者和更多国家，比如在向公共仓库贡献代码的头部国家这一语境下：

按公开仓库推送量排名的前10个国家（按个人资料所在地调整） 

今年，它还意味着更多领域，包括我们此前未曾测量的行业。

我们使用北美行业分类系统（NAICS）来呈现按行业划分的公共仓库情况，该系统将经济活动划分为不同部门。一个语言模型对2022年至2026年每年创建的公共仓库随机样本进行分类，根据其名称、描述、主题和README，将每个仓库归入它所服务的行业。我们还追踪了两个信号：仓库是否提及AI，以及是否有智能体对其发起过拉取请求。

这两个信号并不总是同步变化。在行政与支持服务、采矿、医疗保健和农业领域，超过四成的代码仓库提到 AI，但由智能体发起的拉取请求却很少，不到 3%。建筑业则打破了这一规律：约四分之一的仓库提到 AI，但约 9% 有智能体发起的拉取请求，是所有行业中占比最高的，制造业紧随其后。

同一套分类还显示出各行业的版图自 2022 年以来如何变化，而且远不止软件行业在攀升。专业、科学与技术服务从所有行业中的第四位升至第二位，仅次于信息业。农业、林业、渔业和狩猎业上升两位，金融与保险业、医疗保健与社会援助业各上升一位。以各行业自身 2022 年的基线衡量，采矿、采石及油气开采业从很小的起点增长了约 65 倍，行政与支持服务业和建筑业增长了 17 至 18 倍，即便是其中增长最慢的制造业也几乎翻了三倍。

这些行业变化的背后，是了解自身领域的人开始用 AI 编程智能体来开发。例如在制造业，一个小团队做出了把工具照片变成定制贴合、可 3D 打印的抽屉收纳格的方法。医疗保健领域的一个研究实验室让科学家更容易分析组织样本的大型数字扫描图像，也就是病理学家研究疾病时所看的那类图像。在哥本哈根，一个大学实验室搭建了一条流水线，对鸡玩耍的视频进行分类，从嬉戏到追虫子。怀卡托大学的能源中心开发了一套工具包，帮助工厂找出可再利用的热量，保加利亚数字部开源了一个门户网站，任何人都能查到公共合同由谁中标、金额多少。在写作领域，一位小说家做了一个免费应用，让你边打字边看到手稿呈现出书的样子。在一个又一个领域，最贴近问题的人正在构建解决方案，智能体一路相助。

专业、科学与技术服务较其 2022 年基线增长约 5 倍，升至第二位。这一行业做的是研究、工程和咨询，而开放代码长期以来就是这类工作的一部分。在生物化学领域，AlphaFold 背后的工作让 Demis Hassabis 和 John Jumper 分享了 2024 年诺贝尔化学奖。在计算机科学领域，Tensor2Tensor 伴随那篇提出 Transformer 的论文发布，而 Transformer 正是当今大语言模型背后的架构，论文题为《Attention Is All You Need》。在医学领域，sars-cov-2-stability 保存了最早一批研究病毒在空气和物体表面能存活多久的论文之一的代码和数据。在物理学领域，eht-imaging 是用于重建首张黑洞图像的两个开源库之一。代码仓库已悄然成为已发表研究背后文献链条的一部分。

开发者正在重塑自己的工作流程

如今更多开发者发起拉取请求时，先说明自己想要什么，再调度智能体去完成。到 2026 年 9 月，GitHub 上超过 40% 的拉取请求以智能体的初稿起步，而 3 月这一比例是 17%。仅 9 月就有 1.1 亿个，约为 3 月数量的 6 倍。

由智能体发起的拉取请求也往往更常改动多个文件：约 87%，而没有检测到智能体参与的拉取请求为 79%。它们的合并速度也很快。今年 2 月，智能体参与的拉取请求有 83% 在两周内合并，略低于未检测到智能体参与的拉取请求约 86% 的水平。到 9 月，智能体拉取请求的这一比例达到 90%，而对照组维持在约 86%。

在 GitHub Copilot 的月活跃用户中，如今有 55% 使用智能体功能，高于一年前的 35%。增长最猛的是最省心的模式。Copilot 云智能体由开发者分配任务、智能体独立完成，同比增长 230%，而智能体对话模式增长 85%。开发者仍会向智能体提问，但越来越多地把整个任务交给它。

这种乐于委派的意愿也体现在开发者尝试的任务类型上。提及互操作性或逆向工程的公开仓库同比增长超过 300%，从 2025 年创建的约 3 万个增至 2026 年的超过 13 万个。

评审是开发者塑造产出结果的地方，相关工具也在不断丰富。堆叠式拉取请求把相关工作拆成更小的改动，便于按顺序评审，于 7 月 30 日推出预览版，到 9 月已有超过 26.4 万名开发者使用。AI 辅助代码评审和 GitHub Advanced Security 的使用量均同比增长超过 90%。平台也在帮助保障这些工作的安全：推送保护功能会筛查 API 密钥、密码等泄露的机密信息，今年执行了 58 亿次扫描，接近 2025 年速度的四倍。开发者正在评审方式上加大投入。

模型选择紧跟开发者的节奏

开发者会根据交给智能体的工作来匹配模型。2026 年 9 月，在自行选择模型的 GitHub Copilot 用户中，有 61% 在不同会话中使用过不止一个模型，高于四个月前的 50%。

可选模型也在增多：付费 GitHub Copilot 计划的开发者在 5 月使用了 29 个不同模型，9 月增至 47 个，当月没有任何单一模型的请求占比超过 25%。有些模型选择取决于成本和熟悉程度。开发者会权衡价格与功能是否契合需求，也可能倾向于自己已经信任的提供商。

为了解开发者的选择如何分布，我们按用途把 GitHub Copilot 中使用的模型分为三类：深度推理与规划、通用、快速轻量。然后我们统计请求的流向，只计入开发者明确选择模型的活动。这排除了 GitHub Copilot 自动选择模型（自动模型选择）的情况、GitHub 和微软员工的用量、后台工具类模型、用于监控和测试的重复请求，以及使用开发者自己的 API 密钥发出的请求。

我们发现，在开发者自行选择的每 100 个请求中，38 个流向通用模型，37 个流向深度推理与规划模型，25 个流向快速轻量模型。开发者的选择分散在不同模型和功能上，约 25% 的请求流向快速模型。

为了解这些选择如何变化，我们将其作为过去三个月的时间序列来观察，追踪请求份额，以及有多少开发者尝试过每个模型、有多少人持续使用。有三种模式尤为突出：

• 大多数开发者还没试过新模型，新模型就已经被大量使用。新模型发布后的头几周，它承接的请求占比往往高于已经试用过它的开发者占比。早期尝鲜者会先用起来，其他人才会跟进。
• 开发者对某个模型的使用减少之后，仍会把它留在轮换名单里。当某个模型的请求占比下降时，仍在用它的开发者占比下降得更慢。
• 开发者会混用不同类型的模型。请求分散在三类模型上，很少有开发者长期只用其中一类。

综合来看，模型类型的分散说明开发者在做大量选择：可选阵容不断扩大，最合适的模型随任务而变，三类模型都在轮换使用。不少开发者还让 GitHub Copilot 分担一部分选择工作。2026 年 9 月，63% 的付费 GitHub Copilot 开发者至少用过一次自动模型选择，由 Copilot 为任务挑选模型。

规划、实现和检查一项改动，对模型的能力、速度和成本各有不同要求。Project HydraFusion 最初是模型编排的研究预览，为这项工作的每个步骤匹配模型。在 CLI 和 GitHub Copilot 应用中，它路由了将近 6 万个会话。这项工作现已正式发布为 GitHub Copilot Fusion，把模型编排与自动模型选择结合起来，在后台为每个步骤挑选合适的模型。

语言选择有了新的影响因素

长期以来，语言选择反映的是开发者想构建什么、团队掌握什么，以及现有系统有什么要求。今年的数据引出一个问题：是否正在出现第四个影响因素——当开发者没有指定语言时，智能体自己会选哪种语言。

去年我们曾报告，TypeScript 已超过 Python 和 JavaScript，成为 GitHub 上贡献者使用最多的语言。2026 年这一排序保持不变：TypeScript 第一，Python 第二，JavaScript 第三。但增长速度加快了。从 2025 年 9 月到 2026 年 9 月，TypeScript 新增 362 万月度贡献者，Python 新增 323 万，JavaScript 新增 182 万，是前十大语言中增量最大的。按百分比计算，Rust 在前十大语言中增长最快，过去一年翻了一番。

我们的预测延续了近期趋势：到 2027 年 9 月，TypeScript 和 Python 的月度贡献者将各自接近 1300 万，JavaScript 为 740 万，前十大语言中其余每种都低于约 220 万。

增长最快的语言，也是 AI 出现最多的地方。我们把每种语言过去一年的社区增长，与其已合并拉取请求中检测到 AI 参与的占比做了对照，气泡大小大致反映各语言社区的规模。增长最快的 TypeScript、Python 和 Rust 社区，这一占比也最高，约为已合并拉取请求的 40% 到 44%。Java、C# 和 C++ 较低，约在 21% 到 34% 之间；不过图中列出的每种语言，都有超过五分之一的已合并拉取请求涉及 AI。

仓库数据则提供了另一个视角。在 2026 年创建的仓库中，有智能体信号可观测的仓库里，TypeScript 作为主要语言的比例为 35%，而没有该信号的仓库仅为 24%。对于 2026 年之前创建的仓库，差距类似：有智能体信号的为 27%，没有的为 17%。这说明与智能体打交道的开发者，更倾向于选择那些智能体产出更容易校验的语言。清楚知道自己想要什么的开发者仍会明确指定语言。但当他们把选择权放开时，智能体似乎更偏爱范围更窄的一组语言，其中 TypeScript 居首。

哪些项目吸引了开发者的注意力

今年，我们把 GitHub 上增长最快、互动最活跃的项目分成两类：社区与独立仓库，以及单一厂商或产品主导的仓库。社区与独立项目由基金会治理、由广泛群体维护，或由没有明确商业赞助方的个人主导。单一厂商与产品主导的项目属于开源或源码可用项目，往往也接受大量社区贡献，但战略控制权掌握在一家公司手中。

把两份榜单放在一起看，能看出一种分工。社区一侧主要是支撑其他一切的基础层：vLLM、SGLang、llama.cpp 这类推理引擎，PyTorch 这类框架，Rust、CPython 这类语言与运行时，以及 Home Assistant、Godot 这类平台。厂商一侧则主要是开发者直接使用的工具：编程智能体、编辑器，以及围绕它们的编排工具。两层都有贡献者参与。增长榜里还包括一些专为迎接新人而建的项目，比如 first-contributions 和 is-a-dev/register，许多开发者在那里提交了人生第一个拉取请求。

今年贡献者增长最快的仓库 

互动最活跃的开源仓库 

不变的部分

在今年开展研究的过程中，我们还统计了开发者在代码仓库里最常用的 emoji。在我们考察的每一个行业里，🚀 火箭都高居榜首，而且领先幅度很大。用它来象征这充满势头的一年，再合适不过。今年 GitHub 上的开发者走得更远：代码更多，覆盖的国家更多，涉及的行业也比我们以往统计过的任何时候都多。但这一切活动，都没有改变一件事：代码该做什么，仍然由人来决定。想法总得有人来提——无论是评估地震风险的软件、记录在线服务如何修改条款和隐私政策的公开档案，还是让 AI 像穴居人一样说话以节省字数的智能体技能。而它是否行得通、是否该做、是否足够好，也仍然得由人来判断。

真正改变的是：把一个周末冒出的念头变成现实，如今要容易得多。

工具会不断变化，新的行业也会在我们意想不到的地方冒出来。但开发者选择构建什么、为谁而建，决定权依然在他们自己手里。火箭 emoji 也一样。

术语表

• 智能体配置文件：用于配置或指导 AI 编程智能体的仓库文件，也称 AI 配置文件或智能体文件。没有这类文件的仓库同样可以使用 AI。
• 智能体信号：在遥测数据中观察到的智能体参与迹象，例如由智能体发起的拉取请求。由于并非所有智能体使用都能被检测到，这只是一个下限。
• 智能体发起的拉取请求：初稿由我们能检测到的编程智能体生成的拉取请求。
• 自动模型选择：GitHub Copilot 的一项设置，由 Copilot 为任务挑选模型。
• 提交：仓库变更的一份已保存快照。
• 贡献：活动事件，包括：对提交、议题、拉取请求或讨论发表评论；创建 gist、议题、拉取请求或讨论；推送代码；以及审查拉取请求。每次推送只计一次，无论其中包含多少次提交。开源贡献指对公开仓库和开源仓库的贡献。
• 贡献者：在统计周期内至少有一次贡献的 GitHub 用户。
• Copilot 云端智能体：GitHub Copilot 的一项功能，开发者指派任务后，由智能体独立完成。
• Dependabot：GitHub 的自动化工具，用于发现过时或有漏洞的依赖，并创建拉取请求来更新它们。
• 开发者自选请求：由开发者自行选择模型的请求。它不包括自动模型选择、员工使用、重复的监控与测试请求、后台工具类模型，以及使用开发者自己的 API 密钥发出的请求。
• GitHub Actions 作业：GitHub Actions 工作流中的一个独立工作单元。
• GitHub Advanced Security：GitHub 的一套应用安全功能，包括代码扫描、机密扫描和依赖审查。
• NAICS：北美行业分类系统，今年用于按行业对公开仓库进行分类的标准行业分类法。
• Project HydraFusion：GitHub 的模型编排研究预览版，可跨多个模型规划任务，例如一个模型起草、另一个模型审查，需要时再由能力更强的模型介入。现已作为 GitHub Copilot Fusion 正式发布。
• 推送（Push）：把已保存的改动发送到 GitHub。一次推送可以包含多个提交。
• 堆叠式拉取请求：一种评审流程，把相关工作拆成一系列较小的拉取请求，按顺序逐一评审。

方法论

• 范围与统计窗口。Octoverse 年度统计区间为 2025 年 10 月 1 日至 2026 年 9 月 30 日（含首尾）。除特别说明外，各项指标均涵盖公开和私有仓库。行业、开源贡献和开源项目相关数据仅统计公开仓库。往年数据：2024 年和 2025 年的数字已按相同定义和统计窗口重新计算，因此可能与早先报告不一致——早先报告只统计公开活动，窗口为 9 月 1 日至次年 8 月 31 日。
• 推送、提交与贡献。一次推送会把一个或多个提交发送到 GitHub。贡献按推送计一次，因此提交总数可能高于贡献总数。Actions 按作业数统计，不按分钟数。开源贡献（25 亿）仅统计公开仓库。
• 过滤。贡献者和贡献计数会排除可识别的垃圾账号、员工和机器人。
• 地域与预测。开发者按自报所在地归入国家/地区，发布门槛为 100 名开发者。Octoverse 2025 发布的是 2030 年总量，而非年度目标。进度按 2025 年 9 月至 2026 年 9 月净增开发者数，占各国从已发布的 2025 年数量到其 2030 年预测值之间差距的比例计算。
• 语言。贡献者指每月通过推送、拉取请求、议题、评审或评论参与的去重账号，按各仓库的主要语言（Linguist）归属。同一账号可计入多种语言。此处沿用 Octoverse 2025 的方法。预测覆盖月均参与度排名前 10 的语言，并推算至 2027 年 9 月（图中显示均值）。
• 语言气泡图对比 2025 年 9 月至 2026 年 9 月间月度参与账号的增长，与检测到 AI 参与的已合并拉取请求占比。气泡大小反映社区规模。
• 按向公开仓库推送量排名的国家/地区（按个人资料所在地调整）。统计区间内，各国/地区的推送量逐项累加。为校正 VPN 使用带来的偏差，使用 LLM 分类从该时段内贡献过推送的 GitHub 用户个人资料中提取 ISO 3166-1 alpha-2 代码，再据此构建基于个人资料所在地与基于 IP 地址的 ISO 3166-1 alpha-2 代码之比，用这些比值对各国/地区的推送量加权。
• 行业。对 2022 至 2026 年创建的公开仓库，按年份随机抽样，用微调的多语言嵌入模型依据名称、描述、主题和 README 归入 NAICS 行业分类。AI 提及和由智能体发起的拉取请求（仅限可检测的智能体）作为单独信号标记。行业占比与 AI 提及占比可能相关，因为二者读取的是同一文本。占比均为估算值。
• 开源排名。按谁掌握战略控制权，将仓库分为社区型或单一厂商型。“增长最快”按去重贡献账号的同比绝对增量排名。“参与度最高”综合仓库在星标、复刻以及去重拉取请求和议题创建者方面的排名。复刻仓库不列入这两份榜单。
• 模型选择。数据涵盖 GitHub Copilot，且只统计开发者主动选择的请求，不含自动模型选择、员工使用、重复的监控请求、后台工具类模型，以及开发者使用自己 API 密钥发起的请求。每个模型每周至少要有 1,000 名活跃用户才计入统计。模型按用途分组，示例按提供商名称字母顺序排列：
• 深度推理与规划：Claude Opus 5.5、GPT 5.5。
• 通用：Claude Sonnet 5、Grok 4.7、GPT 6.1 Sol。
• 快速轻量：Claude Haiku 5.5、Gemini 3.8 Flash、GPT 6 Luna。
• 数据反映的是实际观察到的使用情况，不代表模型质量。趋势观察采用 2026 年 7 月 14 日至 10 月 13 日的周度数据。
• 请求占比指截至 2026 年 10 月 13 日的 7 天内，各模型组中每个模型占该组全部合格请求的比例。
• 互操作性。统计每年创建的公开仓库，其名称、描述、话题或 README 中提到互操作性或逆向工程，或相关术语，例如净室实现、直接替换、协议重新实现。
• 预测。我们对历史 GitHub 数据、注册量、产品使用情况和市场规模运行了 43 个时间序列与回归模型，预测 GitHub 上的开发者数量在 2031 年 9 月相对 2026 年 9 月的变化。结果分为三组：3 倍及以上（21 个模型）、2 倍至不足 3 倍（19 个）、不足 2 倍（3 个）。Octoverse 2025 使用了五个模型。没有哪个预测是完全准确的。

文章 Octoverse：2026 年开发者借助智能体开发，提交、推送与覆盖范围均创新高 最早发布于 The GitHub Blog。