动察 Beating AI 快讯，GitHub 公布了代号为 Rubicon 的新一代 Git 存储架构。内部测试显示，5000 个 AI Agent 可以同时在一个代码仓库中工作，每秒完成 7200 次代码推送，同时保持较低的读取延迟。
过去，GitHub 最繁忙的代码仓库，每秒也只有短时几十次写入。现在，大量 AI Agent 可以全天候并行开发，不断提交新代码。每次提交还可能触发自动测试，让其他 Agent 下载最新版本，仓库的读写压力随之增加。
GitHub 的解决办法，是把「存代码」和「更新分支」分开处理。
Git 每次推送代码，都要完成两件事。第一步是保存新增或修改后的代码内容。Git 不会直接覆盖旧版本，而是把变化的内容存成新对象，没变的部分可以继续复用。第二步是更新分支指针，记录这个分支现在指向哪个最新版本。
比如，1000 个 Agent 同时开发软件，有的修改登录功能，有的修改支付功能。只要它们在不同分支工作，新代码就可以同时保存，分支也能各自更新。只有两个 Agent 同时争着更新同一个分支时，系统才需要判断谁的更新能先成功。
GitHub 最初让所有分支共用一份更新记录。即使不同 AI Agent 修改的是不同分支，也要争着更新同一个文件，导致每秒只能处理数百次推送。GitHub 又试着把记录拆成多份，让不同分支同时更新。但这样一来，每次检查仓库有没有变化，都得逐份查询，反而拖慢读取速度。
最终，GitHub 开发了专门管理分支更新的 Ref-CAS 服务。它允许不同分支同时更新，只有修改同一分支时才需要处理冲突。同时，它还给整个仓库维护一个统一版本号。其他程序只需检查这个版本号，就能知道仓库有没有变化，不必逐个查询所有分支。
GitHub 另外安排独立机器，在后台合并不断积累的代码数据包，避免数据包越来越多、拖慢读取。新架构最终在内部测试中达到每秒 7200 次推送。
GitHub 的 Rubicon 目前仍处于有限私测阶段，计划在 2027 年初扩大上线。