10 月 21 日，GitHub 官方工程博客发了一篇题为「通向 agent 规模 Git 基建的桥」的文章，讲它过去一年怎么把存储架构往 Azure 上搬、又怎么为 AI Agent 的重度读写重新设计 Git 的一致性模型。这事的背景是：AI Agent 正在以指数级速度读写仓库，GitHub 自有数据中心的电力和物理空间都有硬上限，扩建跟不上增长。
先给结论：这是基础设施层的改造，短期对开发者几乎无感，但它决定了 GitHub 能不能在 Agent 时代继续稳定地接住流量——所以值得每个重度依赖 GitHub 的人知道它在改什么。
把仓库搬到 Azure
迁移分两步走，先搬数据，再演进架构，因为「在增长的同时既改存储架构又换托管平台，风险太大」。2025 年 8 月，第一个仓库副本落地 Azure Central US；到文章发布时，大多数仓库的 5 个副本里已有 2 个在 Azure，Azure 承载了约 50% 的 Git 流量。这 5 个副本用来平衡持久性、可用性和扩展性，靠一个叫 Spokes 的系统做偏好路由，把请求导向同区域、同可用区的副本。
剩下 0.00001% 卡在哪
已经搬了 99.99999%，剩下的 0.00001% 是平台上最繁忙的仓库，卡在一个 25ms 的跨区域往返延迟上。旧架构里，Spokes 的 quorum 只要多数派就能提交写入，但会等所有健康副本响应；最慢的那个健康副本，决定了每次写入的延迟。而每次写入还持有仓库级锁，于是最慢副本同时决定了吞吐上限。从数据中心到 Azure Central US 约 1000 英里，一次写入要多次往返，接近吞吐上限的仓库根本扛不住这个延迟叠加。
per-reference quorums
突破点是把 quorum 的作用范围从「整个仓库」缩小到「单个引用」。Git 的一致性要求本来就是对每个引用单独成立的：服务器接受某引用的更新后，任何客户端不应再看到更旧的值，无论 fast-forward、force push 还是 delete。但不同引用的更新通常互不依赖，可以独立应用。旧模型用仓库级锁把 quorum 退化成了单一无序队列；新模型下，只有竞争同一引用的写入才需要互相等待，Agent 和开发者推到各自分支的写入可以并行。官方内部测试显示，不同引用的写入吞吐稳定提升 3 到 4 倍，延迟反而更低。
对象存储与虚拟副本
第二原则是存储与计算解耦。多数仓库读远多于写——每 1 次写入对应 100 到 1000 次读取，可旧架构里读写共用同一批副本，争抢资源，没法独立扩展。于是引入虚拟副本（virtual replica）：一种完全无状态的计算节点，作为通往 Azure Blob Storage 的桥，把写入流式写进对象存储，不服务任何读；写入只有在对象存储持久化后才被确认。有了它，还能按需横向扩出任意数量的虚拟读副本，读副本从 Blob Storage 预热缓存、不进 quorum、以对象存储为准在后台对账。官方压测里，旧架构经常触顶，而虚拟读副本面前，压测工具先撞到了自己的极限。
关键数字
| 事项 | 数值 |
|---|---|
| 已迁移仓库比例 | 99.99999% |
| 每仓库副本数 | 5 |
| Azure 承载流量 | 约 50% |
| 首副本落地 | 2025 年 8 月 |
| 跨区域距离 / 单次往返 | 约 1000 英里 / 25ms |
| 读写比 | 100–1000 : 1 |
| 写入吞吐提升 | 3–4x |
| Spokes 日均操作 | 超 1000 亿次 |
对开发者意味着什么
短期：无感，仓库还是那些仓库，只是背后跑在 Azure 和新的 quorum 上。中期：如果 Agent 型工具大量读写仓库，你能更快地拿到响应，因为按引用并行的写入消除了仓库级瓶颈。长期：GitHub 正在为「Agent 和人类共用同一套 Git」重做地基，下周的 GitHub Universe 大会会揭示终态架构，到时关于写入吞吐的最终突破和保留的小规模 consensus group 会有答案。对把 GitHub 当生产依赖的人来说，这一系列博客值得跟着读。