内部测试指标

经内部压力测试验证，新架构能够在保持极低读取延迟的同时，支撑单个代码仓库容纳 5000 个智能体（Agent）并发协作，并承受每秒高达 7200 次的代码推送（push）。

目前 Rubicon 已开启小范围定向内测（limited private preview），并计划于 2027 年初逐步扩大开放范围。

为什么要重构 Git

GitHub 观察到，随着越来越多研发工作交由全天候、高并发运行的 AI 智能体处理，传统以仓库为中心的存储与协调机制正面临新的吞吐与延迟压力。

如今 GitHub 上最繁忙的代码仓库，单秒写入峰值最多不过数十次，且往往呈短暂脉冲式突发。然而，智能体驱动的持续高吞吐正将这种瞬时突发演变为常态。有数据显示，某个典型仓库在 3 月至 5 月期间的日请求量激增约 4 倍；此后访问量始终保持陡峭的指数级上升。

每一次推送还会级联触发更多读取：持续集成流水线启动、部署系统拉取最新提交、其他协同智能体同步获取代码作为上下文。这种读取扇出效应，随着写入频率攀升被显著放大。

架构如何解耦

Rubicon 的核心思路是”减少协调、解耦存储与计算”。Git 对象具有不可变、按内容命名的特性，因此多个写入者可以几乎同时保存对象而无需互相等待；真正需要有序确认的，主要是分支、标签等引用（reference）的更新，而引用更新的数据量小得多。

新架构主要由几部分构成：Spokes 入口层负责路由、负载均衡与租户隔离；一组可动态增减的虚拟副本（virtual replica）处理读取与写入，其本地磁盘仅是随时可重建的缓存；Git 对象与 pack 文件存放于 Azure Blob Storage；引用及 pack 清单则位于独立的复制日志服务 Ref-CAS（Reference Compare-and-Swap，引用比较并交换）中，用于多副本间按顺序确认引用变化；后台压缩与垃圾回收节点直接针对持久化存储执行，不再与读取请求争用资源。

GitHub 表示，其已将 99.99999% 的代码仓库副本迁移至 Azure，并以 Azure Blob Storage 支撑虚拟副本。由于智能体通常各自推送到独立分支，多数更新不会争用同一引用，可并行复制；只有当两个推送同时修改同一引用时，才会由其中一个成功追加到日志。

意义与展望

Rubicon 首先服务于智能体驱动的开发范式，但影响不限于 AI 编程工具。若大量智能体能在同一仓库并行工作，团队可将任务拆成更多独立分支，由智能体分别执行编码、测试、修复与审查，再由开发者或自动化流程完成合并。这将推动代码托管平台从”保存开发者提交”转向”协调大规模并发软件生产”。

需要明确的是，5000 个智能体与每秒 7200 次推送均为内部测试数据，不等同于所有用户当前可获得的服务等级或商业化容量承诺。Rubicon 更像是面向下一代开发模式的基础设施预告：GitHub 正在提前重建底层存储，让单一代码仓库未来能够容纳远超传统人类协作规模的并发智能体工作流。