GitHub 秘密测试「Rubicon」：一个仓库塞下 5000 个 AI 智能体，每秒扛 7200 次推送

过去十年，Git 仓库的写入曲线一直很“人类”：白天密集，深夜归零，峰值不过每秒几十次。GitHub 现在赌的是，这条曲线很快会被 AI 智能体拉成一条平直的高原。

当地时间 11 月 5 日，GitHub 发布博文，正式公布代号“Rubicon”的全新 Git 存储架构。该架构在 GitHub Universe 大会上首次亮相，目前只对小范围用户开放定向内测，计划于明年初逐步扩大开放范围。

一分钟速览

• GitHub 新架构 Rubicon 已开启小范围定向内测，明年初扩大开放
• 内部压力测试：单个代码仓库支持 5000 个智能体并发协作，每秒处理 7200 次代码推送
• 写入能力提升到每秒数千次，读取可以按需水平扩展，同时保持极低读取延迟
• 真正的推手是 Agent 带来的“读放大”：一次推送会级联触发 CI、部署系统和多个智能体同时拉取代码

旧地基为什么突然不够用

Git 诞生于一个“人写代码、人合并分支”的年代。它的对象模型围绕内容寻址设计，仓库的写入路径天然假设提交是稀疏的、间歇的。过去这套假设完全成立：GitHub 上最繁忙的代码仓库，单秒写入峰值最多也不过数十次，而且往往是短暂脉冲，过后迅速回落。

AI 智能体改变了这个前提。当天候命的 Agent 不再等待人类下班，它们 7×24 小时提交、回滚、开分支、跑测试。原本的“瞬时突发”会变成常态化的持续高吞吐，而每一次推送都会级联出更多读取：CI 流水线立即启动，部署系统拉取最新提交，其他协同智能体同步获取代码作为上下文。这种读取的扇出扩散，会随着写入频率攀升，对平台流量产生成倍的放大效应。

7200 次推送是什么概念

作为参照，GitHub 现有最繁忙仓库的峰值是“每秒几十次”。7200 次/秒，相当于把全站最忙仓库的瞬时峰值，变成单个仓库的日常水位，差距在两个数量级左右。

更值得注意的不是写入本身，而是读。一次推送触发 N 个读取方，N 又会随着接入的智能体数量增长。GitHub 在博文中给出了一张曲线：某个典型代码仓库在 3 月到 5 月的两个月里，日请求量增长了约 4 倍，此后至今仍维持陡峭的指数级上升。这条曲线如果继续外推，现有存储层的瓶颈不是“写不进去”，而是“读不过来”。

Rubicon 改了什么

官方披露的细节并不多，核心只有三点：每秒数千次写入、读取按需水平扩展、低读取延迟。把这三点放在一起看，方向很清楚——把写入路径和读取路径解耦，让读能力可以独立扩容，而不是被单仓库的物理边界锁死。

这听起来像常规的读写分离，但放在 Git 上难度极高。Git 的引用更新需要强一致性，打包文件又天然是集中式的；既要保证推送后的可见性和顺序，又要让成千上万个读取方各自就近拿到一致快照，等于在保留 Git 语义的前提下重做一层分布式存储。GitHub 选择“先内测、再逐步放开”，也说明这套架构还在啃硬骨头。

版本控制正在变成 Agent 的运行底座

Rubicon 不是孤立事件。OpenAI 为 Codex 自研了 Pando，把推送延迟降低近 5 倍；Anthropic 也被曝弃用 Git，转向自研版本控制系统 Scion。三家最激进的 AI 公司几乎同时动手改造版本控制，指向同一个判断：当代码的主要作者从人变成智能体，Git 就不再只是协作工具，而是 Agent 的运行时基础设施。

这会带来一连串连锁反应。仓库会更大，monorepo 会更常见；CI 的计费方式会从“按人按次”转向“按智能体流量”；权限、审计、冲突解决都要重新设计，因为提交者可能不是一个有邮箱的人，而是一个需要被限流的进程。对普通开发者来说，短期几乎无感；中期则会感受到分支模型简化、评审前置、以及“谁有权让 Agent 合并”这类新问题。

真正的考验在开放之后

Rubicon 本质上不是一次存储升级，而是 GitHub 为“机器提交”时代重画地基。它要证明的不只是压测数字，而是当 5000 个智能体真的住进同一个仓库，账单、权限、冲突和故障隔离能否同时成立。

明年初的扩大开放，会是第一场公开考试。到那时，行业大概会得到一个明确答案：AI 写代码的速度，究竟是被模型能力限制，还是被版本控制的地基限制。