Claude写代码太快，Anthropic先扛不住了：连Git都要重做

智东西
编译 程茜
编辑 李水青

智东西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