GitHub Octoverse 2026 年度报告：代码推送量创新高，超四成拉取请求由智能体起草

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

这一数字背后，是开发者们在构建他们感兴趣的东西以及他们的社区所需要的东西。在尼泊尔，一位开发者在 GitHub Pages 上搭建了一个洪水公告，提供关于道路、救援、天气和电力的经过核实的信息。此后它发展成了 Gati，一个以尼泊尔语为先、运行在 GitHub Pages 和 Actions 上的官方灾害警报转发平台。在其他地方，NASA 喷气推进实验室（Jet Propulsion Laboratory）的开发者正在开发专为在航天器上运行程序而设计的软件，还有爱好者构建了开源固件，让人们可以自定义自己的电子阅读器。好奇心，指向四面八方，规模之大是 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 月前后激增，仿佛各地的开发者同时看到了新的可能。差不多就在那时，一系列全行业的变革接连落地：更好的底层模型、围绕这些模型构建的 harness 和工具，以及运行在两者之上的智能体。智能体从单会话工具转变为持久化工具，能够跨天跟踪进度并编排其他专门的智能体。同样重要的是，智能体开始大量使用云端，既能远程执行工作，也能在本地机器上执行。

这种势头既体现在全新的代码库中，也体现在已构建多年的开发者身上。从 6 月开始，所有提交中约有 55% 来自全新的代码库。但还有更多提交来自经验老到的开发者：过去 12 个月推送过代码的开发者平均已在 GitHub 上待了 36 个月，而在 8 月发起过拉取请求的人中，超过 75% 在 9 月也推送了代码。他们还在拓展自己的领域：如今普通开发者参与的代码库数量比一年前多出 10%。

这种持久力也体现在开源领域。2026 年公开贡献飙升至 25 亿次，是去年总量（11.2 亿次）的两倍多。这些数字背后是持续活跃的开发者，例如 @kinlane，他通过智能体工作流在自己的公开代码库中贡献超过 100 万次，以保持一个可机器读取的公共 API 信息目录时刻更新。另一个例子是 @kim-em，他在维护 mathlib——一个由计算机验证数学内容的社区库——期间贡献了超过 17.8 万次。@andig 是开源电动汽车充电控制器和家庭能源管理系统 evcc 的维护者，贡献超过 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 倍。

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

在 GitHub Copilot 的月活跃用户中，目前有 55% 使用智能体功能，高于一年前的 35%。增长最快的是最省心的模式。Copilot cloud agent——由开发者分配任务、智能体独立完成——同比增长 230%，而 agent chat 增长 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 和 Microsoft 员工的使用、后台工具模型、用于监控和测试的重复请求，以及使用开发者自带 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 万，是前 10 大语言中增幅最大的。Rust 在顶级语言中按百分比增长最快，过去一年翻了一番。

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

增长最快的语言也是 AI 参与最多的地方。我们绘制了过去一年每种语言的社区增长与其合并拉取请求中检测到 AI 参与的占比的对照图，气泡的大小大致表示每种语言社区的规模。TypeScript、Python 和 Rust 是增长最快的社区，占比也最高，约占合并拉取请求的 40% 到 44%。Java、C# 和 C++ 占比较低，介于约 21% 到 34% 之间，不过图中每种语言的合并拉取请求里，每五个就有一个以上出现 AI 的身影。

仓库数据提供了另一个视角。在 2026 年创建的仓库中，被观测到有智能体信号的仓库里有 35% 以 TypeScript 作为主要语言，而没有此类信号的仓库中这一比例为 24%。对于 2026 年之前创建的仓库，差距类似：有智能体信号的为 27%，没有的为 17%。这表明与智能体协作的开发者更倾向于选择智能体输出更易于检查的语言。清楚知道自己要什么的开发者仍然会指定语言。但当把选择权留给智能体时，智能体似乎更偏爱一组较窄的语言，其中 TypeScript 最为突出。

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

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

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

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

参与度最高的开源仓库 

什么没有改变

作为今年研究的一部分，我们还追踪了开发者在其仓库中使用最多的 emoji。在我们考察的每个行业中，火箭 🚀 都以巨大优势位居榜首。对于充满前进势头的一年来说，这是个贴切的象征。今年 GitHub 上的开发者覆盖了更广的领域：更多代码、更多国家，行业也比我们以往测量过的更多。这些活动都没有改变由谁来决定代码该做什么。仍然需要有人提出想法，无论是评估地震风险的软件、记录在线服务如何变更其条款和隐私政策的公开记录，还是让 AI 像原始人那样回答以节省字数的 agent 技能。也仍然需要有人来判断它是否有效、是否合宜，以及是否足够好。

真正改变的是：把一个念头从周末的随想变成实实在在的东西，如今要容易得多。

工具会不断变化，新的行业也会不断出现在我们意想不到的地方。开发者选择构建什么、为谁而构建，仍然由他们自己决定——连火箭 emoji 也不例外。

术语表

• Agent 配置文件：一种用于设置或指挥 AI 编码 agent 的仓库文件。也称为 AI 配置文件或 agentic 文件。没有此类文件的仓库也可能仍在使用 AI。
• Agent 信号：遥测数据中观察到的 agent 参与迹象，例如由 agent 打开的 pull request。这是一个下限，因为并非所有 agent 使用都能被检测到。
• Agent 发起的 pull request：初稿出自我们可检测到的编码 agent 的 pull request。
• 自动模型选择：GitHub Copilot 的一项设置，由 Copilot 为任务挑选模型。
• Commit：对仓库所做更改的一次已保存快照。
• 贡献（Contributions）：活动事件：对 commit、issue、pull request 或 discussion 发表评论；创建 gist、issue、pull request 或 discussion；推送代码；以及审查 pull request。每次推送只计一次，无论其中包含多少个 commit。开源贡献指对公开的开源仓库做出的贡献。
• 贡献者：在该时段内至少有一次贡献的 GitHub 用户。
• Copilot 云端 agent：GitHub Copilot 的一项功能，开发者指派任务，agent 独立完成。
• Dependabot：GitHub 的自动化工具，用于查找过时或有漏洞的依赖项，并打开 pull request 来更新它们。
• 开发者选择的请求：由开发者通过我们的代理选择模型的模型请求。不包括自动模型选择、员工使用、重复的监控和测试请求、后台实用模型，以及使用开发者自己的 API key 发出的请求。
• GitHub Actions job：GitHub Actions workflow 中的单个工作单元。
• 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 年预测值之间距离的比例。
• 编程语言。贡献者指每月通过推送、拉取请求、issue、评审或评论参与活动的独立账户，并归因于每个仓库的主要语言（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 代码之间的比值。随后使用这些比值对来自各国的推送进行加权。
• 行业。我们从每年随机抽样，通过一个经过微调的多语言嵌入模型，利用仓库名称、描述、主题和 README，将 2022 年至 2026 年创建的公开仓库归类到 NAICS 行业。AI 提及和 agent 发起的拉取请求（仅限可检测到的 agent）被标记为独立信号。行业占比与 AI 提及占比可能存在相关性，因为二者读取的是相同的文本。占比均为估计值。
• 开源排行榜。根据战略控制权的归属，仓库被划分为社区项目或单一厂商项目。“增长最快”按独立贡献账户的同比绝对增量排名。“最活跃”则综合考量仓库在 star、fork 以及独立拉取请求和 issue 创建者方面的排名。这两个榜单均排除了 fork 的仓库。
• 模型选择。数据涵盖 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 个时间序列和回归模型，以 2026 年 9 月为基准预测至 2031 年 9 月 GitHub 上的开发者数量。结果分为 3 倍及以上（21 个模型）、2 倍至不足 3 倍（19 个）和不足 2 倍（3 个）。Octoverse 2025 使用了五个模型。没有哪个预测是完全准确的。

文章 Octoverse：2026 年开发者使用智能体构建，提交与推送数量创历史新高 首发于 The GitHub Blog。