GitHub 重写 Git 存储，几千 agent 一起推能扛住吗

大伙都在卷模型，这回卷到 Git 头上了。一个仓库里挤着几千个 agent 一起跑，每个都等 push 落地才能走下一步，Git 服务器顶得住吗？

GitHub 给了自己的答案。上周 Universe 大会上亮相的新 Git 存储架构，11 月 5 日又在工程博客发了长文拆解，内部代号 Project Rubicon。按 GitHub 自己的说法，内部测试里单个仓库撑住了 5000 个 agent 一起干活，每秒 7200 次 push。我们 AI主线 的看法是：GitHub 这次动的是 Git 的存储底座，而不是外面的功能，说明它判断 agent 带来的高频写入会是长期常态。不过这套架构目前只开放小范围私有预览，成绩单也还是 GitHub 自己测的。

几十次和七千次，差了多远

先看现状。GitHub 说，眼下 GitHub.com 上最忙的仓库，一秒钟顶多几十次写入，还只是短时间爆发。7200 对几十，差着大约两个数量级，这正是他们给自己定的目标：比当前至少多出两个数量级的余量。

为什么敢这么定？GitHub 拿了一个真实仓库的曲线当依据：3 月到 5 月，它的请求量涨了约 4 倍，日均到了 1.81 亿次，之后还在往上走。全平台也是这个势头，Octoverse 报告说过去一年开发者推送了 179 亿次，比 2024 和 2025 两年加起来还多，9 月已有超过 40% 的 PR 由 agent 起草，半年翻了一倍多。

更麻烦的是读。每次 push 完，CI、部署系统、别的 agent 都要来拉一遍，写一份，读一群。

Git 还是 Git，改的是底下那层

思路其实很朴素。Git 的对象不可变，按内容起名，两个人同时存同一份东西，谁也不用等谁。真正需要排队的，只有分支指针（官方叫 reference）的更新。打个比方：仓库像个大库房，货可以随便往里堆，只有墙上那块“当前进度”的黑板，得一个一个改。

所以 GitHub 把两样东西拆开放。代码本身（pack）放进 Azure Blob Storage；分支指针和“仓库由哪些 pack 组成”的清单，放进自研的复制日志服务 Ref-CAS（名字念着像路由器型号，其实就是管指针的）。每次更新是一次比较并交换，说人话就是改之前先核对“你看到的还是最新版吗”，对得上才让改，而且只锁自己碰到的那几个引用。官方说，光指针这一块能做到每秒几万次操作。

上面干活的虚拟副本是随时能扔的计算节点，本地磁盘只当缓存。合并 pack、清垃圾这类重活交给后台的压缩节点，不再占用服务请求的 CPU。

最有意思的是他们走过的弯路。先试过把所有指针塞进一个 blob，写入最多只到每秒几百次。又拆成几个 blob，写快了，读却得挨个检查，而读比写多出几个数量级，等于拆东墙补西墙。

这成绩单能信几分

我的态度是：思路站得住，数字先打个问号。7200 来自内部测试，没有第三方复现。延迟官方只给了“一直很低”这种定性说法，得看到具体毫秒数才好下判断。

还有个我自己琢磨的点。官方说 agent 多半推自己的分支，所以大多数更新互不打架。可真到合回 main 那一刻，大家挤的还是同一个指针，这一步照样得排队。测试里有多少推送撞在同一个分支上，官方没交代。5000 个 agent 各干各的，和 5000 个 agent 抢着合 main，是两码事。

进度也别指望太快：目前是限量私有预览，更大范围的推出排在明年初，GitHub 同期说多区域的 Azure 迁移也预计明年初完成。眼下普通用户能感受到的，多半只是平台稳不稳。

和 Cloudflare 的路子正好反着来

放到同类里看更清楚。Cloudflare 4 月推出的 Artifacts，官方定位是兼容 Git 的版本化存储，主打一个 agent 一个仓库，能开到几千万个仓库。GitHub 反过来，赌的是一个仓库里挤一大群 agent。GitHub 自己把规模分成横向（很多仓库）和纵向（单个仓库）两条轴，老办法扛横向已经多年，这次发力的是纵向。两边解决的是不同的问题，并不冲突。

对天天开一堆 agent 的开发者，我的判断是：以后并行开大了，不太会先卡在 push 上。对负责选型的技术负责人，该盯的是下一个瓶颈：GitHub Actions 今年平均每秒跑 1440 个任务，Git 存储松了，压力会往 CI 和评审那边挪。

接下来我盯两件事。一是私有预览的客户能不能拿出带延迟的实测数。二是 GitHub 列出的那些后续动作，比如不用 clone 就能读文件、一次提交整包多文件改动的原子提交 API，官方没给时间表。我们 AI主线 更想看的其实是后者，agent 每回都先把整个仓库拖下来，想想都浪费。