AI 工程实践

GitHub 为何重写 Git 存储：5000 个 Agent 同时推代码之后

GitHub 在内测中让一个仓库扛住了 5000 个并发 Agent、每秒 7200 次推送，代价是把用了多年的 Git 存储架构 Spokes 换掉。这篇文章讲它到底改了什么、为什么旧架构顶不住，以及同一周 Copilot 进 Xcode 和 JetBrains Air 意味着什么。

11 月 5 日，GitHub 工程博客发了系列文章的第三篇，讲它新的 Git 存储架构。文章里有一个数字值得先摆出来：内测中，一个仓库同时跑 5000 个 Agent，每秒 7200 次推送，读延迟一直保持在低位。

这不是一个性能宣传数字。它是 GitHub 在承认一件事：旧的存储架构到顶了。一个月前的第一篇文章已经把背景摊开：2026 年 9 月，GitHub 上一个月产生了 73.8 亿次提交，是去年同期的 5 倍多；推送从每月 6.9 亿次涨到 33.5 亿次；全平台 Git 活动从 2025 年 9 月的每月 2182 亿次事件涨到 2026 年 8 月的 4733 亿次，翻了一倍多。最忙的那个仓库，8 月一个月就收到了大约 10 亿次请求。

改了什么：Rubicon

新架构代号 Rubicon，2026 年 5 月启动，两条原则：尽量少协调，存储和计算分开。

旧架构 Spokes 把每个仓库的完整副本存在几台文件服务器的本地磁盘上，默认 5 份。推送更新引用时走三阶段提交，用 quorum 保证各方看到一致的状态。问题在于，同一批副本既是持久层又是服务层：每份副本都参与每一次写，推送的速度取决于最慢的那份副本。想多扛读流量就得加副本，加了副本写又变慢。

Rubicon 把这两件事拆开。持久状态只剩两处：Git 对象（pack 加读加速数据）放在 Azure Blob Storage；引用和 pack 清单放在一个叫 Ref-CAS 的复制日志服务里。每次引用更新是一次 compare-and-swap，由多数日志副本提交后生效，只锁住这次更新真正触及的引用；每次提交得到一个日志序列号，仓库的版本就是最新那个序列号。

写路径是：虚拟副本给收到的 pack 建索引，上传到 Blob，再用一次 Ref-CAS 事务同时更新 pack 清单和引用。读路径反过来：先向 Ref-CAS 核对引用版本，再从 Blob 把需要的 pack 拉进缓存。虚拟副本是一支可以丢弃的计算舰队，本地磁盘只是可重建的缓存，仓库忙了就多加副本，闲了就撤掉。压实和垃圾回收也不再跟线上请求抢机器：压实节点在后台直接对 Blob 和 Ref-CAS 工作，按分片持租约并行合并 pack，新 pack 必须校验过、确认对象和输入完全一致才会发布；删分支和 force-push 留下的无引用对象由专门的 worker 清理。

走到这一步之前，GitHub 还试过两个原型，都失败了。单 blob 预写日志一次只能有一笔条件写入在途，写吞吐只有每秒几百次。分段 blob 让不同的写不用互相等，但读要查所有分段，速度取决于最慢的那一段。Ref-CAS 是第三个答案：只对引用本身做协调。Agent 各推各的分支，互不争用，并行复制；引用状态本身能做到每秒几万次操作。

GitHub 在 10 月 6 日的第一篇文章里说，新架构在内部基准测试中写吞吐最高达到旧架构的 35 倍。这句话要小心读：它是 GitHub 自己的基准，没有公开测试方法，也不是生产环境的承诺。真正能对上号的数字是内测那组：5000 个并发 Agent、每秒 7200 次推送。

为什么是 Agent 把它打穿的

人写代码和 Agent 写代码，对 Git 服务器来说是两种完全不同的负载。人是白天集中推送，晚上安静，突发之后有喘息的时间。Agent 是 24 小时并行工作，突发变成了持续速率。GitHub 举了一个仓库的例子：每天的请求量从 3 月均值 4400 万次涨到 5 月均值 1.81 亿次，约 4 倍，而且之后还在指数增长。

Agent 的工作方式在三个地方放大了压力。第一，Agent 处在紧循环里，几乎每做一步就提交或 checkpoint 一次，单次推送的延迟直接决定了它的速度，人根本注意不到的几十毫秒延迟，在这里就是瓶颈。第二，每次推送都会扇出成千上万次读：CI 和代码扫描每分钟成千上万次 fetch 同一个分支尖端，GitHub Actions 9 月一个月就跑了 32.6 亿次，是去年同期的 4 倍多。第三，合并都挤在同一个引用上：主干开发、发布列车、合并队列把所有工作 funnel 到一根分支上，GitHub 上 PR 合并量已经涨到去年同期的近 4 倍。

所以设计目标也定得很高：单仓库扩展能力至少再提高两个数量级。GitHub 的判断是，Agent 不是一阵风，突发会变成常态，基础设施得按这个来建。

同一周的另一件事：Copilot 进了 Xcode 和 JetBrains Air

同一周还有另一件事，动静小一点，但方向是一致的。11 月 3 日，GitHub Copilot 进了 JetBrains Air；11 月 4 日，进了 Xcode 的内置 coding assistant。

JetBrains Air 里的 Copilot 基于 Agent Client Protocol，在 Air 的 agent picker 里选 Copilot，就能用已有的 Copilot 订阅委派任务、跟踪执行、审阅结果。任务可以在本地 IDE 里跑，也可以经 Air Teams 在云端隔离容器里跑；云端任务走 Copilot 套餐，不扣 JetBrains AI 点数，但需要 JetBrains 账号在开通 Air Teams 的业务组织里，并且由 Air 管理员启用 Copilot。

Xcode 那边是公开预览，从 Xcode 27.3 beta 开始，在 Xcode > Settings > Intelligence 里设置，需要 macOS Tahoe 26.6 或更高版本。所有 Copilot 套餐都支持，原来的 Copilot for Xcode 扩展作为独立选项保留。

这两件事合起来看，Copilot 正在从"VS Code 里的一个助手"变成"任何一个 IDE 都能接进来的 Agent"。编辑器的竞争还是其次，真正的变化在协议层：ACP 让 IDE 变成 Agent 的启动器，Agent 不再被绑在某一个编辑器里。对开发者来说，选 IDE 的时候要多问一句：它能不能接我想用的 Agent。

和 Scion 的对照

这件事和 Anthropic 的 Scion 是同一道题的两个答案，我上个月写过 Scion。Anthropic 的单体仓里，合并量从 5 月每天 2500 次涨到 9 月每天 30000 次，Git 撑不住了，他们的答案是换掉 Git：Scion 把引用和元数据放 Spanner，对象放 blob 存储，前面加缓存，提交先在本地完成、再异步同步到远端。

GitHub 的答案正好相反：保住 Git，重写它底下的存储。原因也很直接，GitHub 不能换掉 Git，十亿个仓库都跑在上面，分支、评审、合并、历史这些工作流一个都不能变，整个重建还得在 GitHub 保持在线的情况下完成，不能停机，不能让用户改习惯。

两个答案的诊断是一致的：Git 是为人设计的。人一次改完、一次提交、一次推送，中间有思考的时间。Agent 是每步都提交、24 小时不停、成千上万个并行。Anthropic 选择了换系统，GitHub 选择了换地基。哪条路更好现在还看不出来，但两家同时动手，说明问题已经不是"会不会来"，而是"已经来了"。

对开发者意味着什么

对普通开发者来说，短期内什么都不用改。Git 还是 Git，clone、push、pull 的用法一个没变。新架构现在是有限私有预览，更广泛的推广要到明年年初。你自己的仓库明天不会突然扛住 7200 次推送，也不需要。

真正变化的是天花板的位置。以前一个仓库的上限由"多少人能同时写"决定，以后由"多少 Agent 能同时写"决定。GitHub 还在铺后面的路：不用 clone 就能直接从服务器读文件、一次提交多个文件的原子提交 API、事件流；对 Git 本身也在改，更轻量的 clone、更快的历史遍历、提前预警常见坑。

基础设施的改动总是滞后于使用方式的改动。这一次，滞后了不到一年。Agent 先把 Git 的使用方式改了，GitHub 再把底下的存储改了。顺序就是这样：先有人这么用，系统才跟着变。

本文基于以下公开资料撰写：

关于

关注我获取更多资讯

月球基地博客公众号二维码，扫码关注获取更多 AI 与编程资讯
📢 公众号
月球基地博客作者个人微信二维码，扫码交流 AI 与编程话题
💬 个人号

本文链接地址：https://blog.eimoon.com/p/github-git-storage-5000-concurrent-agents/

作者：eimoon.com

分享转载说明：本文由作者原创，转载请注明出处。

© 2023 - 2026 longlikun
使用 Hugo 构建
主题 Stack 由 Jimmy 设计