Anthropic 重做源代码管理系统：提交量增长 12 倍，传统架构开始失效

Anthropic 最近详细介绍了如何将其单体代码仓库从 Git 迁移至 Scion。Scion 是一套将代码仓库操作移至服务器端的源代码管理系统，使用内容寻址存储和分层缓存来支持智能体与 CI 工作负载。该设计牺牲了离线独立性，换取更少的本地数据和共享基础设施。

Anthropic 在 10 月 13 日发布的工程文章中表示，单日合并变更数从 5 月的约 2500 个增长到了 9 月的 3 万多个。其 CI 系统每天大约执行 2500 万次检出，而单体代码仓库主分支的历史记录接近 100GB，压缩后的工作副本也超过 25GB。该公司此前使用浅克隆、稀疏检出、Promisor Remote、仓库快照以及数百个 Git 镜像，但随着合并频率不断提高，这些方案的运维难度也越来越大。

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

Scion 将提交、合并、变基、历史记录和代码追溯查询都放在服务器端执行。客户端只维护容量受限的对象缓存，虚拟化检出则按需实体化文件。工具还可以通过 API 查询差异并执行部分写入操作，无需检出代码。

Scion 变更集会记录相对于其第一个父变更集发生变化的文件，并使用内容寻址指针引用 Blob 存储中经过压缩的文件内容。创建变更集与更新引用彼此分离，因此接收变更集不需要跨服务器协调。对于历史记录和代码追溯查询，Scion 会构建名为“派生数据”的附加结构。这些数据根据父变更集递归计算，可以提前生成，也可以按需生成。由于实现位于服务器端，派生数据可以独立演进，而无需修改客户端。

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

执行检出时，客户端会直接请求缺失的不可变树和 Blob，而不再协商生成自定义 Packfile。节点本地守护进程会在不同任务之间共享缓存对象，并从区域缓存中获取数据；区域缓存再从权威服务器获取数据，后者由 Spanner 和云存储提供支持。区域缓存会直接以守护进程使用的存储格式流式传输对象，因此无需针对每次请求执行增量压缩。

各层都公开相同的检出协议 RPC，但 Anthropic 会强制规定调用顺序，以隔离故障，防止区域缓存失效时大量请求压垮权威服务器。稀疏检出和虚拟化检出只会请求实际需要的对象。

Anthropic 报告称，每一层的缓存命中率都超过 99%，CPU 和内存基础设施占用仅为此前 Git 镜像的二百分之一，CI 与研究任务的检出速度则提升了两个数量级。这些结果由 Anthropic 根据其内部工作负载得出，并不是与 Git 进行对比的通用基准测试。

InfoQ 此前曾报道 Uber 的 GitFarm。GitFarm 在不替换源代码管理系统的情况下，将标准 Git 操作集中到服务器端。Scion 更进一步，改变了底层数据模型。其设计也建立在已有成果之上：Anthropic 在 10 月 15 日的一次更新中明确表示，Mononoke 及其 Bonsai 数据模型率先采用了 Scion 所使用的许多技术。

Anthropic 提醒，Scion 并不是通用的 Git 替代品。它需要配套的代码审查、代码搜索和 CI 系统，而该公司的这些实现都经过了高度定制。Anthropic 建议将其中一些设计理念引入现有 Git 平台，例如完备的服务器端 API 和更高效的获取协议。

对于架构师而言，最重要的启示是：当工作负载发生变化时，需要重新考虑计算工作应该在哪里执行。代码仓库查询不一定需要本地检出，不可变对象也可以通过缓存共享。这些做法能够减少重复工作，但 Scion 依赖服务器的可用性，而且所需的系统集成工作也相当庞大。

原文链接：https://www.infoq.com/news/2026/10/anthropic-source-control/