智东西

编译 | 程茜

编辑 | 李水青

智东西 10 月 14 日消息，今日，Anthropic 发布一套对标 Git 的源码控制系统Scion，并已在单体仓库中用 Scion 取代了 Git。

一个7 人团队在 5 个月内构建了 Scion 和代码审查工具 Antique 以及六个相关的系统，并完成所有迁移。

长期以来，Git 已成为现代软件工程的重要协作基石与事实标准，是绝大多数软件团队管理代码、留存变更历史、多人协同的必备基础工具。它就像一个软件世界的 " 时光相册 " 和多人协作工作台，让开发者看清代码的修改脉络。

Anthropic 做这件事的背景是，在其内部，2026 年 5 月平均每天合并约 2500 处代码变更，到 9 月日均合并量已经突破3 万笔，4 个月暴涨 12 倍，且这一增长势头短期内不会放缓。代码合并的潜在需求几乎无限，研究人员每消除一个瓶颈，代码产量就会立即进一步增加。

如今，Claude 能够自主迭代研究流程，对复杂程序做精细化优化，还可以从零搭建全新服务，其执行速度与规模前所未有。当下真正的瓶颈，是原本面向人类开发者打造的基础设施正不堪重负，如版本控制、构建流程与持续集成（CI）。

Scion 系统中，每一层都保持着超过99%的缓存命中率，并且不需要长期状态。就 CPU 和内存需求而言，Scion 基础设施占用空间为 Git 镜像基础设施的1/200。

CI 和研究作业检出代码的速度提高了两个数量级，从几分钟缩短到几秒钟；仅 CI 一项就实现了25%的 CPU 容量提升。同时，客户端和缓存都不需要执行代码库维护，可以简化作业的生命周期管理。

原生 Scion 仓库实测性能提升

这一七人团队还构建并发布了代码审查平台 Antique、代码搜索、功能强大的源代码控制身份和访问管理系统、管理和提交大量已审查代码的新方法等。

Anthropic 也特别提到，Scion 绝非 Git 的通用替代品。Scion 只适用于真正庞大的单体仓库，这类仓库要么有数万名工程师，要么有大量智能体在高效地编写代码。

不过，因为很多组件需要根据公司情况高度定制，因此 Anthropic 不会推出通用的 Scion 版本，只是向业界提供一种思路。

一、日均千万级检出、数百 PB 流量，Git 难以应对 AI 智能体负载

Anthropic 使用 Claude 编写软件的频率远超其他公司，这也使得其更快发现那些为人类设计的工具早已不堪重负。

随着单体仓库不断增长，Git 已不再适用。仅主分支的历史记录就接近 100GB，压缩后的工作副本也超过 25GB。不包括开发环境、代理沙箱和研究任务，Anthropic 每天也需要在 CI 环境中执行约 2500 万次代码检出，简单估算，每天 Git 流量将超过 600PB。

Git 本身支持部分拉取仓库能力，如浅克隆、稀疏检出、承诺远端（promisor remotes）。除此之外，业内也有内部 Git 镜像、存放在对象存储里的仓库快照（seed）等适配巨型单体仓库的常规方案。

基于这些方案，Anthropic 在峰值时期维护了几百个内部 Git 镜像来应对负载。

但即便如此，随着合并量上涨，其运维压力越来越大。快照每次更新后，和主线最新提交的差距越拉越大；而且要保证依赖提交历史的操作在部分克隆上正常运行。

扩展 Git 检出范围的典型设置

在这样的背景下，Anthropic 的研究人员开始思考，多数公司此前只是将 Git 当作集中式系统来用，只维护一个权威仓库。但实际上其绝大多数访问方都是一直在线的智能体、自动化任务。

Git 那些适合分布式离线工作的特性，反倒成了仓库扩容的阻碍。那如果从头设计一套源码控制系统，原生就考虑智能体永远在线这个前提会是什么样？

二、六大设计原则，部分思路与 Git 截然不同

基于上述现状，他们在构建 Scion 时在几个核心原则上采取了与 Git 截然不同的方法，同时其借鉴了大型单体仓库成熟的源代码控制技术，如谷歌的 Piper 和 Meta 的 Sapling。

其构建 Scion 的几个核心原则是：

客户端始终在线：Git 默认客户端离线工作并且需要仓库的完整副本。由于 Anthropic 几乎所有的客户端都是智能体和自动化作业，他们围绕一个始终可访问的服务器设计了 Scion 的客户端和协议，让客户端在需要时获取数据。

客户端 - 服务器不对称：在 Git 中，每个客户端都能够充当功能齐全的服务器。在 Scion 中，服务器负责回答有关文件历史记录和 blame 的问题，创建提交，执行合并和变基等操作。

客户端维护一个有界本地对象缓存，在磁盘上布局工作副本文件，监控文件系统变更，并为用户提供符合人体工程学的服务器交互方式。客户端自身计算能力有限，但作为交换，它所需的本地数据量也少得多。

一套全面的源代码控制服务可以为许多创新应用提供支持：使用 Git 时，CI 作业或工具如果需要查询代码库信息，例如谁最后修改了某一行代码或两个提交之间的关系，就必须维护一份本地代码库副本，或者寄希望于特定厂商的 API 能够提供答案。

而使用 Scion，客户端使用的所有源代码控制查询都通过 API 公开，因此很多情况下作业根本不需要本地代码库。如果没有这种低成本、程序化的源代码控制访问方式，许多内部工具将无法大规模应用。

一切都必须具备水平扩展能力：在高峰时期，Anthropic 运行了数百个 Git 镜像，这会限制服务器容量，一旦仓库规模超过镜像的磁盘或内存限制，就无法继续扩展。在 Scion 中，仓库数据是分布式存储的，每个组件都可以独立扩展，即使在服务器上也没有仓库的完整实例。Scion 没有类似 Git 的对象压缩包的概念，因此无需维护仓库。

提交必须成本低廉、增量式且无锁：在 Git 中，开发者要先在本地提交，然后推送以共享工作。在 Scion 中，每次提交、变基或合并都在服务器端进行，因此无需推送任何内容。创建提交并更新其下游数据结构的成本必须与变更的大小成正比，而不是与仓库的整体大小成正比，否则服务器会跟不上。

Scion 的开发生命周期不鼓励使用引用，除了主引用或发布分支之外，因为所有服务器都必须达成一致的全局状态会带来潜在的扩展性问题。

工作副本可选，设计精简：由于 Anthropic 的单体仓库庞大，并且每天要为了 CI 而检出数千万次代码，因此他们希望尽可能避免检出操作。使用 Scion，开发者需要比较某个提交与其合并基础版本差异的 CI 作业时，可以直接向服务器请求。写入操作也是如此，许多写入工作负载也可以跳过检出，完全通过 API 执行。

Scion 的协议以仅包含客户端请求目录的稀疏检出和按需实例化文件的虚拟化检出为核心，因此当作业确实需要磁盘上的文件时，客户端只需为实际读取的文件付费。

三、专为 AI 智能体负载打造，Scion如何解决巨型仓库痛点？

Scion 中的工作单元是" 变更集 "（changeset），它是预写式日志（Write-ahead Log）中的一个条目。

变更集存储的内容与 Git 提交（commit）类似。但 Git 提交存储的是指向代码树的指针，而变更集存储的是相对于其第一个父级发生更改的文件列表，以及指向 Blob 存储中压缩文件内容的指针。变更集在服务器端创建，并可立即在任何位置访问。

Scion 中变更集的架构

这种架构的好处是可以极高吞吐地接收变更集，不用处理打包文件、无需加锁或跨服务协同，也不用操作引用。

Scion 理论上支持引用，但由于创建、拉取提交都不依赖引用，因此引用的变更只是对单条 Spanner 记录执行一次比较交换，和变更集的提交相互独立。

此外变更集仅记录更改的内容，因此它本身无法快速回答诸如 " 谁最后编辑了某一行 " 或 " 哪些提交影响了某个文件 " 之类的问题。为了回答这些问题，Scion 会基于变更集构建额外的数据结构，包括用于文件错误信息和路径历史记录的专用结构，以及用于提交图的跳过列表。

研究人员将所有不直接属于变更集的数据称为 " 派生数据 "，并通过一个通用机制计算所有这些数据。每种派生数据都是递归定义的，因此它在某个变更集中的值是根据其在该变更集父级变更集中的值计算得出的。

这种机制有三大优点：当新的数据结构能够加快某些操作的速度时，Anthropic 可以快速添加新的派生数据类型；对于每种数据类型，其可以选择立即计算或延迟计算，从而避免实例化不需要的数据；由于客户端永远不会看到这些数据结构的内部细节，研究人员可以在不更改客户端的情况下对其进行优化。

少量 Scion 服务器即可对外提供源码控制接口，支持各类客户端操作，如获取变更集、计算差异、查找合并基、拉取文件对象。所有源码数据都采用内容寻址，数据一旦写入就不会变更，任意服务器都可以缓存，无需和其他节点协商。

因此服务器支持水平扩容，节点间协同开销极低。它们本质上就是大容量缓存，还能实时计算派生数据，并回写至 Spanner。

此外，Scion 的众多用户不再需要维护自己的本地代码库。过去，获取和维护代码库对于 CI 作业或需要查询源代码控制问题的工具来说是一项繁重的维护负担。

在迁移初期，Scion 仅负责处理 " 元数据 " 查询，而获取文件内容和实例化工作副本等操作则需要处理更多的数据，因此需要专门的设计。

Scion 的 scn 客户端和 Git 的拉取协议有几点核心差异，由此可以搭建高可扩展架构，CPU 开销远低于 Git 服务。

在集群里，客户端通过套接字和守护进程 scion-daemon 通信，这个守护进程为本节点统一缓存对象。Scion 大部分节点都需要访问单体大仓库，同一节点上的任务会复用绝大多数对象。

每个守护进程都从一个定期刷新的快照启动，然后仅与其所在区域的树形缓存服务器和 Blob 缓存服务器（scion-cache）通信。这些缓存服务器直接从内存中以守护进程将要使用的磁盘格式流式传输对象，因此它们无需花费时间计算客户端缺失的对象或执行增量压缩。当缓存缺少某个对象时，它会向 scion-server 发出请求，后者会根据需要从 Spanner 或云存储中读取数据。

scion-daemon、scion-cache 和 scion-server 都支持同一套协议 RPC，客户端无需感知缓存的层级拓扑。

Scion 的检出架构

在创建 Scion 的过程中，Claude Mythos Preview 的早期内部快照版本重写了 Git 到 Scion 的数据导入管道，在没有任何进一步指示的情况下，它生成了一个内存占用减少至1/20、速度提升4 倍的版本，同时保留了所有关于数据导入顺序和数据结构的隐式不变性。

2026 年 1 – 9 月，Scion 与 Antique 代码库每周合并变更量

结语：AI 编程，正倒逼专为人开发的研发链路重构

AI 自主编程浪潮下，面向人类开发者设计的基础设施正面临挑战。在 Git 里，开发者手动提交、按需拉取、低并发操作，离线可用性是核心诉求。但当编程主体变成 7×24 小时在线、高频批量迭代的 AI 智能体，就需要重新设计，Anthropic 此次推出的 Scion 面向的就是版本控制环节。

未来伴随 AI 生成的代码量飞速增长，构建系统、缓存调度、代码评审、测试沙箱、权限审计等都需要重新适配 AI 的并发模式。

来源：Anthropic