构建支撑智能体规模开发的 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 基础设施建设，以满足智能体软件开发的需求，为团队提供支撑其最宏大工作负载的基础。

为应对这种规模，需解决若干架构挑战：

• 每次提交的响应时间成为每个智能体的瓶颈。 处于紧密循环中的智能体在几乎每个动作后都会提交或保存检查点。其速度受限于单次 push 完成的快慢，因此人类不易察觉的延迟，反而成了制约因素。
• 写吞吐量需求正在成倍增长。 推送量同比增长了4.9倍，从每月6.9亿次激增至33.5亿次。成千上万个Agent在同一仓库的不同分支上并行工作，产生持续的高写入速率，这些负载最终都汇聚到我们架构的同一个节点上。
• 合并操作在同一引用上发生竞争。 主干开发、发布列车和合并队列将所有工作汇聚到一个必须承受所有合并请求的单一点上。GitHub上的Pull Request合并量已增长至一年前水平的近4倍。
• 每次推送都会衍生出成千上万次读取。 例如，CI和代码扫描每分钟都会克隆或拉取同一分支头数千次，这种扇出效应必须低成本运行。仅GitHub Actions在9月就运行了32.6亿次，比一年前增长了4倍以上。
• 仓库操作必须保持快速。 为了维持速度，我们需要持续压缩仓库数据并清理不再需要的对象。每次新的写入都会增加这一工作负载，随着数据量攀升，成本会复合式增长。

这就是为什么快速克隆只能解决部分问题。读取相对容易扩展：添加缓存、增加副本并向更多客户端提供相同的数据即可。扩展读取能力至关重要，但这些工作负载需要更多的手段。写入要难得多。每次推送都必须持久化存储，并在下一个Agent或CI作业基于其构建之前，确保状态一致可见。

现有架构如何应对新需求

目前的架构多年来为开发者提供了良好服务。每个仓库都由 Spokes 存储，Spokes 在多台文件服务器（默认5台）的本地磁盘上保留完整副本。这些快速的本地磁盘使 Git 操作能以低延迟读取原生仓库数据，额外的副本提供冗余性，并将读取请求分散到各文件服务器上。当推送更新引用时，三阶段提交协议利用法定人数机制确保 CI、Web UI 和 API 客户端看到一致的仓库状态。这套组合目前服务于数十亿个仓库。

不过，保障数据持久性的机制和支撑规模的机制是同一套。磁盘上的副本就是事实来源，因此增加读取能力就意味着再添加一个持久化副本。每个副本都参与每次写入，所以 push 的速度取决于副本集中最慢的那个。结果就是：为了消化读取流量而增加副本，反而会让写入变慢。 对大多数仓库来说，这种权衡是可以接受的。但在最高的活跃度下，它就成了天花板：增加读副本会给写入带来额外开销，丢失一个副本会降低读取能力，而丢失 quorum 则会让写入完全停止。要满足 agent-first 的需求，我们必须把持久性和规模解耦，同时不牺牲团队如今所依赖的一切。

为最繁忙的场景而建，让所有人受益

我们是在 GitHub 正常运行的前提下重建基础设施。世界上没有任何一个维护窗口能让全球的代码停止流动，我们也不会要求任何人改变构建软件的方式来配合这次改造。 我们为 GitHub 上最严苛的工作负载而构建：在严格监管要求下持续交付的企业、在一个能构建完整操作系统的仓库里合并变更的团队，以及对同一个代码库运行数千个 agent 的组织。为这种规模做工程设计，会把所有人的底线都抬高一截。无论是跨时区审阅志愿者贡献的维护者，还是首次发起 pull request 的学生，都将获得同样更快、更有韧性的基础。 新架构还必须保留团队已经在使用的管控机制。维护者需要分支保护和必需的代码审查，确保未经审查的变更不会进入默认分支。安全团队需要审计日志和仓库可见性来排查可疑的访问事件。值班工程师需要可靠的自动化和足够的可观测性来弄清部署失败的原因。 要让平台在为最繁忙的工作负载扩展的同时继续服务这里的每一个人，以下是我们的指导原则：

• 建立在开发者已经信任的工作流之上。团队依赖 branching、review、merge、history 等工作流来大规模地构建、发布和治理软件。我们的新基础设施旨在以更高的活跃量支撑这些同样的工作流。
* 将可靠性放在首位。我们用开发者和组织对可靠性的要求来衡量每一个决策。只有对平台充满信心，工程团队才能构建自动化流程、按期交付、满足合规要求，并真正理解其所产出的软件。这项工作将显著提升吞吐量并扩大规模，这些收益将进一步夯实已有的信任基础。 * 让人类掌控代码。如果系统不能服务于使用者及其所在组织，且不受他们控制，那就不值得构建。随着 Agent 承担更多工作，代码所有者依然可以审查、理解并批准代码变更。

技术路径

我们正在构建一种可扩展性更强的全新 GitHub 架构。我们的方案基于核心分布式系统设计原则，并将其应用于 Agent 软件开发的高并发和大规模场景。我们的目标是在保留和适配围绕 Git 和 GitHub 构建项目的开源社区及企业所依赖的功能与控制手段的同时，推动全球范围内基于 Git 和 GitHub 的项目继续向前发展，以满足 Agent 时代的新需求。

最小化协调开销

接收大量 Push 操作的仓库必须快速接受并发布更新。当协调用于保护正确性时，它是宝贵的；但过度的协调会限制写吞吐量，使繁忙的仓库成为瓶颈。我们当前的架构在某些本不需要紧密耦合的地方却耦合过紧，这限制了我们在读写扩展能力上的提升，并迫使我们在性能与复杂性之间做出艰难取舍。我们正在重新设计系统，以保留 Git 语义所必需的协调机制，同时让其他部分独立运行。

• 仅对需要达成共识的部分进行协调。Push 操作中真正需要同步共识的环节仅仅是引用（reference）更新。存储底层对象、验证对象连通性以及执行秘密扫描虽然工作量更大，但其中大部分工作可以与其他写操作并行执行。这将 Push 的关键路径缩短至仅需协调的那个小步骤，从而避免其余工作延迟确认响应。
• 将维护任务移出服务路径。 压缩和垃圾回收是仓库中最繁重的操作之一，目前它们在与处理实时 Git 请求相同的托管主机上运行。在新架构中，独立的 worker 直接针对持久化存储执行维护任务。繁忙的仓库可以持续在后台优化，而不拖慢 push 和 fetch 操作。

存储与计算解耦

当前，本地磁盘上的完整仓库副本既充当持久化存储，又作为响应 Git 请求的层。将两者分离，可以独立扩展各自的能力。

• 增加读取容量而无需添加持久化副本。 新架构中，读取容量来自轻量级 worker，它们通过缓存数据来服务请求。仓库的权威副本保存在底层的持久化存储中。这样，平台可以吸收来自 CI 扇出、agent 集群和大克隆带来的巨大读取峰值，而无需在每个 push 中增加负担。
• 让每一层专注于单一职责。 权威仓库数据存储在 Azure Blob Storage，该服务已提供 Azure 规模的持久化和复制能力。计算层则针对吞吐量进行优化，力求最低延迟。
• 加速故障恢复。 当存储和计算耦合时，失去一台主机会同时降低容量和持久性，恢复意味着重建完整的仓库副本。当两者分离时，失去一个计算 worker 类似于缓存未命中：备用 worker 可以立即开始服务请求，并在流量到达时从持久化存储填充其缓存。
• 让容量匹配需求。 计算 worker 可以根据流量变化动态增减，而无需预先为峰值负载配置资源。正在经历活动爆发（如发布或新 agent 集群上线）的仓库可以获得额外容量。一旦峰值过去，这些容量就会消失。

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

接下来是什么

我们正在打造一套架构，旨在提供业界最高的吞吐量和可靠性。读写独立扩展，系统在故障后也能平稳恢复。在内部基准测试中，写入吞吐量最高提升了 35 倍，读取容量则可按需自主扩展。

随着自动化开发提高软件变更的频率和并发程度，GitHub 将持续演进其底层架构，同时不牺牲团队所依赖的治理与管控能力。这一基础工作已经启动。在本系列的下篇文章中，我们会深入探讨未来的架构设计，以及我们一路走来的探索历程。