Anthropic 用自研 Scion 取代 Git：日均代码合并从 2500 次涨到 3 万次

瓶颈从写代码变成了合并代码

Anthropic 在 10 月 13 日的工程博客里披露，公司已在五个月内把整个单体仓库（monorepo）迁出 git，换成自研的版本控制系统 Scion，投入的是一个七人团队。触发这次迁移的是增速：2026 年 5 月，Anthropic 平均每天合并约 2500 次代码变更；到 9 月，这个数字超过了 3 万次。

Anthropic 的说法很直接，写代码已经不是瓶颈了。Claude 能自主迭代研究循环、微优化复杂程序、从零搭建新服务；真正的瓶颈是为人类规模设计的开发者基础设施，也就是版本控制、构建和 CI。据披露，其主分支历史接近 100GB，压缩后的工作副本超过 25GB，CI 每天要执行约 2500 万次代码检出，光这一项如果按朴素方式抓取，每天的 git 流量会超过 600PB。为此他们曾维护数百个内部 git 镜像，但随着合并速率上升，镜像与主干的差距越来越难维持。

为常在线客户端重新设计

Scion 的设计前提是一个假设：客户端永远在线。git 是去中心化系统，每个克隆都是自包含的完整仓库，可以离线算 diff、读历史和检出任意版本，这对绝大多数仓库是正确的设计；但对 Anthropic 这种几乎全部客户端都是智能体和在线任务的工作负载，这些优点反而成了负担。

Scion 因此把 commit、merge、rebase 都放到服务端执行，客户端只保留有界本地缓存；每个变更记录为服务端生成的 changeset，是一组相对第一父提交的文件变更清单加压缩内容的指针。很多工具不再需要真正检出代码，而是通过 API 直接查询版本差异；需要文件时用稀疏检出，或按需物化。对象一经存储就不再改变，因此任何持有它的缓存都能作答，区域缓存命中率因此很容易做高。

Anthropic 的结论不是 git 不好，而是当写代码的主体从人变成智能体，为离线、分布式场景做的优化会反过来限制扩展性。

数字与边界

官方给出的对比是，Scion 的 CPU 与内存占用约为此前 git 镜像方案的二百分之一，CI 与研究任务的代码检出从数分钟缩短到数秒，各级缓存命中率超过 99%。配套的评审界面叫 Antique，同期完成。有意思的是，Claude 也参与了这套系统本身的建设：在 git 到 Scion 的摄取管道上，工程师让它重写整个实现，在没有额外指令的情况下产出了一个内存占用降低 20 倍、速度快 4 倍的版本。

边界同样明确，Anthropic 表示 Scion 不会开源，也绝不是 git 的通用替代品。他们更希望 git 社区采纳兼容的服务端改进、更好的 RPC 与协商协议，来应对智能体规模的工作负载。对大多数团队来说，这个案例的价值不在于照搬 Scion，而在于意识到：当 AI 编程代理把代码产出速度提上去，天花板会先出现在流水线上，而不是模型上。