Anthropic 的 Scion：为智能体规模单体仓库重新设计源代码控制

Anthropic 宣布其构建了内部版本控制系统 Scion，并在五个月内将其单体仓库完全从 git 迁移出来，因为为人类规模设计的开发者基础设施——源代码控制、构建和 CI——已成为瓶颈，而如今 Claude 编写了公司大部分代码。这篇文章是 Scion 设计的技术案例研究，而非产品发布：Anthropic 明确表示 Scion 并不适合作为 git 的通用替代品，并且没有计划广泛提供它。

问题：合并量超出了 git 的能力

Anthropic 的合并率在四个月内增长了约 10 倍，且公司预计这一增长不会放缓。2026 年 5 月，Anthropic 平均每天合并约 2,500 个代码变更；截至 2026 年 9 月，每天合并超过 30,000 个。Anthropic 将合并代码的潜在需求描述为“几乎无限”，并指出每消除一个瓶颈，都会立即导致代码产量进一步增加。

单体仓库的规模是基础设施压力的直接原因。仅主分支的历史就接近 100 GB，压缩后的工作副本超过 25 GB。Anthropic 每天为 CI 执行约 2,500 万次代码检出，这还不包括开发环境、智能体沙箱和研究任务。如果以朴素方式获取，每天将产生超过 600 PB 的 git 流量。

git 的去中心化设计——每个克隆都是一个完整、自包含的仓库，可以计算差异、读取历史和 blame，并在完全离线的情况下检出任何修订——对于绝大多数仓库来说是正确设计，Anthropic 也明确如此表示。但它并不适合这种工作负载。Anthropic 使用了浅克隆、稀疏检出、promisor 远程、内部 git 镜像以及 blob 存储中的仓库快照（种子）。在高峰期，公司运营着数百个内部 git 镜像来应对负载。这些变通方法争取了时间，但随着合并率的增加，操作变得越来越困难：种子在刷新之间与主分支尖端偏离更远，而保持 diff 和 blame 等依赖历史的操作在部分克隆上正常工作需要越来越多的关注。

推动 Scion 的关键观察是：Anthropic 将 git 用作具有单一权威副本的集中式系统，但其几乎所有客户端都是智能体和任务，它们本质上是在线的。使 git 在分布式、离线工作中表现出色的特性，在仓库增长时反而积极削弱了 Anthropic 的扩展能力。

智能体规模源代码控制的六项原则

Scion 的设计基于与 git 不同的一组假设。Anthropic 将大型单体仓库源代码控制中的先前工作——Google 的 Piper 和 Meta 的 Sapling——视为设计参考。

客户端始终在线。 git 假设客户端离线工作并需要仓库的完整副本。由于 Anthropic 几乎所有客户端都是智能体和任务，Scion 的客户端和协议围绕始终可达的服务器构建，客户端在需要时获取数据。

客户端-服务器不对称。 在 git 中，每个客户端都能成为完整的服务器。在 Scion 中，服务器回答关于文件历史和 blame 的问题、创建提交、执行合并和变基。客户端维护有界的本地对象缓存，在磁盘上布局工作副本文件，监视文件系统更改，并提供到服务器的易用接口。它自身能计算的内容很少，但本地所需数据也少得多。

全面的源代码控制服务可以支持许多新颖应用。 使用 git，需要询问仓库问题——谁最后更改了一行，或两个提交如何关联——的 CI 任务或工具必须维护仓库的本地副本或依赖特定于供应商的 API。使用 Scion，客户端使用的所有源代码控制查询也通过 API 暴露，因此在许多情况下任务根本不需要本地仓库。Anthropic 表示，如果没有这种廉价的、程序化的源代码控制访问，其许多内部工具（如自动二分和回滚流水线）在规模上是不切实际的。

一切必须水平可扩展。 Anthropic 在高峰期运行的数百个 git 镜像在容量上捉襟见肘，一旦仓库超出镜像的磁盘或内存限制，扩展就停止了。在 Scion 中，仓库数据是分布式的，每个组件都可独立扩展；任何地方都没有完全物化的仓库副本，即使在服务器上也没有。没有 packfile 的等价物，因此不需要仓库维护。

提交必须廉价、增量且无锁。 在 git 中，你在本地提交，然后推送以共享工作。在 Scion 中，每次提交、变基或合并都发生在服务器上，因此没有需要推送的内容，但每个操作必须快速。创建提交和更新其下游数据结构的成本必须随变更大小扩展，而不是随仓库整体大小扩展。Scion 的开发生命周期不鼓励 refs（指向提交的指针，如分支和标签），除非是主 ref 或发布分支，因为每个服务器都必须达成一致的全局状态是一个迫在眉睫的扩展问题。

工作副本是可选的，并且设计上就是稀疏的。 由于单体仓库如此之大，且代码每天被检出数千万次用于 CI，Anthropic 希望尽可能避免检出。需要提交与其合并基础之间差异的 CI 任务可以向服务器请求。许多写入工作负载也可以跳过检出，完全通过 API 运行。Scion 的协议以稀疏检出的核心，其中只包含客户端请求的目录，以及虚拟化检出，按需物化文件，因此任务只需为其实际读取的内容付费。

Scion 的工作原理：变更集和派生数据

Scion 的工作单元是“变更集”，即预写日志中的一个条目。变更集存储了 git 提交存储的大部分内容，但 git 提交存储指向树的指针，而变更集存储相对于其第一父级更改的文件列表，以及指向 blob 存储中压缩文件内容的内容寻址指针。变更集在服务器端创建，并立即可在所有地方使用。

这种结构使 Anthropic 能够以非常高的吞吐量接受变更集，因为没有需要接受的 packfile，没有锁定或跨服务器协调，也没有需要移动的 refs。Scion 技术上支持 refs，但由于创建和获取提交都不涉及它们，移动 ref 是对单个 Spanner 行的比较并交换操作，与创建变更集分开进行。

由于变更集只记录更改内容，它本身无法快速回答诸如谁最后编辑了一行或哪些提交影响了文件等问题。因此，Scion 从变更集构建额外的数据结构，包括专门用于文件 blame 和路径历史的结构，以及用于提交图的跳过列表。Anthropic 将不属于变更集直接部分的所有内容称为“派生数据”，并通过一个通用机制计算所有派生数据：每种类型的派生数据都是递归定义的，因此其对变更集的值是从其对该变更集父级的值计算得出的。

Anthropic 列举了这种机制的三个好处：当新数据结构能使某些操作更快时，可以轻松添加新类型的派生数据；每种类型可以急切或延迟计算，避免物化不需要的数据；由于客户端永远不会看到这些数据结构的内部，可以在不更改客户端的情况下优化它们。随着系统增长，Anthropic 多次添加了新类型的派生数据，包括用于复制检测和基于路径的文件搜索的新索引。

扩展 Scion：分层缓存架构

一小群 Scion 服务器为客户端所需的任何操作提供源代码控制 API，例如获取变更集、计算差异、查找合并基础和获取 blob。所有源代码控制数据都是内容寻址的，因此数据一旦存储就不会更改，任何服务器都可以缓存它而无需与其他服务器检查。因此，服务器是水平可扩展的，几乎不需要协调——本质上是大型缓存，还可以即时计算派生数据并将结果写回 Spanner。

Scion 的 scn 客户端在几个重要方面偏离了 git 的获取协议。Scion 的协商不会告诉服务器客户端已经拥有什么；相反，它完全基于客户端想要的树和 blob 进行操作。从根树开始，客户端检查其本地存储中缺失的树并递归请求它们，然后对 blob 重复该过程。每个请求都是针对永远不会更改的特定对象，因此任何缓存都可以回答它，架构与传统分层缓存非常相似。该过程高效且可恢复，因为没有单个多 GB 的 packfile 响应。稀疏和虚拟化检出不需要特殊支持，因为客户端根本不会请求它不想要的树。

客户端通过套接字与守护进程 scion-daemon 通信，该守护进程存储整个节点的对象。大多数节点需要访问单体仓库，同一节点上的任务重用大多数相同的对象。每个守护进程从定期刷新的快照开始，然后只与其区域内的树和 blob 缓存服务器（称为 scion-cache）通信。这些缓存服务器直接从内存中以守护进程将消费的磁盘格式流式传输对象，因此它们不会花时间计算客户端缺失的对象或执行增量压缩。当缓存缺少对象时，它会询问权威的 scion-servers，后者根据需要从 Spanner 或云存储读取。

scion-daemon、scion-cache 和 scion-server 都对此协议响应相同的 RPC，因此客户端不需要知道缓存拓扑。任何层理论上都可以与任何其他层通信，但 Anthropic 严格执行分层以隔离故障域，避免区域 scion-cache 的故障压垮上游 scion-servers 并导致整个系统崩溃的情况。

实测结果

Anthropic 报告了迁移的以下结果：

系统的每一层都保持超过 99% 的缓存命中率，并且不需要长期状态，使其易于扩展。
Scion 的基础设施占用空间比之前的 git 镜像基础设施小 200 倍（就 CPU 和内存需求而言）。
CI 和研究任务检出代码的速度快了两个数量级——从几分钟缩短到几秒——释放了整个集群的大量容量。
仅 CI 就实现了 25% 的 CPU 容量提升。
客户端和缓存都不需要执行仓库维护，简化了任务的生命周期管理。

Anthropic 在构建 Scion 中学到的东西

Anthropic 大约在 Claude Mythos Preview 和 Claude Tag 内部可用时开始构建 Scion。文章指出，这两个版本同时放大了对 Scion 的需求，并显著加快了构建速度。

一个具体例子：今年早些时候，Anthropic 主要手写了 git 到 Scion 摄取流水线的第一个版本作为原型。在获得 Claude Mythos Preview 的早期内部快照后，团队要求它重写整个流水线。在没有进一步指示的情况下，它生成了一个内存消耗减少 20 倍、速度快 4 倍的版本，同时保留了摄取顺序和数据结构的隐式不变量。

小团队快速开发将变得更加普遍

一个七人团队构建了 Scion 和 Antique（Anthropic 的代码审查工具），以及六个相关系统，并在五个月内完全迁移到它们——而每天合并的代码量增加了 10 倍。Anthropic 指出，以前开发和部署这样的源代码控制系统可能需要公司多年的迭代迁移和更多工程师，并预计这种快速、灵活的迁移将变得更加普遍。

工程师并非不再有价值，但他们的工作正在改变

Anthropic 表示，所有参与该系统的工程师现在都会认为 Claude 在编写代码方面比他们更好。但工程师仍然提供了对高层系统间组件和设计级权衡的理解，做出明智的选择，决定解决哪些问题以及达到什么规模。Anthropic 将工程师的角色描述为经常告诉 Claude“不”：

智能体有时会违反核心系统约束，以满足本就不应被允许的模式。

这在迁移期间尤其常见。例如，多个系统试图通过线性读取提交日志来暴力查找变更何时合并到主分支，而不是询问代码审查工具。Anthropic 还广泛使用对抗性审查，它称之为极其有效但有时目光短浅，因此熟练的工程师必须引导 Claude 避免针对假设性问题过度设计系统部分。其中一次审查对信任另一个内部服务过于防御，导致 Claude 添加了过多的验证和复杂性。团队成员仍然审查系统的每个变更请求，但现在检查变更的意图，而不是阅读每一行代码。

优化和质量显著提高

由于 Claude 可以比人类更快地编写大量代码，Anthropic 将 Scion 描述为其所处理过的测试最充分、防御最严密的代码库之一。即使在紧张的时间表上，团队也为其遇到的每个非平凡基础设施和源代码控制交互构建了封闭模拟，以及模糊测试和复杂的速率限制。Claude 还发现了显著的优化——例如，对祖先查询的算法优化，该查询遗漏了团队的一个索引——Anthropic 表示这需要专家数天或数周的分析和调整，而第二天它又做到了。

为新型单体仓库安全奠定基础

Scion 支持仓库上的丰富访问控制，以及将权限应用于单个目录的能力，以保护最敏感的代码而不失去单体仓库的好处。Anthropic 构建的代码审查工具可以对批准表达复杂的语义约束，区分简单更改（如仅注释编辑）和敏感逻辑更改，以便人类审查者可以专注于最重要的更改。

新的卓越运营水平成为可能

Anthropic 大量使用 Claude Tag 来监控系统的每个组件。团队创建了 Slack 频道，Claude 的任务是痴迷地关注单个组件的健康状况——内部称为“超级粉丝”。有 scion-daemon 超级粉丝、scion-cache 超级粉丝、Antique 合并队列超级粉丝等等。他们可以访问遥测和日志，像经验丰富的工程师一样，除了刷新图表和寻找任何异常之外没有更好的事情可做。Anthropic 也运行传统警报，但表示超级粉丝可以检测到微妙和新颖的问题，使这些警报相比之下显得一维。

Anthropic 正在重新思考其先验

该项目促使 Anthropic 重新审视其他为人类规模设计的工作流程。例如，适当的合并队列在智能体规模下没有多大意义，文章问道，当测试运行时数百或数千个更改可以合并时，CI 意味着什么。Anthropic 无法有效复制行业标准的全局仓库锁在合并队列上，因此它投资于合并后和部署前自动化测试。这意味着并发更改可能冲突，但 Anthropic 表示 Claude 通常可以比人类识别冲突更快地修复这些冲突。

Scion 不是 git 的替代品，Anthropic 也不会开源它

Anthropic 明确表示，Scion 绝不是 git 的通用替代品。所概述的概念仅对真正巨大的单体仓库有意义，要么有数万名工程师，要么有大量智能体大量编写代码。Anthropic 还指出，其独特之处在于，其内部使用代币的能力远远超过任何其他企业现实上愿意花费的——它这样做既是为了满足自身的软件开发需求，也是为了测试 Claude 的能力。

实际上，Anthropic 表示很难提供一种对其他组织广泛有用的 Scion 形式。它与 git 有显著差异，意味着公司需要迁移开发生命周期的每个部分，并且它需要自己的代码审查、代码搜索和 CI。Anthropic 这些组件的内部版本高度定制，其他组织难以采用；公司担心试图取悦所有人的公开版本实际上不会非常有用。

相反，Anthropic 表示它能做的最有影响力的事情是分享其想法，以便其他开发者可以将 Scion 最成功的部分应用于 git，而不偏离整体模型。文章中的具体建议：

git 服务器不必与 git 客户端的工作方式相同；存在提供显著扩展改进的新颖服务器架构。
git 平台可以提供像 Scion 这样的全面服务器端 RPC，甚至可能在各个 forge 之间标准化，git 客户端可以学会与之通信。
协商协议不必看起来完全像今天这样，git 的各种稀疏和浅层功能可以很好地组合。

Anthropic 预计这类问题将在未来 6 到 12 个月内变得更加普遍，并认为每个使用 git 的公司都独自面对类似挑战将是工程资源的低效使用。文章最后承认，git 社区花了近二十年时间为数百万开发者扩展平台，并将 Anthropic 的贡献描述为更狭窄：对智能体软件开发如何与这些系统交互的早期见解，以便与 GitHub、GitLab 和开源社区合作。

技术脚注

Scion 存储相对于合并的第一父级更改的文件。Anthropic 将其描述为风格选择，指出在实践中，在单体仓库的基于主干的开发中，人们只关心主线上提交的历史或 blame。

文章由 Nick G. 和源代码控制团队（S.G.、R.K.、Dan C.、Garrett H.、Ben L.、Colin M.、Joe P.）撰写，感谢 Vilas J. 和 Sergiu D. 对团队的支持，以及 Amir O. 对 Antique 的早期贡献。