公司新闻

Claude 写代码太快，Git 扛不住了：Anthropic 仅靠 7 人，5 个月重造版本控制系统

今年5月，Anthropic每日合并的代码修改次数平均约为2500次。到了9月，这一数字攀升至超过3万次。仅四个月间，代码合并量激增了12倍以上。

2026年1月至9月，Anthropic单体代码仓库（Monorepo）每日合并的代码变更数量呈现显著上升趋势。

这种增长主要归因于Claude。AI编码代理能够自主调整代码、运行测试、反复优化程序，甚至从零开始构建服务。代码生产速度提升后，原本为人类工程师设计的软件开发基础设施逐渐显现出滞后。

Git率先成为严重瓶颈。Anthropic的Monorepo主分支历史已接近100GB，压缩后的工作副本超过25GB。仅持续集成（CI）系统，每日需执行约2500万次代码检出。若采用简单的Git数据获取方式，每日可能产生超过600PB的数据传输需求。

Anthropic此前已运用Git浅克隆、稀疏检出、内部镜像和对象存储快照等多种优化手段，高峰期甚至维护着数百台Git镜像服务器。然而，随着代码合并量持续上升，这一方案愈发难以维系。

于是，Anthropic做出了一个相当大胆的决定：重新开发一套版本控制系统。

10月13日，Anthropic在官方工程博客中披露了这项工程。一个仅有7名工程师的团队，在五个月内开发出名为Scion的新版本控制系统，并完成了整个Monorepo的迁移。同时，他们还打造了代码审查工具Antique、代码搜索系统、权限管理及其他配套基础设施。

迁移后，Scion基础设施的CPU和内存占用降至原有Git镜像方案的约1/200，CI和研究任务的代码检出速度提升了约两个数量级，仅CI就节省了约25%的CPU容量。

更有趣的是，Claude既是造成基础设施压力的关键因素，也是帮助Anthropic完成系统改造的重要工具。

1 每日3万次代码合并，Git究竟为何不堪重负？

Git之所以成为软件开发行业的标准工具，很大程度上得益于其分布式设计。开发者可在本地保存仓库历史、创建提交、比较差异，即使离线也能完成大部分操作。

对于绝大多数软件项目，这是一套非常成功的设计。但它也意味着，客户端需具备相当完整的版本控制能力，并保存执行相关操作所需的仓库数据。

Anthropic面临的工作负载已经发生了显著变化。

首先，代码仓库本身日益庞大。接近100GB的主分支历史和超过25GB的压缩工作副本，使得频繁创建开发环境、CI环境和代理沙箱变得成本高昂。其次，代码检出频率极高。每日约2500万次检出尚未计入开发者环境、代理沙箱和研究任务产生的额外需求。

更关键的是，代码变化的速度远超传统开发团队。Anthropic在官方文章中表示，每消除一个开发瓶颈，代码产出量就会进一步增加。开发基础设施需持续应对这种增长。

为维持Git的运行，Anthropic曾部署数百台内部镜像服务器，并在对象存储中保存仓库快照。这些方案虽能减少重复下载，但也引入了新的维护负担。镜像需不断同步，快照很快落后于主分支，而在部分克隆环境中保持diff、blame等依赖历史信息的操作正常工作，也愈发复杂。

Anthropic由此重新审视了一个长期存在的设计假设：既然大多数代码操作都由始终联网的代理和自动化任务完成，为何每个客户端还需像传统Git客户端一样，具备独立处理完整仓库历史的能力？

这成为Scion设计的起点。

当然，超大规模Monorepo与Git之间的矛盾并不新鲜。Google很早就开发了内部集中式版本控制系统Piper，Meta也投入多年建设Sapling。Anthropic此次遇到的问题与这些大型科技公司有相似之处，但驱动力有所不同：过去主要是庞大的工程师组织和代码仓库规模，现在，大量并行工作的编码代理也开始产生类似压力。

2 Scion如何设计？将版本控制的大部分工作移至服务器

Scion最重要的设计变化，是将版本控制从以本地仓库为中心的工作方式，转向始终在线的客户端—服务器架构。

在Git中，客户端可独立创建提交、执行变基、查询历史，再将修改推送到远端。Scion则将提交、合并、变基、历史查询等主要操作交由服务器端完成。客户端主要负责维护有限的本地缓存、管理工作目录，以及监控文件变化。

由于提交直接在服务器端创建，Scion不再需要传统Git工作流中的push步骤。客户端也无需下载大量与当前任务无关的仓库数据。

这一改变还让版本控制能力可直接通过API提供给其他系统。例如，CI任务若只需计算某次提交与合并基点之间的差异，就可直接请求服务器返回结果，不必先检出整个代码仓库。自动化回滚、定位问题提交等工具，也能通过API查询版本历史。

从工程架构上看，Scion试图让版本控制操作的成本更多取决于实际修改的数据量，而非整个仓库的规模。

为实现这一点，Scion重新设计了底层数据结构。

在Git中，一个提交会引用对应的目录树。Scion则采用名为Changeset的变更记录，将其写入预写日志。每条Changeset记录相对于第一个父提交发生变化的文件，以及指向压缩文件内容的内容寻址引用。

文件内容保存在Blob Storage中，版本关系和相关元数据由后端系统管理。Scion使用Spanner存储部分需协调的元数据，并尽可能减少创建提交时的跨服务器同步。

这种设计使提交能快速创建和分发，也避免了Git Packfile机制带来的部分打包、协商和维护开销。

Scion仍支持类似Git分支和标签的引用，但尽量减少对它们的依赖。Anthropic认为，若大量操作都需更新全局共享状态，就容易重新引入协调瓶颈。因此，Scion的常规提交创建不依赖移动ref，只有主分支或发布分支等场景需要更新这些引用。

不过，将操作移至服务器并不意味着问题自然解决。服务器需同时承受大量代理和CI任务的请求，若所有客户端都直接访问中央存储，系统仍可能被流量压垮。

Anthropic因此设计了一套分层缓存架构。

在计算节点上，scion-daemon负责为同一节点上的多个任务共享文件对象缓存。区域内的scion-cache服务器提供第二层缓存，再向上连接权威的scion-server。只有缓存未命中时，才需继续访问Spanner或云存储。

客户端请求的是具体的不可变对象。由于对象采用内容寻址，缓存不需反复确认对象是否发生变化，各层服务也可独立横向扩容。

Anthropic披露，这套架构每一层的缓存命中率都超过99%。它还通过明确的缓存层级隔离故障，避免某个区域缓存出现问题时，大量请求直接涌向上游服务。

Scion同时将稀疏检出和虚拟化检出作为基础能力。客户端只获取需要的目录和文件，部分文件直到实际访问时才会被加载。对于只需版本元数据的任务，甚至可以完全跳过工作目录创建。

最终，Anthropic报告Scion的基础设施CPU和内存占用相比原有Git镜像方案缩小约200倍，代码检出从分钟级缩短到秒级，CI获得约25%的CPU容量节省。

需要注意的是，这些指标对应不同的优化维度。200倍指的是基础设施资源占用差异，两个数量级指的是代码检出速度，25%则是CI容量收益，不能简单理解为Scion在所有操作上都比Git快200倍。

3 七个人、五个月，Claude将重写基础设施的速度也提升了

如果说Scion的架构设计反映了代理规模化带来的系统变化，那么它的开发过程，则展示了编码代理对软件工程组织方式的另一种影响。

Anthropic披露，Scion和配套代码审查工具Antique由一个7人团队开发。团队在五个月内完成系统建设及整个Monorepo的迁移，同时还交付了代码搜索、权限管理等多个相关系统。

这个过程中，Claude承担了大量代码实现与优化工作。

官方文章介绍了一个具体案例：Scion早期的Git数据导入管线主要由工程师手写完成，团队原本认为性能已经不错。后来，他们让内部早期版本的Claude Mythos Preview重新实现整个管线。

在没有进一步指令的情况下，Claude生成的新版本将内存消耗降低了20倍，执行速度提高了4倍，同时保留了原有的数据导入顺序和数据结构约束。

这个案例的意义在于，代理已能参与复杂基础设施的性能优化，而不只是完成局部函数、接口或业务代码的编写。

但Anthropic也强调，这并不意味着工程师的作用消失了。

团队成员认为Claude在代码编写方面已经超过了自己，但系统层面的设计决策仍依赖工程师，包括理解不同组件之间的关系、判断架构取舍，以及决定哪些问题值得解决。

官方文章中有一个很有意思的细节：工程师的一项重要工作，是告诉Claude“不要这样做”。

这与Scion项目的实际特点有关。高吞吐、低延迟、横向扩展、故障隔离和数据一致性之间存在大量取舍。某种实现即使代码质量很好，也未必符合系统长期运行的要求。工程师需从整体架构和生产环境约束出发，决定哪些方案可以接受。

Claude还被用于日常系统运维。Anthropic团队创建了一批被称为“superfans”的Claude代理，分别关注Scion的不同组件。例如，一个代理持续监控scion-daemon，另一个关注scion-cache，还有代理专门观察Antique合并队列。

2026年1月至9月，Scion和Antique代码库每周合并的代码变更数量也呈现增长趋势。

这些代理可读取遥测数据和日志，持续检查系统状态，寻找传统监控规则不易发现的异常。Anthropic并未因此取消常规告警，而是将代理作为额外的分析层。

从代码实现、性能优化到运行监控，Claude已深度参与了Scion的整个工程生命周期。

4 当代理持续写代码，连CI和代码合并规则都需重新设计

Scion解决了版本控制系统的扩展问题，但Anthropic发现，现有软件开发流程中还有很多环节建立在人类工程师的工作节奏之上。其中一个典型例子是合并队列。

传统合并队列通过协调代码进入主分支的顺序，尽量保证提交之间的兼容性，并在合并前执行测试。这种机制能降低并发修改带来的风险，但也会引入等待和协调成本。

当代码合并量达到每天数万次，问题就变得复杂起来。

一项测试还在运行时，主分支可能已合并了数百甚至数千次修改。测试结果对应的代码状态与当前主分支之间，可能已出现明显差异。若坚持让所有修改严格串行通过统一合并队列，吞吐量又会受到限制。

Anthropic表示，团队尚未找到一种有效方式，在这种规模下复现行业常见的全局仓库锁式合并队列。因此，他们将更多资源投入到合并后测试和部署前自动化测试中。

这意味着，一些并发修改之间的冲突可能在合并后才被发现。Anthropic认为，Claude通常能比人类工程师更快地修复这些冲突。

不过，这种方式也引出了新的工程问题。

当合并后的代码可能包含尚未发现的冲突，团队如何保证主分支的可用性？合并后测试与部署前测试之间应该如何分工？若多个代理持续修改同一批文件，又该如何控制故障传播范围？

Anthropic的文章没有完整披露这些问题的解决方案，也未给出新流程下的缺陷率、回滚率或生产事故数据。因此，目前可确定的是Anthropic已调整了代码集成与验证机制，但这种模式在质量和可靠性上是否全面优于传统流程暂无法确定。

尽管如此，这仍是一个值得关注的变化。过去，软件工程基础设施主要围绕开发者提交代码、执行测试、等待审查和合并的流程建设。随着代理承担越来越多实际开发工作，代码生成和提交可能成为持续运行的后台活动，版本控制、CI、代码审查及发布系统都需适应新的吞吐量和并发模式。

5 Git会被取代吗？Anthropic自己也不这么认为

看到Anthropic重造版本控制系统，很多人可能容易得出一个判断：编码代理时代，Git可能要被淘汰了。

但Anthropic并未做出这样的结论。

事实上，大型科技公司针对超大规模Monorepo开发专用版本控制系统，早已有先例。

Google使用内部集中式版本控制系统Piper，Meta则长期建设Sapling。Meta在2022年公开介绍Sapling时就指出，传统开源版本控制系统难以满足其拥有数千万文件和提交的超大仓库需求。Sapling通过专用服务器、虚拟文件系统和按需获取历史数据等机制解决扩展问题，同时保留了与Git仓库交互的能力。

Scion借鉴了这些系统的设计经验。Anthropic的特殊之处在于，代理带来的代码产出速度，让一个规模远小于Google、Meta传统工程组织的团队，也遇到了类似的基础设施压力。

但这并不意味着所有使用Claude Code或其他编码代理的开发团队都需要放弃Git。

Scion针对的是极其庞大的Monorepo、每天数千万次检出以及数万次代码合并的特殊场景。它还依赖一套专门开发的代码审查、代码搜索和CI基础设施。对于普通团队而言，迁移到Scion这样的系统，成本很可能远远超过收益。

Anthropic也明确表示，Scion不适合作为通用Git替代品，现阶段没有计划将其包装成供外部组织普遍使用的产品。

公司更希望通过公开架构经验，推动Git生态改进服务器端的扩展能力。例如，Git服务器未必需要完全复制客户端的工作方式；代码托管平台可提供更丰富的服务端API；稀疏检出、浅克隆和数据协商协议也存在进一步优化的空间。

这也解释了为何Anthropic选择公开技术设计，却没有直接开源Scion。

从目前披露的信息看，Scion是一套高度依赖Anthropic内部研发体系的基础设施。它的架构经验可能具有广泛参考价值，但完整系统未必适合其他公司直接采用。