2026-10-24 13:03:25 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

Scion：Anthropic 为超大代码库重做版本控制

原创

Qsec
Qsec

Qsec

2026年10月15日 23:07
江苏

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

Scion：Anthropic 为超大代码库重做版本控制

Anthropic 说，2026 年 5 月每天合并约 2,500 个代码变更，到 9 月已超过 30,000 个。它用五个月把内部主代码库从 Git 迁到了 Scion。

这次迁移的对象是 Anthropic 内部开发环境里的主代码库。Claude Code 面向用户的 Git 使用不在这次迁移范围内。Anthropic 的 CI（自动化构建与测试）每天要检出代码约 2,500 万次，主分支历史接近 100 GB。大量短任务反复准备代码副本，开始拖慢整套开发基础设施。

Scion 的核心变化是由服务器管理仓库历史和提交，客户端只取当前任务需要的文件。

规模压力

Git 的一个优势是每个开发者都能有一份本地仓库。拿到代码后，可以在本地查看历史、切换版本，网络断开时也能继续工作。对多数项目，这个设计很合适。

Anthropic 遇到的是另一种工作负载。后台任务很多，其中 CI 和编码 Agent 会反复创建短期工作区。单个任务可能只运行一会儿，却要频繁准备代码。压缩后的工作副本也超过 25 GB。任务数量上去后，反复下载、检出和更新数据就成了独立的基础设施成本。

开发者的本地仓库通常会反复使用；CI 工作区则往往随着任务结束而销毁。同一批文件被不同任务重复下载，费用会不断叠加。因此问题落在总量上。单次克隆快几秒帮助有限，若每天仍要数千万次重复准备，负担不会消失。

Git 本身提供浅克隆、稀疏检出等优化。Anthropic 用过这些办法，也维护了数百个内部 Git 镜像。镜像能分担下载流量，但需要持续追上主分支；CI 仍要查询提交关系和文件历史。随着变更量上升，Git 镜像与历史服务也要承担更多维护工作。

Scion 想降低的是整套工作流里反复准备代码的成本。它把仓库历史和主要写操作交给服务端，让客户端只取当前任务确实要用的数据。

Anthropic 工作负载规模

架构分工

Scion 把请求分成两类。一类是查仓库信息、记录变更；另一类是读取文件内容。

Scion 两条请求路径

这张图根据公开资料整理，只概括各部分的逻辑关系。Anthropic 公开的信息显示，Spanner 保存元数据等信息，Cloud Storage 提供文件对象；通信协议、容量配置和内部代码路径没有公开。

Scion 也是分阶段建成的。自有客户端、仓库格式和通信协议完成前，团队先让服务端回答仓库元数据问题。随后补齐对象读取和客户端缓存，再完成工作区并逐步迁移主仓。代码评审和搜索系统需要接通，权限也要迁入。从架构上看，这让团队可以先搬走查询负载，再处理文件读取和工作区。

先看查询。CI 可以请求两个版本的差异或共同祖先。比如，只需确认一个提交是否进入目标分支时，服务端返回关系结果后，任务就能结束，不必先下载文件树。查询与文件下载因此可以分开处理。

再看文件读取。构建任务如果只需要某个服务的目录，客户端就请求这部分目录对应的对象；服务端只返回缺少的内容。一个只分析提交关系的任务可以完全跳过文件读取。版本控制因此成为 CI 和 Agent 能直接调用的服务，不再要求每个任务先准备完整的本地仓库。

变更模型

Scion 把一次提交记作 changeset。可以把它理解为一张变更清单，记录相对基础版本改了哪些文件。文件内容则单独压缩存放，并按内容生成对象标识。两份文件内容相同，就能使用同一个标识，缓存也能复用。

举个简单例子，一次改动只更新了 config.json，changeset 就记录这个路径和新内容对应的对象。没有变化的文件不需要随这次提交重新传一遍。

changeset 由服务端创建，创建后即可被其他客户端看到。工作流不需要先在每个任务里本地提交，再把提交推到中央仓库。服务端还会从这些记录生成查询索引，例如查看文件每一行是谁改的（blame），或追踪某个路径的历史。有的索引提前生成，有的等到查询时再计算，客户端不必自己扫描仓库里的全部提交。

主分支指针和 changeset 分开更新。提交先记录变更；更新 main 指针时，服务端用 Spanner 中的单行 CAS（比较并交换），检查当前值仍是预期值后才写入新值。若另一个任务已经移动了指针，旧写入就不会覆盖新状态。这样一来，大量提交不必都争抢同一个主分支状态。

这套模型把文件内容和分支状态分开。文件对象创建后不变，能在不同任务和缓存间共享；主分支指针会变化，才需要用 CAS 保护更新。大量读取因此可以交给缓存，服务端重点协调的共享状态则少了一些。

Git 也用对象标识管理和复用数据。Scion 的差别在于由服务端掌握历史与写入，客户端按需请求这些对象。

changeset 与文件对象关系

对象读取

Scion 从目录树开始，沿着选中的路径找到需要的子目录和文件。客户端只按对象标识请求缺少的内容；对象可以分批传输、断点续取。一个任务不必先把完整仓库历史下载完，才能开始准备自己的工作区。

工作区有两种按需方式。任务目标明确时，只检出所需目录；如果事先不知道会访问哪些文件，可以先呈现目录结构，等文件真正被打开时再下载内容。前一种适合固定构建目标，后一种适合需要继续探索的开发工作区。

举个简化例子。CI 要构建一个服务时，Scion 只读取该服务需要的目录和文件对象。另一台任务机器稍后请求相同对象时，区域缓存可能直接提供，不必再次访问底层存储；如果任务最终产生代码变更，服务端再创建 changeset。这个流程用于说明公开架构，具体任务配置没有公开。

对象读取会经过本机缓存、区域缓存，再到 Scion 服务端和底层存储。同一台机器上的多个任务能复用本机缓存，不同机器也能共享区域热点。对象不可变、标识固定，各层可以按对象复用缓存。每层只向相邻上游取数据，避免区域缓存出问题时大量节点同时直连权威服务。Anthropic 称系统各层缓存命中率超过 99%，也就是说，大多数对象请求能在缓存层得到响应；这个数字是公司自报的。

Anthropic 表示，没有任何一台机器保存完整物化仓库。节点后台进程和区域缓存保存的是实际访问到的对象。公开资料没有说明 Scion 使用哪种具体文件系统接口；Meta 的 EdenFS 和 Microsoft 的 GVFS 可以帮助理解虚拟工作区的做法，但不能据此推断 Scion 的实现。

稀疏检出与虚拟化工作区

并发写入

在 Scion 里，记录一次变更和移动主分支指针是两步操作。更新主分支时，服务端会先核对当前指针；只有它仍符合预期，才会写入新值。这种“先检查、再更新”的方式叫 CAS（比较并交换）。如果另一个任务已经移动了指针，较早发出的更新就不会覆盖新状态。

Scion 没有把所有变更都排进一个全局合并队列，更多正确性检查放到合入后和部署前。这样能减少串行等待，让许多变更同时进入主线。代价是主分支可能先接到有问题的变更，再由合入后测试发现；团队必须快速修复，必要时回滚。Anthropic 没有公开冲突重试策略或故障恢复时限。

并发提交与 main 指针 CAS

一次任务

可以用一个简化流程把前面的组件串起来：

CI 先向服务端查询差异、祖先关系等元数据；如果任务只需要这些信息，到这里就结束。
2. 2.

构建任务再选定所需目录，从本机缓存、区域缓存或对象存储中取文件。
3. 3.

如果任务还要提交代码，服务端创建 changeset，再单独更新主分支指针；合入后的测试继续检查结果。

这三步里，只有第二步需要真正读取文件。大量任务可以共用缓存，服务端也不用为每个任务都准备一份完整仓库。

收益与边界

Anthropic 自报，Scion 的 CPU 和内存占用约为旧 Git 镜像系统的 1/200。CI 和研究任务的检出从分钟级降到秒级；CI 的 CPU 效率提升约 25%。这些是 Anthropic 的内部数据，比较基线是旧镜像系统，尚无独立评测；其他团队的工作负载不同，结果也可能不同。

这种设计适合客户端常在线、任务数量大、单次只需要仓库一小部分的环境。如果每个任务都要读取几乎整个仓库，按需读取能省下的数据就少；开发者经常离线时，完整本地副本反而更有用。网络或服务端出现故障时，客户端没有完整本地仓库可供离线查历史。路径权限还必须和缓存读取一起检查。文件命中缓存，也不代表当前用户有权访问。

虚拟工作区还得兼容常用开发工具，尤其是文件监视和构建工具。代码评审和搜索系统需要接入，CI 与权限也要迁移或协调。工程量远超编写一个 scn 命令。

我的判断是，Scion 的价值取决于工作负载。重复检出和历史查询已经成为主要成本时，服务端型版本控制才可能划算。迁移前还要把省下的重复检出成本，与建设服务端、缓存和权限体系的投入放在一起算。对多数项目，Git 的本地副本、离线能力和成熟工具链仍然更实用。评估时可以先统计每日检出次数和每个任务实际需要的仓库比例，再比较节省的传输与新系统的维护成本。