字节笔记本
2026年11月7日 · 约 4 分钟读完
一个仓库多出一支 agent 大军：GitHub 重写 Git 存储
GitHub 官方工程博客 11 月 5 日发了长文《Inside GitHub's new Git storage architecture》（作者 Karthik Raman 与 Brian Celenza，16 分钟长文），首次完整披露 "Project Rubicon"——为 agent 规模化重写的 Git 存储架构。这个项目上周刚在 GitHub Universe 上宣布过，设计启动于 2026 年 5 月、Azure 迁移完成之后。
驱动它的问题很具体：一个仓库突然多出一支 agent 大军。官方口径的内部测试数据（未经独立复现）：同一仓库可支持 5,000 个并发 agent 工作、每秒 7,200 次 push，同时读流量保持低延迟。
两条设计原则
Rubicon 的整个架构从两条原则推出来：
- 最小化协调（minimize coordination）——锁的粒度越细、参与共识的东西越少，并发就越高；
- 存储与计算解耦（decouple storage from compute）——算力节点变成可以随时丢弃重建的东西。
四件套架构（博文原文）
- Spokes 仍在最上层，负责路由与负载均衡；
- 其下是虚拟副本（virtual replicas）：可以任意丢弃、重建的 Git 服务副本，本地磁盘只是缓存，不是真相源；
- Git 对象以 pack 形式存进 Azure Blob Storage；
- 引用（references）与 pack 清单（pack manifest）存在独立的复制日志服务 Ref-CAS——按 quorum 提交、每次只锁触及的引用，引用状态操作可达每秒数万次；
- 压实（compaction）节点在后台独立跑，直接操作 Blob Storage 与 Ref-CAS，不占用虚拟副本的 CPU 与内存。
值得一提的是演进过程：这个系列前两篇已经讲过原则与过渡（99.99999% 的仓库迁入 Azure、写 quorum 缩到单个引用、虚拟副本由 Blob 支撑）；而 Ref-CAS 是原型教训逼出来的——单 blob 写前日志每秒只有数百次写，按引用分段存储又让读变慢，团队最终自研了这套引用服务。Ref-CAS 这个组件此前已单独写过，本篇是整个 Rubicon 架构四件套的首次完整拼图。
现状与下一步
Rubicon 目前在有限内测（limited private preview）中，更广泛的推广在明年初。官方给的下一步是三件事：继续扩规模、让 agent 在 GitHub 上更高效、为 agentic 开发演进 Git 本身。对普通用户的底线也交代了：Git 保持 Git——push、fetch、branch 的用法不变，变的是底下的存储引擎。
判断
对维护大仓库、跑 agent 军团和 CI 的团队，这篇的信号是：并发瓶颈正在从"工作流层"沉到"存储层"，GitHub 选择把引用状态从文件系统语义里拆出来做成日志服务——这条路走通的话，"一个仓库上千个 agent 同时干活"就从工程奇迹变成常规配置。但记住口径：7,200 pushes/秒、5,000 并发 agent 都是 GitHub 自家内部测试，等有限内测的数据出来再当生产结论。
