为智能体规模的开发构建 Git 基础设施
每天，数百万开发者都在 GitHub 上构建客户依赖的产品、为开源项目做贡献、推进个人项目。多年来，GitHub 的架构一直在稳步演进，以支撑这些工作，也满足依赖它的开发者和组织不断增长的需求。如今，智能体式软件开发（由 AI 智能体参与编码）正在推动下一轮架构转变。开发者和智能体并发地在仓库中工作，而这些仓库每天要接收数百万次提交——这类负载需要一套不一样的 Git 架构。我们正在重建 GitHub 的 Git 基础设施来支撑它们。本文将探讨塑造这项工作的需求，以及背后的设计原则。
当下流量最高的一批负载，体现了我们要支撑的规模。普通仓库与最繁忙仓库之间的差距，比大多数人想象的要大得多。下面是 2026 年 8 月 GitHub 仓库月度活跃度分布的大致情况：
活跃度在分布曲线的最末端急剧攀升。8 月，GitHub 上最繁忙的单个仓库大约收到了 10 亿次请求。
除了这些最高流量的负载，GitHub 上 Git 活动的总量也在快速增长：2025 年 9 月到 2026 年 8 月，月事件量翻了一倍多，从 2182 亿次增至 4733 亿次。仅 9 月一个月，开发者和智能体就在 GitHub 上完成了 73.8 亿次提交，是一年前的 5 倍多。
曲线顶端的仓库，展示了智能体开发处在最前沿时是什么样子：大型工程团队运行着繁忙的 CI 流水线，身边还有规模不断扩大的智能体集群。要支撑这些团队，就得构建能承受持续、并发读写的 Git 基础设施，而这样的规模如今很少有仓库能达到。我们正深度投入 Git 基础设施建设，以满足智能体软件开发的需求，为团队打下能承载其最庞大工作负载的基础。
要为这种规模而构建，需要解决几个架构层面的挑战：
- 每个 agent 的提交周转都会成为瓶颈。 处于紧密循环中的 agent 几乎每个动作后都会提交或设置检查点。它的速度受限于单次推送完成的速度，因此人类根本不会注意到的延迟反而成了限制因素。
- 写入吞吐需求正以数量级增长。 推送量同比增长 4.9 倍，从每月 6.9 亿次增至 33.5 亿次。数千个 agent 在同一仓库中各自处理自己的分支，会产生持续写入速率，并在我们架构的某个单点上汇聚。
- 合并会争用同一个引用。 主干开发、发布列车和合并队列会把所有这些工作汇聚到一个引用上，而这个引用必须承接每一次合并。GitHub 上的拉取请求合并量已增长到去年同期的近 4 倍。
- 每次推送都会放大成数千次读取。 例如，CI 和代码扫描每分钟会克隆或获取同一分支尖端数千次，这种扇出必须足够便宜。仅 GitHub Actions 在 9 月就运行了 32.6 亿次，是去年同期的 4 倍多。
- 仓库操作必须持续保持快速。 为了保持快速，我们会不断压缩仓库数据，并清理不再需要的对象。每一次新写入都会增加这项工作，而且随着体量攀升，成本会不断累积。
这就是为什么快速克隆只能解决部分问题。读取相对容易扩展：增加缓存、增加副本，并把相同字节提供给更多客户端。扩展读取至关重要，但这些工作负载需要的远不止这些。写入要难得多。每次推送都必须持久存储，并在下一个 agent 或 CI 作业能够基于它构建之前，以一致的方式变为可见。
当现有架构遇上新需求
现有架构多年来一直很好地服务着开发者。每个仓库都由 Spokes 存储，它会在多台文件服务器的本地磁盘上保留完整副本，默认是五台。这些本地磁盘速度快，让 Git 操作能以低延迟读取原生仓库数据；额外副本既提供冗余，也能把读取负载分散到不同文件服务器。当一次推送更新某个引用时，三阶段提交协议会通过多数派确认，确保 CI、Web UI 和 API 客户端看到一致的仓库状态。这套组合目前支撑着十亿个仓库。
不过，我们用来保证持久性的机制，也是用来实现扩展的机制。磁盘上的副本就是唯一可信来源，所以增加读取容量，就等于增加一个持久化副本。每个副本都要参与每一次写入，因此一次推送的速度取决于其所在集合中最慢的那个副本。最终结果就是：为了吸收读取负载而增加副本，反而让写入变慢。
对大多数仓库来说，这个取舍运作良好。但到了最高活跃度级别，它就成了一道天花板：增加只读副本会给写入增加开销，丢失一个副本会减少读取容量，而失去多数派则会让写入完全停止。为了满足智能体优先（agent-first）的需求，我们需要把持久性和扩展性拆开，同时不丢掉团队目前依赖的能力。
为最繁忙的场景而建，让所有人受益
我们在重建基础设施的同时，GitHub 仍在持续运行。没有让全世界的代码停下来的维护窗口，也不会要求大家在我们施工期间改变构建软件的方式。我们要应对的是 GitHub 上最苛刻的工作负载：一家在严格监管要求下交付软件的企业，一个要在构建操作系统的仓库里合入变更的团队，以及一个针对单一代码库运行数千个智能体的组织。
为这种规模做工程，会抬高所有人的底线。跨时区审阅志愿者贡献的维护者，和第一次打开拉取请求的学生，都能得到同样更快、更强韧的基础。
新架构还必须保留团队已经在用的各项管控措施。维护者需要分支保护和强制评审，确保未经评审的改动不会进入默认分支。安全团队需要审计日志和仓库可见性，以便排查可疑的访问事件。值班工程师需要可靠的自动化，以及足够的可观测性，来弄清一次部署为何失败。
平台要想在承载最繁重负载的同时继续服务好所有人，下面这几条是我们要遵循的原则：
- 建立在开发者已经信任的工作流之上。 团队依赖分支、评审、合并、历史记录等工作流，来大规模地构建、发布和治理软件。我们的新基础设施，就是为了在活动量高得多的情况下，依然支持这些同样的工作流。
- 把可靠性放在第一位。 我们做每一个决定，都以开发者和组织所要求的可靠性为衡量标准。只有对平台有信心，工程组织才能搭建自动化、按计划发布、满足合规要求，并弄清自己产出的软件到底长什么样。
这项工作将实实在在地提升吞吐量和规模，而团队今天依赖的工作流会照常运行，和现在一模一样——不需要迁移，不需要维护窗口，也不需要 GitHub 上的开发者和组织做任何改动。
这些提升，是在一份本就存在的信任基础上继续加码。让人掌控自己的代码。如果系统帮不上使用它的人和组织的忙，又不在他们的掌控之中，那就不值得去建。随着智能体承担越来越多的工作，代码的所有者依然能够评审、理解并批准这些代码。
实现思路
我们正在构建一套全新的 GitHub 架构，让它能更高效地扩展。思路的核心是把分布式系统的经典设计原则，应用到智能体软件开发的并发与规模场景中。目标是延续全球开源社区和企业已经用 Git 和 GitHub 建立起来的势头，同时保留并调整相关功能与控制机制，满足智能体时代的新需求。
尽量减少协调
一个频繁接收推送的仓库，必须能快速接受并发布更新。协调机制在保障正确性时是有价值的，但过度协调会限制写入吞吐量，让繁忙的仓库变成瓶颈。我们当前的架构在一些本不需要紧密耦合的地方耦合过紧，导致读写扩展时不得不做艰难的取舍。我们正在重新设计系统，只保留 Git 语义真正需要的协调，其余部分独立推进。
只对必须达成一致的部分做协调。
一次推送中真正需要达成一致的，只有引用更新本身。存储底层对象、校验对象连通性、密钥扫描这些工作量大得多，但大部分可以和其他写入并行进行。这样一来，推送的关键路径就缩短到只需要协调的那一小步，其余工作不再拖慢确认返回。
把维护工作移出服务路径。
压缩和垃圾回收是仓库最繁重的操作之一，目前它们和实时 Git 请求跑在同一批主机上。新架构里，由独立的工作进程直接对持久化存储执行维护。繁忙的仓库可以在后台持续优化，而不拖慢推送和拉取。
存储与计算解耦
现在，本地磁盘上的完整仓库副本既充当持久化存储，又充当响应 Git 请求的层。把两者分开，就能各自独立扩展。
扩展读能力，不必增加持久化副本。
在新架构中，读能力由轻量工作节点提供，它们通过缓存数据来响应请求。仓库的权威副本存放在底层的持久化存储中。这样一来，平台就能扛住 CI 任务分发、智能体集群和大规模克隆带来的读请求高峰，而不会给每次推送增加额外负担。
让每一层只做一件事。
权威仓库数据存放在 Azure Blob Storage，它本身就能在 Azure 规模下提供持久性和复制能力。计算层则专注于低延迟和高吞吐。
更快从故障中恢复。
存储和计算耦合时，一台主机故障会同时损失容量和持久性，恢复时还得重建完整的仓库副本。两者分离后，计算节点故障更像一次缓存未命中：替补节点可以立刻开始处理请求，并在流量到来时从持久化存储填充缓存。
按需匹配容量。
计算节点可以随流量变化增减，不必提前按峰值负载预留资源。仓库遇到活动高峰时——比如发布，或者一批新智能体上线——可以临时获得额外容量。高峰过去，这部分容量就会被释放。
这些原则结合起来，让我们能够支撑更高吞吐和更多并发任务，同时不牺牲用户需要的可靠性和管控能力。
接下来
我们正在构建一套架构，目标是提供尽可能高的吞吐量和可靠性。读和写可以独立扩展，系统也能在故障后平稳恢复。在内部基准测试中，它的写入吞吐量最高提升了 35 倍，读容量则能按需自动扩展。