Anthropic 用 Scion 换掉 Git：日合并量冲到 3 万，缓存命中率超 99%

Anthropic 近日披露了把单体代码仓库从 Git 迁到 Scion 的完整过程。Scion 把仓库操作挪到服务器端执行，靠内容寻址存储和分层缓存来支撑智能体与 CI 负载。代价是放弃离线独立性，换来的是本地数据更少、基础设施共享。

10 月 13 日发布的工程文章里，Anthropic 给出了一组数字：单日合并变更数 5 月约 2500 个，到 9 月已经超过 3 万个。CI 系统每天跑大约 2500 万次检出；主分支历史记录接近 100GB，压缩后的工作副本也超过 25GB。此前他们用过浅克隆、稀疏检出、Promisor Remote、仓库快照和数百个 Git 镜像，可合并频率一涨，这些方案越来越难运维。

2026 年 1 月至 9 月，Anthropic 单体代码仓库每天合并的变更数量。（来源）

在 Scion 里，提交、合并、变基、历史记录和代码追溯查询全部由服务器端完成。客户端只保留容量受限的对象缓存，虚拟化检出按需把文件实体化。工具还能直接调 API 查差异、做部分写入，不用先把代码检出到本地。

变更集会记下相对第一个父变更集有哪些文件变了，并用内容寻址指针引用 Blob 存储里压缩过的文件内容。创建变更集和更新引用是分开的，所以接收变更集不需要跨服务器协调。历史记录和代码追溯查询则依赖一套叫“派生数据”的附加结构，它按父变更集递归算出来，可以提前生成，也能按需生成。实现放在服务器端，派生数据就能独立演进，客户端不用跟着改。

Scion 变更集记录发生变化的文件及其内容引用；树结构由服务器单独派生。（来源）

检出的时候，客户端直接去要缺失的不可变树和 Blob，不再协商生成自定义 Packfile。节点上的本地守护进程会在不同任务之间共享缓存对象，数据先从区域缓存取，区域缓存再向权威服务器要，后者由 Spanner 和云存储支撑。区域缓存按守护进程使用的存储格式直接流式传输对象，每次请求不必再做增量压缩。

各层对外暴露的都是同一套检出协议 RPC，不过 Anthropic 强制规定了调用顺序。这样能把故障隔离开，区域缓存失效时不会有一大堆请求压垮权威服务器。稀疏检出和虚拟化检出只请求真正用得到的对象。

据 Anthropic 报告，每一层的缓存命中率都超过 99%，CPU 和内存基础设施占用只有此前 Git 镜像的二百分之一，CI 与研究任务的检出速度快了两个数量级。这些数字来自 Anthropic 自己的内部工作负载，并非与 Git 对比的通用基准测试。

InfoQ 此前报道过 Uber 的 GitFarm，那套方案不换源代码管理系统，只把标准 Git 操作集中到服务器端。Scion 走得更远，连底层数据模型都改了。它的设计也吸收了已有成果：Anthropic 在 10 月 15 日的一次更新中明确表示，Mononoke 及其 Bonsai 数据模型率先采用了 Scion 所用的许多技术。

Anthropic 提醒，Scion 不是通用的 Git 替代品。它得配上代码审查、代码搜索和 CI 系统，而这家公司的这些实现都经过高度定制。Anthropic 建议把其中一些设计理念搬到现有 Git 平台上，比如完备的服务器端 API 和更高效的获取协议。

对架构师来说，最该记住的一点是：工作负载变了，计算该放在哪里执行也得重新想。仓库查询不一定非要本地检出，不可变对象也能通过缓存共享。这么做能减少重复劳动，但 Scion 依赖服务器可用性，系统集成的工作量也相当大。