21CTO 导读：GitHub 向全球开发者们宣布，正在不停机重建其 Git 基础设施，以支撑开发者与智能体并发在仓库中工作的巨量负载。

背景与事实

GitHub 工程博客发布了文章，题目为《Building Git infrastructure for agent-scale development》，作者为 Brian Celenza。

GitHub关于架构重写的文章地址：

https://github.blog/news-insights/company-news/an-update-on-github-availability/

他表示，GitHub 正在其服务持续运行的前提下重建 Git 基础设施，目标是支撑“智能体规模化”的软件开发负载。文章称，随着开发者与智能体在同一批仓库中并发工作，现有 Git 架构面临新的压力，因此需要一套不同的架构设计。

数据和影响

该篇文章中给出的数据勾勒出这一变化的量级。

2025 年 9 月至 2026 年 8 月，GitHub 上的 Git 活动量从每月 2182 亿次事件暴增至 4733 亿次，超过此前水平的两倍。

仅 2026 年 9 月，开发者与智能体在 GitHub 上产生了 73.8 亿次提交，据称是一年前的五倍以上。而推送量同比增长 4.9 倍，从每月 6.9 亿次增至 33.5 亿次；拉取请求合并量增至一年前的近四倍；GitHub Actions 在 9 月运行了 32.6 亿次，同样超过一年前的四倍。文章还提到，GitHub 上最繁忙的仓库在 2026 年 8 月收到约十亿次请求。

据 GitHub 称，这主要是由于大型工程团队拥有繁忙的持续集成 (CI) 流水线以及越来越多的 AI 代理所致。

为什么人工智能代理会给系统带来如此大的压力？代理在一个紧密的循环中运行，几乎每次操作后都会提交或检出，这使得人眼难以察觉的延迟成为了瓶颈。此外，持续集成 (CI) 作业每分钟都会克隆或获取同一分支的顶部数千次。GitHub Actions 在 9 月份运行了 32.6 亿次，是去年同期的四倍多。

为此，GitHub 不断发生故障，但问题始终没有彻底解决。此次该团队开始彻底重建其 Git 基础设施。

副本减慢写入速度

当前系统 Spokes 默认将每个代码仓库存储在五台文件服务器的本地磁盘上。采用三阶段提交协议并设置法定人数，确保持续集成 (CI)、Web UI 和 API 客户端能够看到一致的状态。该架构目前服务于十亿个代码仓库。

但磁盘上的副本既是数据的来源，也是扩展的手段。每个副本都会参与每一次写入操作，因此推送速度取决于最慢的副本。

GitHub 对此总结道：“增加副本来分担读取负载会降低写入速度。” 如果失去法定人数，写入操作将完全停止。

存储和计算分离

GitHub的新架构将存储和计算两层分离。权威存储库数据存储在 Azure Blob 存储中，负责持久性和复制。轻量级计算工作节点缓存读取请求的数据，并可根据流量进行扩展。GitHub 表示称，如果某个工作节点发生故障，其影响与缓存未命中的效果相当。

协调工作也得到了最大程度的简化。只有引用更新仍需达成共识；对象存储、连接性检查和密钥扫描基本并行运行。压缩和垃圾回收被移至独立的工作进程，远离处理实时 Git 请求的主机。

因此，在内部基准测试中，新方案的写入吞吐量提升高达 35 倍。

GitHub向用户强调，分支保护、强制审查和审计日志等功能仍然有效。此次重组没有维护窗口，平台将继续正常运行。

作者：洛逸