GitHub 公布新 Git 存储架构 Rubicon：单仓实测 5,000 智能体并发，每秒 7,200 次推送
GitHub 11 月 5 日公布新 Git 存储架构 Rubicon：单仓实测 5,000 智能体并发、每秒 7,200 次推送，已开启内测，明年初扩大开放。
GitHub 在 2026 年 11 月 5 日的工程博文《Inside GitHub’s new Git storage architecture》中公布了新 Git 存储架构 Rubicon，一套为「智能体规模」开发重造的存储层。官方压测给出的数字是：单个仓库同时承载 5,000 个智能体并发协作，每秒承受 7,200 次代码推送。Rubicon 没有替换 git——Git 对象搬进 Azure Blob Storage，引用更新收进一个小型共识组 Ref-CAS，读写从此各自独立扩展。目前 Rubicon 处于 limited private preview，官方计划明年初扩大开放范围。
要点
- Rubicon 是 GitHub 于 2026-11-05 公布的新 Git 存储架构，项目 2026 年 5 月启动，取名自「渡过卢比孔河」，官方称这是对智能体开发「不归点」的致意；目前已开启 limited private preview。
- 内部压力测试中，单个仓库跑出 5,000 个并发智能体、每秒 7,200 次推送；而当前平台最繁忙仓库的真实写入峰值只有每秒几十次，且是短时突发。
- 核心机制：Git 对象存 Azure Blob Storage，只有引用更新走 Ref-CAS 共识组（官方称每秒可处理数万次引用事务）；读取由可随时丢弃重建的虚拟副本池按需扩展，compaction 移出服务路径。
背景
Rubicon 要接的不是新需求，而是已经翻倍的平台流量。GitHub 在 2026-10-06 的系列博文中给出过口径：全平台月 Git 事件从 2,182 亿涨到 4,733 亿，月推送从 6.9 亿涨到 33.5 亿次（约 4.9 倍），8 月最繁忙的单个仓库吃下约 10 亿次请求；一个典型仓库 3 月到 5 月的日请求量涨了约 4 倍，此后仍是指数曲线。官方判断，未来一年内，现在的瞬时突发会变成常态化的持续高吞吐负载。
压力的来源是开发方式的改变。智能体每完成一步就 checkpoint、就 push，push 延迟直接封顶单个智能体的速度；每次推送又会级联触发大量读取——CI 流水线、部署系统、其他智能体都要拉同一分支尖端，官方把这种放大效应称为 Read Fan-out。GitHub Octoverse 2026 的统计是另一面镜子：9 月超过 40% 的 PR 由智能体起草初稿。
行业里这不只有一种解法。本站此前报道过 Anthropic 弃 git 换自研 Scion，也覆盖过 OpenAI 收购 Pierre、把 Code Storage 团队并入 Codex；The New Stack 还记录了 OpenAI 用 Rust 写的 git 后端 Pando 与 Zed 的 Delta。Scion 走「另起炉灶」路线，Pando、Delta 与 Rubicon 同属「基于 git 改造」阵营。
Rubicon 如何工作
Rubicon 的存储层由三个部件组成。对象与读取加速数据存 Azure Blob Storage，对象不可变、按内容寻址；引用（分支、标签）与 pack manifest 存进 Ref-CAS（Reference Compare-and-Swap）——一个只存指针、从不持有对象数据的小型共识组；原有 Spokes 系统继续负责路由与负载均衡。
写入路径分两步：虚拟副本先把 pack 索引并上传到 Blob Storage，再向 Ref-CAS 提交一个事务。事务只锁它触到的那几个引用，按 quorum 完成比较交换，不同引用的写入因此可以并行；每个提交带一个 LSN，仓库版本就是最新提交的 LSN，版本一致时读侧只花一次比较就能确认无需同步。官方称 Ref-CAS 可做到每秒数万次引用事务，而第一版 Blob Storage 方案只有每秒几百次的水平。
读取的扩展与写入解耦：请求被路由到同一仓库的一组虚拟副本，本地磁盘只是随时可重建的缓存，副本按 Ref-CAS 版本检查决定要不要拉新 pack；compaction 由独立后台节点按 lease 认领 shard、按大小分层合并，不再挤占服务流量的副本。这套设计有演进脉络可查：2026-10-21 的博文交代过 Azure 迁移已覆盖 99.99999% 的仓库（每仓约 5 个副本、其中 2 个在 Azure），按引用拆共识后不同引用的写入吞吐提升 3–4 倍；更早的内部基准给过最高 35 倍写入吞吐。
事实部分
Rubicon 的官方数字集中在下面这张表里（均为 GitHub 自家压测或平台统计，截至 2026-11-05）：
| 指标 | 数字 | 来源与日期 |
|---|---|---|
| 单仓并发智能体（内测压测） | 5,000 | 官方博文 2026-11-05 |
| 单仓每秒推送（内测压测） | 7,200 次 | 官方博文 2026-11-05 |
| 当前最繁忙仓库写入峰值 | 每秒几十次，短时突发 | 官方博文 2026-11-05 |
| 平台月推送 | 6.9 亿 → 33.5 亿次 | 系列博文 2026-10-06 |
| 平台月 Git 事件 | 2,182 亿 → 4,733 亿次 | 系列博文 2026-10-06 |
| 最繁忙仓库单月请求 | 约 10 亿次（2026-08） | 系列博文 2026-10-06 |
| Ref-CAS 引用事务吞吐 | 每秒数万次 | 官方博文 2026-11-05 |
| 上线状态 | limited private preview | 官方博文 2026-11-05 |
三点口径需要说明。其一，5,000 智能体与 7,200 次推送出自 GitHub 自己的压测环境，不是第三方实测，也与当前真实流量相差约两个数量级——最繁忙仓库的真实峰值只有每秒几十次写入。其二，项目 2026 年 5 月才启动，第一版 Blob Storage 方案吞吐只有「每秒几百次的中间水平」，团队推倒重来才换到 Ref-CAS。其三，官方暂未公布内测申请入口、收费方式与 GA 日期，博文作者为 GitHub 杰出工程师 Karthik Raman 与首席工程师 Brian Celenza。
各方说法
Rubicon 公布时，智能体时代的源码管理之争已经分成两条路线。Anthropic 的 Scion 属于另起炉灶：官方博文明言它「绝非 git 的通用替代品」，也不开源——The New Stack（Meredith Shubel，2026-10-15）的报道标题就叫「但你拿不到它」。OpenAI 的 Pando 则保持 git 兼容：同一媒体的后续报道（Frederic Lardinois，2026-11-02）记录它 push 延迟降近 5 倍、每天服务近 1 PB Git 数据。Rubicon 与 Pando 同侧：不改协议与客户端，只改存储。
Anthropic 工程博文里的一句话被两家媒体反复引用：「现在的瓶颈，全是为人类规模修建的开发基础设施：源码管理、构建和 CI。」Rubicon 是 GitHub 对同一诊断给出的平台级答案。IT之家 2026-11-07 的中文报道把官方数字完整转述给中文读者，同样把「每秒 7,200 次推送」与「最繁忙仓库每秒几十次」并列呈现。
社区侧的反应还没有成形：截至 2026-11-07，Hacker News 上没有 Rubicon 的专门讨论帖；作为对照，Scion 10 月发布时曾拿到 649 分、617 条评论。各方对 Rubicon 本身的质疑与实测，预计要等扩围后才会出现。
编辑判断
Rubicon 对在 GitHub 上跑智能体的团队意味着：push 延迟与 CI 签出风暴的缓解是平台级的，而且不用迁出 git 生态——这是它与 Scion、Pando 最实际的差别，后两者都只服务自家仓库。仓库越挤、智能体越多的团队，受益越直接。
但官方数字要当压测看，别当实测看。5,000 并发、7,200 次推送出自 GitHub 自己的实验环境；private preview 没有公开的申请通道；最难啃的场景——trunk 单引用上的合并队列争抢——官方只说按引用拆共识，没给这种极端情况的数字。明年初的扩围能否平稳落地，才是检验这套架构的真正节点；在此之前，把 Rubicon 当作一份路线宣言更接近事实。
接下来
Rubicon 的官方时间表只有一条：limited private preview 之后，2027 年初扩大开放范围。值得盯两件事：扩围时是否公布申请通道与配额条件；官方是否补上 trunk 单引用场景的实测数字——那是与自家 merge queue 短兵相接的地方。