作者 ｜ 蔡芳芳 今年 5 月，Anthropic 平均每天合并约 2500 次代码修改。到了 9 月，这个数字已经超过 3 万次。短短四个月，代码合并量增长了 12 倍以上 2026 年 1 月至 9 月，Anthropic 单体代码仓库（Monorepo）每天合并的代码变更数量 这种增长很大程度上来自 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 完成系统改造的重要工具。 1 每天 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 也开始产生类似压力。 2 Scion 怎么设计？把版本控制的大部分工作搬到服务器 Scion 最重要的设计变化，是将版本控制从以本地仓库为中心的工作方式，转向始终在线的客户端—服务器架构。 在 Git 中，客户端可以独立创建提交、执行变基、查询历史，再将修改推送到远端。Scion 则把提交、合并、变基、历史查询等主要操作放到服务器端完成。客户端主要负责维护有限的本地缓存、管理工作目录，以及监控文件变化。 由于提交直接在服务器端创建，Scion 不再需要传统 Git 工作流中的 push 步骤。客户端也无需下载大量与当前任务无关的仓库数据。 这一改变还让版本控制能力可以直接通过 API 提供给其他系统。