GitHub 重建 Git 基础设施，应对智能体规模开发

每天在 GitHub 上，数百万开发者构建着客户所依赖的产品、为开源做贡献，并推进个人项目。多年来，GitHub 的架构不断演进，以支撑这些工作以及依赖它的开发者和组织日益增长的需求。

智能体软件开发正在推动下一次架构转变。开发者和智能体在每天接收数百万次提交的代码仓库中并发工作，这些工作负载需要一种不同的 Git 架构。我们正在重建 GitHub 的 Git 基础设施来支持它们。本文探讨塑造这项工作的需求及其背后的设计原则。

当今最高负载的工作负载展示了我们正在为之构建的规模。典型代码仓库与最繁忙仓库之间的差距比大多数人想象的要大得多。以下是 2026 年 8 月 GitHub 上每月仓库活动分布的大致情况：

仓库活动在分布的最远端急剧攀升。GitHub 上最繁忙的仓库在 8 月收到了约十亿次请求。

除了这些最高负载的工作负载之外，GitHub 上的 Git 总活动量也在快速增长：从 2025 年 9 月到 2026 年 8 月，它增长到此前水平的两倍多，从每月 2182 亿次事件增至 4733 亿次。

仅在 9 月，开发者和智能体就在 GitHub 上完成了 73.8 亿次提交，是一年前的五倍多。

这条曲线顶端的仓库展示了智能体开发在最前沿的样子：大型工程团队运行着繁忙的 CI 流水线，同时还有不断增长的智能体集群。支持这些团队意味着要构建能够支撑持续并发读写的 Git 基础设施，其规模是如今鲜有仓库能达到的。我们正在深入投资 Git 基础设施，以满足智能体软件开发的需求，并为团队提供一个为其最宏大工作负载而构建的基础。

为这一规模而构建意味着要解决若干架构挑战：

• 提交周转成为每个智能体的瓶颈。处于紧密循环中的智能体几乎在每次操作后都会提交或创建检查点。其速度受限于单次推送完成的速度，因此人类根本不会察觉的延迟反而成了限制因素。
• 写入吞吐需求正以数量级增长。推送量同比增长 4.9 倍，从每月 6.9 亿次增至 33.5 亿次。数千个智能体在同一仓库中各自的分支上工作，产生的持续写入速率汇聚到我们架构中的单一节点上。
• 合并争用同一个引用。主干开发、发布列车和合并队列将所有工作汇聚到单个 ref 上，它必须吸收每一次合并。GitHub 上的拉取请求合并量增长到一年前的近 4 倍。
• 每次推送都会放大为数千次读取。例如，CI 和代码扫描每分钟会克隆或获取同一分支顶端数千次，这种扇出必须足够廉价。仅 GitHub Actions 在 9 月就运行了 32.6 亿次，是一年前的 4 倍多。
• 仓库上的操作必须持续保持快速。为了保持快速，我们不断压缩仓库数据并清理不再需要的对象。每一次新的写入都会增加这项工作，而随着数据量攀升，成本会不断累积。

这就是为什么快速克隆只能解决部分问题。读取相对容易扩展：增加缓存、增加副本，就能把相同的字节提供给更多客户端。扩展读取至关重要，但这些工作负载需要的远不止这些。写入则要困难得多。每次推送都必须持久存储，并在下一个 agent 或 CI 任务基于它构建之前，以一致的方式使其可见。

当今架构如何应对新需求

当前架构多年来一直很好地服务于开发者。每个仓库都由 Spokes 存储，它会在多台文件服务器的本地磁盘上保留完整副本，默认是五台。这些快速的本地磁盘让 Git 操作能以低延迟读取原生仓库数据，而额外的副本则提供冗余，同时将读取分散到各文件服务器。当推送更新某个引用时，三阶段提交协议会使用法定人数来确保 CI、Web UI 和 API 客户端看到一致的仓库状态。这种组合如今支撑着十亿个仓库。

然而，我们用于持久性的机制，也正是我们用于扩展的机制。磁盘上的副本是事实来源，因此增加读取容量就意味着增加另一个持久副本。每个副本都参与每一次写入，所以一次推送的速度取决于其集合中最慢的副本。最终效果是：增加副本来吸收读取负载，反而会让写入变慢。

对大多数仓库来说，这种权衡效果不错。但在最高活跃度下，它就成了天花板：增加读取副本会给写入增加开销，丢失一个副本会降低读取容量，而失去法定人数则会完全停止写入。为了满足 agent 优先的需求，我们需要将持久性与扩展性分离，同时不丢失团队今天所依赖的能力。

为最繁忙者而建，让所有人受益

我们正在重建基础设施，同时 GitHub 仍在运行。没有让全世界的代码停止流动的维护窗口，也没有任何版本会要求人们在我们做这件事时改变他们构建软件的方式。

我们正在为 GitHub 上要求最高的工作负载而构建：一家在严格监管要求下交付的企业、一个在构建操作系统的仓库中落地变更的团队，以及一个针对单一代码库运行数千个 agent 的组织。为这种规模进行工程化，会提升所有人的下限。跨时区审查志愿者贡献的维护者，以及打开第一个 pull request 的学生，都会获得同样更快、更有韧性的基础。

新架构还必须保留团队已经在使用的控制措施。维护者需要分支保护和必需的审查，以确保未经审查的变更永远不会进入默认分支。安全团队需要审计日志和仓库可见性，以调查可疑的访问事件。值班工程师需要可靠的自动化，以及足够的可观测性，来理解部署为何失败。

为了让平台在扩展以应对最繁忙工作负载的同时，继续服务这里的每一个人，以下是我们的指导原则：

• 基于开发者已经信任的工作流来构建。团队依赖分支、审查、合并和历史等工作流，来大规模地构建、交付和治理软件。我们的新基础设施旨在以高得多的活动量支持这些相同的工作流。
• 可靠性优先。我们以开发者和组织所要求的可靠性来衡量每一项决策。对平台的信心，正是工程组织能够构建自动化、按计划交付、满足合规义务并理解其产出的软件的基础。这项工作将切实提升吞吐量和规模，而这些收益会进一步巩固业已存在的信任基础。
• 让代码始终处于人的掌控之中。如果系统不能帮助使用它的个人和组织，也不受他们控制，那就不值得构建。随着 agent 承担越来越多的工作，代码的所有者仍然可以审查、理解并批准它。

方法

我们正在构建一种全新的 GitHub 架构，能够以更高效的方式扩展。我们的方法以核心分布式系统设计原则为中心，并将其应用于 agent 驱动软件开发的并发与规模场景。我们的目标是延续全球开源社区和企业在 Git 与 GitHub 上构建项目的前进势头，同时保留并调整其周边的功能与控制机制，以满足 agent 时代的新需求。

最小化协调

一个接收大量 push 的仓库必须快速接受并发布更新。当协调能够保护正确性时，它是有价值的，但过多的协调会限制写入吞吐量，并可能让繁忙的仓库成为瓶颈。我们当前的架构在一些并不需要的地方存在紧密耦合，这限制了我们在读写两方面进行扩展的能力，除非做出艰难的取舍。我们正在重新设计系统，以保留 Git 语义所必需的协调，并让其他一切独立进行。

• 只协调真正需要达成一致的部分。一次 push 中真正需要达成一致的部分是引用更新本身。存储底层对象、验证对象连通性以及密钥扫描的工作量要大得多，但其中大部分可以与其他写入并行进行。这将 push 的关键路径缩短到需要协调的那一小步，因此其余工作不再延迟确认。
• 将维护移出服务路径。压缩和垃圾回收是仓库执行的最繁重工作之一，而如今它们运行在响应实时 Git 请求的同一批主机上。在新架构中，独立的工作进程直接针对持久化存储处理维护任务。繁忙的仓库可以在后台持续优化，而不会拖慢 push 和 fetch。

将存储与计算解耦

如今，本地磁盘上的完整仓库副本既充当持久化存储，又充当响应 Git 请求的层。将两者分离，使我们能够独立扩展每一层。

• 在不增加持久化副本的情况下扩展读取。在新架构中，读取能力来自轻量级工作进程，它们缓存数据以服务请求。仓库的权威副本位于底层的持久化存储层中。这样一来，平台就能吸收来自 CI 扇出、agent 集群和大型克隆的大量读取峰值，而无需为每次 push 增加额外工作。
• 让每一层各司其职。权威仓库数据存放在 Azure Blob Storage 中，它已在 Azure 规模上提供持久性和复制能力。计算层则针对最低延迟下的吞吐量进行优化。
• 更快地从故障中恢复。当存储和计算耦合在一起时，丢失一台主机就会同时降低容量和持久性，恢复意味着要重建整个仓库副本。当两者分离时，丢失一台计算工作节点更接近于一次缓存未命中：替换的工作节点可以立即开始处理请求，并随着流量到来从持久存储中填充其缓存。
• 让容量与需求匹配。计算工作节点可以随着流量变化而增减，而不必提前为峰值负载进行预置。当某个仓库经历活动激增时，比如一次发布或一批新的 agent 集群上线，它可以为这次激增获得额外容量。一旦激增过去，这些容量就会被释放。

这些原则共同使我们能够支持更高的吞吐量和更多的并发工作，同时不放弃用户所需的可靠性和控制能力。

接下来是什么

我们正在构建一种旨在提供最高吞吐量和可靠性的架构。读取和写入独立扩展，系统能够优雅地从故障中恢复。在内部基准测试中，它实现了高达 35 倍的写入吞吐量提升，读取容量也能自行扩展以满足需求。

随着自动化开发提高了软件变更的频率和并发度，GitHub 将在不牺牲团队所依赖的治理和控制的前提下，演进其基础设施。我们已经在将这一基础落实到位。在本系列的下一篇文章中，我们将更深入地探讨我们未来的架构以及引领我们走到这一步的历程。

文章 Building Git infrastructure for agent-scale development 首次发表于 The GitHub Blog。