Anthropic自研Scion替代Git应对AI代码暴增

Anthropic 放弃代码管理工具 Git

自己开发了一套名为 Scion 的版本控制系统，来适应 AI 开发需要...

原因是：AI 已经代替人写代码、代码提交呈指数级暴增，传统的 Git 彻底被撑爆...

合并量暴涨12倍：2026年 5 月，Anthropic每天大概合并 2,500 次代码；到了9月，这个数字冲到了每天30,000 多...

仓库庞大且流量惊人：主分支历史记录接近 100 GB，压缩后的本地副本超过 25 GB；为了跑 CI（持续集成），每天需要执行约 2,500 万次 checkout。如果每次都把压缩副本完整拉取，每天要产生 600 PB 以上的网络流量

Git 的设计假设不再匹配负载：Git 的本质是“去中心化、支持离线工作”，默认的完整克隆保留全量历史。但 Anthropic 绝大多数代码客户端都是始终在线的 AI Agent 和云端 CI 任务。

为了让 Git 扛住，他们以前开了几百个镜像节点，但随着合并频率越来越高，主分支更新太快，镜像扩容、更新快照（seeds），以及在部分副本上计算 diff 和 blame 都越来越难维护...

于是他们用 5 个月自研了一套全新的版本控制系统——Scion。

这套新系统的核心逻辑主要有三点：

按需索取：工作的大多是始终联网的 AI 智能体，不需要每次都把全部历史记录下载下来。系统只在需要某些文件时，才去服务器调取对应内容。

服务器挑大梁：版本管理中复杂、繁重的计算主要放在云端服务器完成，客户端主要负责把文件放到磁盘、监测改动和维护简单缓存，极大地节省了本地机器的资源消耗。

更轻便的记录方式：每次保存修改时，系统只记录改动的文件清单和内容指针，创建变更集时不需要给整个代码库加锁；分支引用另行更新，减少大量任务同时提交时的协调和堵塞。

Anthropic 汲取了 Google 的 Piper 和 Meta 的 Sapling 的经验，提出了几个颠覆 Git 的设计原则：

彻底拥抱“客户端永远在线”：客户端不再需要存全量历史，改向服务端要数据。

非对称架构（轻客户端，重服务端）：

Git 里每个客户端都是全功能服务器；

Scion 则把所有算力集中在服务端：由服务端负责算历史、查责任人（blame）、提交、合代码、rebase；客户端只维持一个很小的本地缓存和工作区目录。

全能力 API 化：CI 任务想要比对两个 commit 之间差了什么，不再需要把整个仓库 clone 下来，直接发个 API 调服务端算好的结果即可。

工作区可选、按需加载（Sparse & Virtualized）：客户端只拉自己关心的目录或文件，没读过的文件根本不用下载到硬盘上。