Anthropic 弃用 git：每天合并 3 万次代码，自研版本控制系统 Scion

图源：Anthropic 官方工程博客

Anthropic 把 git 换掉了。

昨天它在官方工程博客发文说：公司内部的大代码仓库，已经整体从 git 迁到了自研的版本控制系统 Scion，前后只用了五个月。

起因很简单：代码合并量涨疯了。今年 5 月平均每天合并约 2500 个改动，到 9 月已经超过每天 3 万个，大部分是 Claude 写的。

官方原文

https://www.anthropic.com/engineering/redesigning-source-control

先补两个概念。

版本控制，就是记录代码每一次改动的系统，谁改了哪行、什么时候改的，都能查、能回退。git 是现在几乎所有程序员都在用的那一个。

monorepo（单一大仓库），指公司把几乎所有项目的代码都放在同一个仓库里管。好处是协同方便，坏处是仓库会变得巨大。

另外要说明：Scion 是内部系统，没有开源，官方也明确说暂时不打算对外提供。下文的技术细节都来自官方博客。

Anthropic 弃用 git：每天合并 3 万次代码，自研版本控制系统 Scion图2

每日合并改动数，9 月 9 日单日 30401 个｜图源：Anthropic 官方博客

git 为什么扛不住了

git 的设计是“去中心化”：每个人克隆下来的都是一份完整仓库，断网也能看历史、做对比、切版本。对绝大多数项目来说，这是优点。

但 Anthropic 的仓库太大了。主分支历史将近 100 GB，压缩后的工作副本也超过 25 GB。

CI（每次提交后自动跑测试的流水线）每天要检出代码约 2500 万次，还不算开发机和 Agent 沙箱。要是老老实实全量拉取，一天的 git 流量会超过 600 PB。

他们把 git 的招都用遍了：浅克隆、稀疏检出、内部镜像、仓库快照……最多时养着几百台 git 镜像服务器，还是越来越吃力。

后来他们想明白一件事：自己的客户端几乎全是 Agent 和任务，本来就是一直在线的。git 最擅长的“离线可用”，反倒成了负担。

Scion 的几个核心思路

• 客户端默认在线：需要什么数据，现用现取，不再把整个仓库搬到本地。

• 重活交给服务器：查历史、查某行是谁改的（blame）、提交、合并、变基，全在服务端做。客户端只留一个有上限的本地缓存。

• 所有能力都开放成 API：很多 CI 任务甚至不用检出代码，直接问服务器要 diff 就行。自动二分定位 bug、自动回滚这类工具，也靠它才跑得动。

• 处处可横向扩展：哪里都没有一份完整的仓库，连服务器上也没有，也就不需要 git 那种定期打包维护。

• 提交要便宜：一次提交的开销只跟改动大小有关，跟仓库多大无关；尽量不用分支、标签这种需要全局同步的“指针”。

这些思路也参考了前人的经验，官方点名了 Google 的 Piper 和 Meta 的 Sapling。

一次提交长什么样

Scion 里的基本单位叫 changeset（变更集）。它和 git 的 commit 很像，但只记录“相对上一版改了哪些文件”，外加指向文件内容的哈希。

文件内容压缩后存在云存储里，按哈希去重，存进去就不再变；元数据存在 Google 的 Spanner 数据库里。

Anthropic 弃用 git：每天合并 3 万次代码，自研版本控制系统 Scion图3

Scion changeset 的结构｜图源：Anthropic 官方博客

光记录改动，回答不了“这行最后是谁改的”这类问题。所以服务器会另外算出一批“派生数据”：blame 索引、文件历史、提交图的跳表等。

这些派生数据都是递归定义的，可以提前算，也可以等用到时再算。客户端看不到这些内部结构，所以服务端随时能优化，不用动客户端。

代码怎么发到每台机器

拉文件时，Scion 不像 git 那样先告诉服务器“我已经有什么”，而是只说“我要什么”：从根目录开始，本地缺哪个目录、哪个文件就要哪个。

因为每个对象都按哈希寻址、永不改变，任何一层缓存都能直接回答。架构就是三层缓存：每台机器上的 scion-daemon，每个区域的 scion-cache，最后才是权威的 scion-server。

Anthropic 弃用 git：每天合并 3 万次代码，自研版本控制系统 Scion图4

Scion 的检出架构｜图源：Anthropic 官方博客

官方给的数字：每一层缓存命中率都在 99% 以上；整套基础设施的 CPU 和内存占用，比原来的 git 镜像集群小 200 倍；CI 和研究任务检出代码从几分钟变成几秒，CI 省下 25% 的 CPU。

下面这张是日常命令的对比，比如开发机上 status 从 3.9 秒变成 19 毫秒，Agent 新建工作区从 7.1 分钟变成 5.1 秒。

Anthropic 弃用 git：每天合并 3 万次代码，自研版本控制系统 Scion图5

git 与 scn 常用命令耗时对比（中位数，官方自测）｜图源：Anthropic 官方博客

七个人，五个月

更有意思的是怎么做出来的。官方说，整个 Scion 加上代码审查工具 Antique，还有一堆配套系统，是一个七人团队在五个月里做完并迁移上线的。

举个例子：最早那版从 git 导入 Scion 的程序是人手写的。后来他们让内部早期版本的 Claude Mythos Preview 重写一遍，不加额外指令，新版本内存省了 20 倍、速度快了 4 倍。

Anthropic 弃用 git：每天合并 3 万次代码，自研版本控制系统 Scion图6

Scion 和 Antique 代码库每周合并的改动数｜图源：Anthropic 官方博客

团队成员都觉得，Claude 写代码已经比自己强。但工程师的活没少，只是变了：很多时候工程师的作用是对 Claude 说“不”。

比如 Agent 有时会为了套用某个模式，违反系统的核心约束；对抗式审查有时又太“神经过敏”，让 Claude 加了一堆多余的校验。人现在审代码，更多是看改动的意图，而不是逐行读。

运维上也有新玩法：他们给每个组件配了一个专门盯着它的 Claude，叫“superfan”，整天看监控和日志，找不对劲的地方。

普通团队要不要跟

官方自己说得很清楚：Scion 不是 git 的通用替代品，只适合几万工程师或者大批 Agent 一起写代码的超大仓库。

它跟 git 差别太大，需要配套自己的代码审查、搜索和 CI，所以也不打算做成公开产品。

但他们判断，未来 6 到 12 个月，用 AI 写代码的公司会越来越多地碰到同样的问题。所以先把思路分享出来，希望 git 生态（比如服务端提供更完整的查询接口、改进拉取协议）能吸收其中有用的部分，并表示愿意和 GitHub、GitLab 及开源社区合作。

注：文中性能和规模数据均为 Anthropic 官方自述，目前未见第三方独立验证。