Anthropic 为什么放弃 git：日合并 3 万次代码后，自研版本控制系统 Scion

Anthropic 的代码合并量从 5 月的日均约 2500 次涨到 9 月的 3 万次以上，git 的分布式设计反而成了瓶颈。他们用五个月把 monorepo 迁到自研的 Scion，并总结了六条面向 agent 时代的版本控制设计原则。

瓶颈从写代码转移到了基础设施

• Claude 已经能自主跑研究循环、微调复杂程序、从零搭建服务，写代码不再是瓶颈，卡住的是为人类规模设计的源码管理、构建和 CI。
• 2026 年 5 月 Anthropic 日均合并约 2500 次代码变更，到 9 月超过 3 万次，团队认为这个增速短期内不会放缓。
• 主分支历史接近 100 GB，压缩后的工作副本超过 25 GB；每天约 2500 万次代码检出用于 CI，还不算开发者环境、agent 沙箱和研究任务。
• 如果按朴素方式拉取，每天会产生超过 600 PB 的 git 流量。

git 为什么撑不住

• git 是去中心化设计，每个克隆都是完整仓库，能离线算 diff、读历史、查 blame，这对绝大多数仓库是对的，但和超大 monorepo 不匹配。
• 他们试过 shallow clone、sparse checkout、promisor remote、内部镜像和 blob 存储快照，高峰期跑了几百个内部 git 镜像。
• 镜像和快照只是买时间：合并率一高，快照离主分支最新提交越来越远，依赖历史的 diff、blame 在部分克隆上越来越难维护。
• 关键观察是：他们实际把 git 当集中式系统用，而客户端几乎全是永远在线的 agent 和任务，git 为离线分布式做的优化反而拖累了扩展性。

Scion 的六条设计原则

• 客户端永远在线：围绕始终可达的服务器设计协议，客户端按需取数据，不再假设需要完整副本。
• 客户端与服务端不对称：服务端负责历史、blame、创建提交、合并和 rebase；客户端只维护有上限的本地对象缓存、落盘工作副本、监听文件变化。
• 源码控制服务本身可支撑新应用：客户端用的查询全部开放成 API，CI 任务不必持有本地仓库，自动 bisect 和 revert 流水线才跑得起来。
• 一切必须水平扩展：仓库数据分布式存放，任何地方都没有完整物化的副本，也没有 packfile，因此不需要仓库维护。
• 提交要便宜、增量、无锁：提交、rebase、合并都在服务端完成，成本随改动大小增长而不是仓库大小；除主分支和发布分支外尽量不用 ref。
• 工作副本可选且默认稀疏：CI 任务可以直接向服务端要 diff，写操作也能纯走 API；协议以稀疏检出和按需物化的虚拟检出为中心。

数据结构：以 changeset 为单位

• Scion 的工作单元是 changeset，本质是预写日志（write-ahead log）里的一条记录。
• git commit 存的是指向 tree 的指针，changeset 存的是相对第一个父提交的变更文件列表，以及指向 blob 存储中压缩文件内容的内容寻址指针。
• changeset 在服务端创建，立刻全局可见；没有 packfile 要接收、没有锁和跨服务协调、没有 ref 要移动，因此吞吐很高。
• Scion 技术上支持 ref，但创建和拉取提交都不经过 ref，移动 ref 只是对 Spanner 单行做一次 compare-and-swap，与创建 changeset 分离。
• changeset 只记录变化，所以单看一条无法快速回答某些历史问题，这也是文章后续要解决的部分。

对使用 AI 编码的团队意味着什么

• Anthropic 承认自己的工作负载极不寻常，但认为其他重度使用 AI 编码工具的公司迟早会遇到同样的压力点。
• 有超大 monorepo 的源码控制先例可参考：Google 的 Piper 和 Meta 的 Sapling，Scion 借鉴了它们的经验。
• 迁移不是只换版本控制：同期还自建了代码评审界面 Antique、代码搜索、源码控制 IAM，以及批量落地已评审代码的新流程。
• 一个反直觉的结论：Claude 既是造成这个瓶颈的原因，也是他们能在五个月内建出并迁移到 Scion 的原因。