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（一个由计算机校验的数学社区库）期间做出了超过 178,000 次贡献。@andig 是开源电动汽车充电控制器与家庭能源管理系统 evcc 的维护者，贡献超过 21,000 次。

这些只是数百万开发者每天所做工作中的几个例子。致所有从事此类工作以及更多工作的开发者：我们看到了你们，也很高兴你们在构建。

开发者正在更多地方进行构建

本报告中的每一个数字背后都是一位开发者。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 的论文，这一架构正是当今大语言模型的基础，即《Attention Is All You Need》。在医学领域，sars-cov-2-stability 保存了关于病毒在空气和表面存活多久的最早论文之一的代码和数据。在物理学领域，eht-imaging 是用于重建首张黑洞图像的两个开源库之一。一个代码仓库已悄然成为已发表研究背后论文记录的一部分。

开发者正在重塑他们的工作流程

如今更多开发者开始一个拉取请求时，会先说明他们想要什么，并编排执行该任务的智能体。到 2026 年 9 月，GitHub 上超过 40% 的拉取请求以智能体的初稿开始，高于 3 月的 17%。仅 9 月就有 1.1 亿个，约为 3 月数量的 6 倍。

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

在 GitHub Copilot 的月活跃用户中，55% 现在使用 Agent 功能，高于一年前的 35%。增长最陡峭的是最省心的模式。Copilot cloud agent 由开发者分配任务、Agent 独立完成，同比增长 230%，而 Agent 聊天为 85%。开发者仍会向 Agent 提问，并且越来越多地把整个任务交给它。

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

审查是开发者塑造返回结果的环节，为此正在构建更多工具。堆叠拉取请求将相关工作拆分为更小、便于按顺序审查的变更，于 7 月 30 日推出预览版，到 9 月已有超过 264,000 名开发者使用。AI 辅助代码审查和 GitHub Advanced Security 的使用量均同比增长超过 90%。该平台还帮助保护这些工作：推送保护会筛查 API 密钥和密码等泄露的机密，今年运行了 58 亿次扫描，接近 2025 年速度的四倍。开发者正在加大对代码审查方式的投入。

模型选择以开发者的速度变化

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

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

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

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

为了解这些选择如何变化，我们将其视为过去三个月的时间序列，追踪请求份额以及尝试每个模型的开发者数量和持续回访的开发者数量。有三种模式尤为突出：

• 大多数开发者尚未尝试新模型之前，新模型就已被大量使用。在发布后的最初几周，大多数新模型所承接的请求份额，超过了尝试过它们的开发者所占比例。早期采用者会在其他人跟进之前大量使用某个模型。
• 开发者在减少对某个模型的依赖后，仍会将其保留在轮换使用中。当某个模型的请求份额下降时，仍在使用它的开发者比例下降得更慢。
• 开发者会混合使用不同类型的模型。请求分散在全部三类模型上，很少有开发者长期只使用某一类模型。

综合来看，跨模型类型的分布表明开发者做了大量选择：模型阵容持续扩大，最佳选择随任务不同而变化，三类模型都在轮换使用。许多开发者还让 GitHub Copilot 承担其中一部分工作。2026 年 9 月，63% 的付费 GitHub Copilot 开发者至少使用过一次自动模型选择，让 Copilot 为任务挑选模型。

规划、实现和检查一项变更，各自对模型的能力、速度和成本提出了不同要求。Project HydraFusion 最初是模型编排的研究预览，将模型与这项工作的每个步骤相匹配。在 CLI 和 GitHub Copilot 应用中，它路由了近 60,000 个会话。这项工作现已作为 GitHub Copilot Fusion 正式可用，它将模型编排与自动模型选择结合在一起，在后台为每个步骤选择正确的模型。

语言选择有了新的影响力

语言选择长期以来反映了开发者想构建什么、团队了解什么以及现有系统需要什么。今年的数据提出了一个问题：第四种影响力是否正在出现——当开发者没有指定语言时，智能体所选择的语言。

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

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

增长最快的语言也是 AI 出现最多的语言。我们将每种语言过去一年的社区增长与其合并拉取请求中检测到 AI 参与的份额进行了对照，气泡大小大致表示每种语言社区的规模。TypeScript、Python 和 Rust 是增长最快的社区，其份额也最高，约 40% 到 44% 的合并拉取请求涉及 AI。Java、C# 和 C++ 较低，约在 21% 到 34% 之间，不过在所示的所有语言中，每五个合并拉取请求中就有一个以上涉及 AI。

仓库数据提供了另一个视角。在 2026 年创建的仓库中，有可观察到的 agent 信号的仓库里，TypeScript 作为主要语言的比例为 35%，而没有 agent 信号的仓库中这一比例为 24%。对于 2026 年之前创建的仓库，差距类似：有 agent 信号的为 27%，没有的为 17%。这表明与 agent 打交道的开发者倾向于使用那些 agent 输出更容易检查的语言。清楚知道自己想要什么的开发者仍然会指定语言。但当他们把选择权留空时，agent 似乎会偏向更窄的一组语言，其中 TypeScript 居首。

什么在吸引开发者的注意力

今年，我们将 GitHub 上增长最快、参与度最高的项目分为两组：社区与独立仓库，以及单一厂商或产品主导的仓库。社区与独立项目由基金会治理、广泛维护，或由个人领导且没有明确的商业赞助方。单一厂商和产品主导的项目是开源或源码可用的，通常也会接受大量社区贡献，但战略控制权掌握在一家公司手中。

综合来看，这两份榜单显示出一种分工。社区一侧主要是支撑其他一切的基础设施：像 vLLM、SGLang 和 llama.cpp 这样的推理引擎，像 PyTorch 这样的框架，像 Rust 和 CPython 这样的语言与运行时，以及像 Home Assistant 和 Godot 这样的平台。厂商一侧主要是开发者直接使用的工具：编码 agent、编辑器以及围绕它们的编排工具。贡献者在两个层面都有参与。增长榜单还包括一些专为欢迎新人而建的地方，比如 first-contributions 和 is-a-dev/register，许多开发者在那里提交了他们的第一个 pull request。

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

参与度最高的开源仓库 

不变的是什么

作为今年研究的一部分，我们还统计了开发者在各自代码库中最常使用的 emoji。在我们考察的每一个行业中，火箭 🚀 都以巨大优势位居榜首。它恰如其分地象征了这充满动能的一年。今年，GitHub 上的开发者涉足了更广阔的领域：比以往任何时候都更多的代码、更多的国家和更多的行业。但这一切活动都没有改变由谁来决定代码应该做什么。仍然需要有人提出想法，无论是评估地震风险的软件、在线服务如何更改其条款和隐私政策的公开记录，还是让 AI 像穴居人一样回答以节省字数的 agent 技能。也仍然需要有人来决定它是否可行、是否该被纳入，以及它是否足够好。

真正改变的是，把一个周末的灵光一现变成现实变得容易了许多。

工具会不断变化，新的行业会不断在我们意想不到的地方出现。开发者选择构建什么、为谁构建，仍然由他们自己决定。火箭 emoji 以及一切皆是如此。

术语表

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

方法论

• 范围与时间窗口。Octoverse 年度统计期为 2025 年 10 月 1 日至 2026 年 9 月 30 日（含首尾）。除非另有说明，指标涵盖公开和私有仓库。行业、开源贡献和开源项目数据仅限公开仓库。往年数据：2024 年和 2025 年的数据按相同定义和时间窗口重新计算，因此可能与早期报告存在差异，早期报告仅涵盖公开活动，且时间窗口为 9 月 1 日至 8 月 31 日。
• 推送、提交与贡献。一次推送会将一个或多个提交发送到 GitHub。贡献数对每次推送只计一次，因此提交总数可能超过贡献总数。Actions 按作业（job）计数，而非按分钟计数。开源贡献（25 亿）为公开数据。
• 过滤。贡献者和贡献计数在可识别的情况下排除被标记为垃圾信息的账户、员工和机器人。
• 地理与预测。开发者按自报位置映射到国家/地区，发布阈值为 100 名开发者。Octoverse 2025 发布的是 2030 年总量，而非年度目标。进展指 2025 年 9 月至 2026 年 9 月净增开发者数，占各国已发布的 2025 年数量到其 2030 年预测值之间距离的比例。
• 语言。贡献者指每月通过推送、拉取请求、议题、评审或评论参与的去重账户，按各仓库的主要语言（Linguist）归属。一个账户可计入多种语言。此方法沿用 Octoverse 2025 的做法。预测覆盖按月均参与度排名前 10 的语言，并预测至 2027 年 9 月（显示均值）。
• 语言气泡图比较了 2025 年 9 月至 2026 年 9 月间月度参与账户的增长，与检测到 AI 参与的已合并拉取请求占比之间的关系。气泡大小反映社区规模。
• 按对公开仓库的推送量排名的国家/地区（按个人资料位置调整）。各国推送量按 Octoverse 年度汇总。为校正 VPN 使用带来的偏差，使用 LLM 分类从该期间有推送贡献的 GitHub 用户个人资料中提取 ISO 3166-1 alpha-2 代码，再据此构建基于个人资料位置的 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。