Anthropic 的 Scion：Anthropic 如何用面向智能体规模的版本控制系统取代 Git

Anthropic 宣布其构建了内部版本控制系统 Scion，并在五个月内将其单体仓库完全从 Git 迁移出来，原因是 Git 的去中心化、离线优先设计已无法跟上 AI 智能体编写代码的速度。该公司报告称，合并的代码变更从 2026 年 5 月的每天约 2500 次增长到 2026 年 9 月的每天超过 30000 次，并且 Scion 的基础设施占用（按 CPU 和内存计算）比之前的 Git 镜像设置小 200 倍。

核心问题：编码不再是瓶颈

在 Anthropic，构建系统和进行研究的瓶颈不再是编写代码——而是为人类规模构建的开发基础设施：源代码控制、构建和 CI。Claude 可以自主迭代研究循环、微优化复杂程序，并从零开始构建新服务，而周围的工具已成为制约因素。

Anthropic 引用的增长数字非常惊人。2026 年 5 月，Anthropic 平均每天合并约 2500 次代码变更。截至 2026 年 9 月，每天合并超过 30000 次。Anthropic 表示预计这一增长速度不会放缓，并将合并代码的潜在需求描述为“几乎无限”，并指出每消除一个瓶颈都会立即导致产生的代码量进一步增加。

除了 Scion，Anthropic 还构建并推出了一个名为 Antique 的代码审查界面、代码搜索、源代码控制 IAM 系统，以及管理和落地大量已审查代码的新方法——所有这些都在同一五个月内完成。

为什么 Git 不再适合 Anthropic 的单体仓库

Git 是一个去中心化系统，每个克隆都是一个完整、自包含的仓库，可以在完全离线的情况下计算差异、读取历史和 blame，并检出任何修订版本。Anthropic 明确表示，对于绝大多数仓库来说，这是正确的设计，这也是 Git 成为标准的重要原因。然而，Anthropic 的单体仓库越来越超出这种设计空间。

Anthropic 给出的具体规模数据：

仅主分支的历史就接近 100 GB。
一个压缩的工作副本超过 25 GB。
Anthropic 每天执行约 2500 万次代码检出用于 CI，这还不包括开发环境、智能体沙箱和研究任务。
如果天真地获取，每天将产生超过 600 PB 的 Git 流量。

Anthropic 使用了所有可用的标准变通方法：浅克隆、稀疏检出、promisor 远程仓库、内部 Git 镜像，以及存储在 blob 存储中的仓库快照（种子）。在高峰期，Anthropic 运行了数百个内部 Git 镜像来应对负载。这些方法争取了时间，但随着合并率的增加，操作变得越来越困难——种子在刷新之间与主分支尖端的距离越来越远，并且保持 diff 和 blame 等依赖历史的操作在部分克隆上正常工作需要越来越多的关注。

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

Scion 背后的六项原则

Anthropic 提到了大型单体仓库中源代码控制的先前实践，特别是 Google 的 Piper 和 Meta 的 Sapling，并表示在构建 Scion 时考虑了这些来之不易的经验教训。设计基于六项原则：

1. 客户端始终在线

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

2. 客户端-服务器不对称

在 Git 中，每个客户端都可以成为完整的服务器。在 Scion 中，服务器回答关于文件历史和 blame 的问题，创建提交，执行合并和变基等。客户端维护一个有界的本地对象缓存，在磁盘上布局工作副本文件，监视文件系统更改，并提供与服务器协作的便捷方式。它自己几乎无法计算，但本地需要的数据要少得多。

3. 全面的源代码控制服务可以驱动许多新颖的应用

使用 Git，需要询问仓库问题（谁最后更改了一行，两个提交如何相关）的 CI 任务或工具必须维护本地副本或依赖特定于供应商的 API。使用 Scion，客户端使用的所有源代码控制查询也通过 API 公开，因此在许多情况下，任务根本不需要本地仓库。Anthropic 表示，如果没有这种廉价的、程序化的源代码控制访问，其内部的自动二分查找和回滚管道在大规模下将不切实际。

4. 一切都必须水平可扩展

在高峰期，Anthropic 运行了数百个 Git 镜像，这给容量带来了压力，并且一旦仓库超出镜像的磁盘或内存限制，扩展就会停止。在 Scion 中，仓库数据是分布式的，每个组件都可以独立扩展。任何地方都没有完全物化的仓库副本，即使在服务器上也是如此。没有类似 Git 的 packfile，因此不需要仓库维护。

5. 提交必须廉价、增量且无锁

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

6. 工作副本是可选的，并且设计上就是稀疏的

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

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

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

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

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

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

服务架构：守护进程、缓存和服务器层

一小群 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 的基础设施占用（按 CPU 和内存要求计算）比之前的 Git 镜像基础设施小 200 倍。
CI 和研究任务检出代码的速度快了两个数量级——从几分钟缩短到几秒——释放了整个集群的大量容量。
仅 CI 就实现了 25% 的 CPU 容量提升。
客户端和缓存都不需要执行仓库维护，简化了任务的生命周期管理。

Anthropic 在构建 Scion 中学到了什么

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

Claude 重写了摄取管道

Anthropic 最初主要手写了 Git 到 Scion 摄取管道的第一版作为原型。在获得 Claude Mythos Preview 的早期内部快照后，团队要求它重写整个管道。在没有进一步指示的情况下，Claude 生成了一个内存消耗减少 20 倍、速度快 4 倍的版本，同时保留了围绕摄取顺序和数据结构的隐式不变量。

小团队现在可以在几个月内完成多年迁移

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

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

Anthropic 表示，参与该系统的所有工程师现在都会认为 Claude 在编写代码方面比他们更好。这些工程师仍然提供了对高层系统间组件和设计级权衡的理解，就解决哪些问题以及达到什么规模做出明智的选择。Anthropic 将工程师的角色描述为经常告诉 Claude“不”：智能体有时会违反核心系统约束，以满足一个本不应被允许的模式。这在迁移期间尤其常见——例如，多个系统试图通过线性读取提交日志来暴力查找更改何时合并到主分支，而不是询问代码审查工具。

Anthropic 还广泛使用对抗性审查，它称之为非常有效但有时目光短浅。熟练的工程师必须引导 Claude 避免针对假设性担忧的过度工程化；其中一次审查对信任另一个内部服务过于防御，导致 Claude 添加了过多的验证和复杂性。团队成员仍然审查系统的每个更改请求，但他们现在检查更改的意图，而不是逐行阅读代码。

优化和质量显著提高

由于 Claude 可以比人类快得多地编写大量代码，Scion 是 Anthropic 有史以来测试最充分、防御最严密的代码库之一。即使在紧张的时间表上，团队也为其遇到的每一次非平凡基础设施和源代码控制交互构建了封闭模拟，以及模糊测试和复杂的速率限制。Anthropic 还报告说，Claude 轻松发现了显著的优化——例如，对祖先查询的算法优化，该优化错过了团队的一个索引，这项工作可能需要专家数天或数周的分析和调整——然后在第二天又做了一遍。

单体仓库安全的新形式

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

“超级粉丝”：Claude 作为组件级监视器

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

重新思考合并队列和 CI

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

Scion 不是通用 Git 替代品

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

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

Anthropic 对更广泛 Git 生态系统的建议

Anthropic 预计这类问题将在未来 6 到 12 个月内变得更加普遍，并认为每个使用 Git 的公司都独自面对类似挑战将是工程资源的低效使用。因此，其声明的贡献是分享其想法，以便其他开发人员可以将 Scion 最成功的部分应用到 Git 中，而无需偏离整体模型。

Anthropic 为 Git 提出的具体方向：

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

Anthropic 最后承认，Git 社区花了近二十年时间为数百万开发人员扩展平台。它将自己的贡献描述为更狭窄——分享关于智能体软件开发如何与这些系统交互的早期观点——并表示希望与 GitHub、GitLab 和 OSS 社区合作，以支持开发人员在软件开发生命周期与 AI 指数增长交汇时不断变化的需求。