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

今年5月，Anthropic平均每天合并约2500次代码修改。到了9月，这个数字已经超过3万次。短短四个月，代码合并量增长了12倍以上。 这种增长很大程度上来自Claude。AI Coding Agent能够自主修改代码、执行测试、反复优化程序，甚至从零开始构建服务。代码生产速度上去了，原本服务于人类工程师的软件开发基础设施却逐渐跟不上。 最先出现严重瓶颈的是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完成系统改造的重要工具。 每天3万次代码合并，Git到底哪里扛不住了？ Git之所以成为软件开发行业的标准工具，很大程度上得益于其分布式设计。开发者可以在本地保存仓库历史、创建提交、比较差异，即使没有网络连接也能完成大部分操作。 对于绝大多数软件项目，这是一套非常成功的设计。但它也意味着，客户端需要具备相当完整的版本控制能力，并保存执行相关操作所需的仓库数据。 Anthropic面临的工作负载已经发生了明显变化。 首先，代码仓库本身越来越大。接近100GB的主分支历史和超过25GB的压缩工作副本，使得频繁创建开发环境、CI环境和Agent沙箱变得昂贵。其次，代码检出频率极高。每天约2500万次检出还没有计算开发者环境、Agent沙箱和研究任务产生的额外需求。 更关键的是，代码变化的速度远远超过了传统开发团队。Anthropic在官方文章中表示，每消除一个开发瓶颈，代码产出量就会进一步增加。开发基础设施需要持续应对这种增长。 为了维持Git的运行，Anthropic曾经部署数百台内部镜像服务器，并在对象存储中保存仓库快照。这些方案能够减少重复下载，但也引入了新的维护负担。镜像需要不断同步，快照很快落后于主分支，而在部分克隆环境中保持diff、blame等依赖历史信息的操作正常工作，也越来越复杂。 Anthropic由此重新审视了一个长期存在的设计假设：既然大多数代码操作都由始终联网的Agent和自动化任务完成，为什么每个客户端还需要像传统Git客户端一样，具备独立处理完整仓库历史的能力？ 这成为Scion设计的起点。 当然，超大规模Monorepo与Git之间的矛盾并不新鲜。Google很早就开发了内部集中式版本控制系统Piper，Meta也投入多年建设Sapling。Anthropic此次遇到的问题与这些大型科技公司有相似之处，但驱动力有所不同：过去主要是庞大的工程师组织和代码仓库规模，现在，大量并行工作的Coding Agent也开始产生类似压力。 Scion怎么设计？把版本控制的大部分工作搬到服务器 Scion最重要的设计变化，是将版本控制从以本地仓库为中心的工作方式，转向始终在线的客户端—服务器架构。 在Git中，客户端可以独立创建提交、执行变基、查询历史，再将修改推送到远端。Scion则把提交、合并、变基、历史查询等主要操作放到服务器端完成。客户端主要负责维护有限的本地缓存、管理工作目录，以及监控文件变化。 由于提交直接在服务器端创建，Scion不再需要传统Git工作流中的push步骤。客户端也无需下载大量与当前任务无关的仓库数据。 这一改变还让版本控制能力可以直接通过API提供给其他系统。例如，CI任务如果只需要计算某次提交与合并基点之间的差异，就可以直接请求服务器返回结果，不必先检出整个代码仓库。自动化回滚、定位问题提交等工具，也能够通过API查询版本历史。 从工程架构上看，Scion试图让版本控制操作的成本更多取决于实际修改的数据量，而不是整个仓库的规模。 为了实现这一点，Scion重新设计了底层数据结构。 在Git中，一个提交会引用对应的目录树。Scion则采用名为Changeset的变更记录，将其写入预写日志（Write-Ahead Log）。每条Changeset记录相对于第一个父提交发生变化的文件，以及指向压缩文件内容的内容寻址引用。 文件内容保存在Blob Storage中，版本关系和相关元数据由后端系统管理。Scion使用Spanner存储部分需要协调的元数据，并尽可能减少创建提交时的跨服务器同步。 这种设计使提交能够快速创建和分发，也避免了Git Packfile机制带来的部分打包、协商和维护开销。 Scion仍然支持类似Git分支和标签的引用（ref），但尽量减少对它们的依赖。Anthropic认为，如果大量操作都需要更新全局共享状态，就容易重新引入协调瓶颈。因此，Scion的常规提交创建不依赖移动ref，只有主分支或发布分支等场景需要更新这些引用。 不过，把操作搬到服务器并不意味着问题自然解决。服务器需要同时承受大量Agent和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倍。