GitHub 首席软件工程师 Brian Celenza 10 月 6 日在官方工程博客发文，披露公司正在重建 Git 存储层。原因写得很直白：AI 代理把写入流量推到了原有架构的上限。新架构在内部基准测试中，写入吞吐最高提升 35 倍。
文章给了一组过去一年的增长数字：
| 指标 | 最新数据 | 同比 |
|---|---|---|
| 每月 Git 事件 | 4733 亿次（2026 年 8 月） | 约 2.2 倍 |
| 每月推送 | 33.5 亿次 | 4.9 倍 |
| 每月提交 | 73.8 亿次（2026 年 9 月） | 5 倍多 |
| 每月 Actions 运行 | 32.6 亿次（2026 年 9 月） | 4 倍多 |
| PR 合并 | 未给绝对值 | 近 4 倍 |
最繁忙的单个仓库，8 月一个月收到约 10 亿次请求。文中对代理写入习惯的描述是：
“An agent in a tight loop commits or checkpoints after nearly every action” （循环运行的代理几乎每做一步就提交或打一次检查点。）
旧架构卡在写入上
GitHub 现有的仓库存储系统叫 Spokes。每个仓库默认在多台文件服务器的本地磁盘上各存一份完整副本，共 5 份。一次推送更新引用时，系统用基于多数派的三阶段提交协议，保证 CI、网页和 API 客户端看到一致的仓库状态。
这套设计里，副本同时负责两件事：防丢数据，以及分摊读请求。代价是每份副本都要参与每一次写入，加副本能扛更多读，写入反而变慢。人类开发者主导的年代，读远多于写，这个取舍没什么问题；代理把写入频率拉上来以后，副本数成了写入的瓶颈。
新架构拆成三块
第一块是把协调压到最少：只有引用更新需要各方达成一致，对象存储、校验、安全扫描都改成并行处理。
第二块是存储和计算分开。持久化交给 Azure Blob Storage，读请求由一批轻量工作进程处理。文章的说法是：
“Separating the two lets us scale each one independently” （把两者分开，就能各自独立扩容。）
第三块是后台维护独立出来，压缩和垃圾回收由单独的工作进程跑，不再和实时请求抢资源。分支保护、强制审查、审计日志和可观测性这些控制机制都保留。
粗算一笔写入账
按 30 天一个月粗算，73.8 亿次提交摊下来是每秒约 2850 次；33.5 亿次推送是每秒约 1290 次，一年前约 270 次。如果每次推送都要 5 份副本参与，旧架构每秒要处理的副本写入在 6500 次上下（估算，没算重试和维护任务）。
35 倍的吞吐提升对应的是 4.9 倍的推送年增速，账面上留出了几年的余量。前提是代理流量的增长曲线不再陡下去，而这件事 GitHub 自己也给不出预测。
文章没交代的部分
新架构已经迁移了多少仓库、什么时候全量切换，文章没有给时间表；35 倍的基准用的是什么规模的仓库、多大并发，也没有说明。对用户可能有哪些影响，比如速率限制会不会调整，文中同样没有提。
今年 GitHub 出过几次较长时间的服务中断，这篇文章没有回应这些事故，也没说新架构能否避免类似情况。Celenza 在结尾预告，系列下一篇会细讲未来架构和这次改造的来龙去脉。
参考来源：GitHub 工程博客、CocoLoop；GitHub 官方数据核验月度提交、推送与 Actions 运行量的统计口径。