今年 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 提供给其他系统。例如，CI 任务如果只需要计算某次提交与合并基点之间的差异，就可以直接请求服务器返回结果，不必先检出整个代码仓库。自动化回滚、定位问题提交等工具，也能够通过 API 查询版本历史。
从工程架构上看，Scion 试图让版本控制操作的成本更多取决于实际修改的数据量，而不是整个仓库的规模。
为了实现这一点，Scion 重新设计了底层数据结构。
在 Git 中，一个提交会引用对应的目录树。Scion 则采用名为 Changeset 的变更记录，将其写入预写日志（Write-Ahead Log）。每条 Changeset 记录相对于第一个父提交发生变化的文件，以及指向压缩文件内容的内容寻址引用。
Scion 中 Changeset（变更集）的数据结构
文件内容保存在 Blob Storage 中，版本关系和相关元数据由后端系统管理。Scion 使用 Spanner 存储部分需要协调的元数据，并尽可能减少创建提交时的跨服务器同步。
这种设计使提交能够快速创建和分发，也避免了 Git Packfile 机制带来的部分打包、协商和维护开销。
Scion 仍然支持类似 Git 分支和标签的引用（ref），但尽量减少对它们的依赖。Anthropic 认为，如果大量操作都需要更新全局共享状态，就容易重新引入协调瓶颈。因此，Scion 的常规提交创建不依赖移动 ref，只有主分支或发布分支等场景需要更新这些引用。
不过，把操作搬到服务器并不意味着问题自然解决。服务器需要同时承受大量 Agent 和 CI 任务的请求，如果所有客户端都直接访问中央存储，系统仍然可能被流量压垮。
Anthropic 因此设计了一套分层缓存架构。
Scion 的代码检出架构
在计算节点上，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 的架构设计反映了 Agent 规模化带来的系统变化，那么它的开发过程，则展示了 Coding Agent 对软件工程组织方式的另一种影响。
Anthropic 披露，Scion 和配套代码审查工具 Antique 由一个 7 人团队开发。团队在五个月内完成系统建设及整个 Monorepo 的迁移，同时还交付了代码搜索、权限管理等多个相关系统。
这个过程中，Claude 承担了大量代码实现与优化工作。
官方文章介绍了一个具体案例：Scion 早期的 Git 数据导入管线主要由工程师手写完成，团队原本认为性能已经不错。后来，他们让内部早期版本的 Claude Mythos Preview 重新实现整个管线。
在没有进一步指令的情况下，Claude 生成的新版本将内存消耗降低了 20 倍，执行速度提高了 4 倍，同时保留了原有的数据导入顺序和数据结构约束。
这个案例的意义在于，Agent 已经能够参与复杂基础设施的性能优化，而不只是完成局部函数、接口或业务代码的编写。
但 Anthropic 也强调，这并不意味着工程师的作用消失了。
团队成员认为 Claude 在代码编写方面已经超过了自己，但系统层面的设计决策仍然依赖工程师，包括理解不同组件之间的关系、判断架构取舍，以及决定哪些问题值得解决。
官方文章中有一个很有意思的细节：工程师的一项重要工作，是告诉 Claude“不要这样做”。
这与 Scion 项目的实际特点有关。高吞吐、低延迟、横向扩展、故障隔离和数据一致性之间存在大量取舍。某种实现即使代码质量很好，也未必符合系统长期运行的要求。工程师需要从整体架构和生产环境约束出发，决定哪些方案可以接受。
Claude 还被用于日常系统运维。Anthropic 团队创建了一批被称为“superfans”的 Claude Agent，分别关注 Scion 的不同组件。例如，一个 Agent 持续监控 scion-daemon，另一个关注 scion-cache，还有 Agent 专门观察 Antique 合并队列。
2026 年 1 月至 9 月，Scion 和 Antique 代码库每周合并的代码变更数量
这些 Agent 可以读取遥测数据和日志，持续检查系统状态，寻找传统监控规则不容易发现的异常。Anthropic 并没有因此取消常规告警，而是将 Agent 作为额外的分析层。
从代码实现、性能优化到运行监控，Claude 已经深度参与了 Scion 的整个工程生命周期。
4 当 Agent 持续写代码，连 CI 和代码合并规则都要重新设计 Scion 解决了版本控制系统的扩展问题，但 Anthropic 发现，现有软件开发流程中还有很多环节建立在人类工程师的工作节奏之上。其中一个典型例子是合并队列（Merge Queue）。
传统合并队列通过协调代码进入主分支的顺序，尽量保证提交之间的兼容性，并在合并前执行测试。这种机制能够降低并发修改带来的风险，但也会引入等待和协调成本。
当代码合并量达到每天数万次，问题就变得复杂起来。
一项测试还在运行时，主分支可能已经合并了数百甚至数千次修改。测试结果对应的代码状态与当前主分支之间，可能已经出现明显差异。如果坚持让所有修改严格串行通过统一合并队列，吞吐量又会受到限制。
Anthropic 表示，团队尚未找到一种有效方式，在这种规模下复现行业常见的全局仓库锁式合并队列。因此，他们将更多资源投入到合并后测试和部署前自动化测试中。
这意味着，一些并发修改之间的冲突可能在合并后才被发现。Anthropic 认为，Claude 通常能够比人类工程师更快地修复这些冲突。
不过，这种方式也引出了新的工程问题。
当合并后的代码可能包含尚未发现的冲突，团队如何保证主分支的可用性？合并后测试与部署前测试之间应该如何分工？如果多个 Agent 持续修改同一批文件，又该如何控制故障传播范围？
Anthropic 的文章没有完整披露这些问题的解决方案，也没有给出新流程下的缺陷率、回滚率或生产事故数据。因此，目前可以确定的是 Anthropic 已经调整了代码集成与验证机制，但这种模式在质量和可靠性上是否全面优于传统流程暂无法确定。
尽管如此，这仍然是一个值得关注的变化。过去，软件工程基础设施主要围绕开发者提交代码、执行测试、等待审查和合并的流程建设。随着 Agent 承担越来越多实际开发工作，代码生成和提交可能成为持续运行的后台活动，版本控制、CI、代码审查及发布系统都需要适应新的吞吐量和并发模式。
5 Git 会被取代吗？Anthropic 自己也不这么认为 看到 Anthropic 重造版本控制系统，很多人可能容易得出一个判断：Coding Agent 时代，Git 可能要被淘汰了。
但 Anthropic 并没有做出这样的结论。
事实上，大型科技公司针对超大规模 Monorepo 开发专用版本控制系统，早已有先例。
Google 使用内部集中式版本控制系统 Piper，Meta 则长期建设 Sapling。Meta 在 2022 年 公开介绍 Sapling 时就指出，传统开源版本控制系统难以满足其拥有数千万文件和提交的超大仓库需求。Sapling 通过专用服务器、虚拟文件系统和按需获取历史数据等机制解决扩展问题，同时保留了与 Git 仓库交互的能力。
Scion 借鉴了这些系统的设计经验。Anthropic 的特殊之处在于，Agent 带来的代码产出速度，让一个规模远小于 Google、Meta 传统工程组织的团队，也遇到了类似的基础设施压力。
但这并不意味着所有使用 Claude Code 或其他 Coding Agent 的开发团队都需要放弃 Git。
Scion 针对的是极其庞大的 Monorepo、每天数千万次检出以及数万次代码合并的特殊场景。它还依赖一套专门开发的代码审查、代码搜索和 CI 基础设施。对于普通团队而言，迁移到 Scion 这样的系统，成本很可能远远超过收益。
Anthropic 也明确表示，Scion 不适合作为通用 Git 替代品，现阶段没有计划将其包装成供外部组织普遍使用的产品。
公司更希望通过公开架构经验，推动 Git 生态改进服务器端的扩展能力。例如，Git 服务器未必需要完全复制客户端的工作方式；代码托管平台可以提供更丰富的服务端 API；稀疏检出、浅克隆和数据协商协议也存在进一步优化的空间。
这也解释了为什么 Anthropic 选择公开技术设计，却没有直接开源 Scion。
从目前披露的信息看，Scion 是一套高度依赖 Anthropic 内部研发体系的基础设施。它的架构经验可能具有广泛参考价值，但完整系统未必适合其他公司直接采用。
Scion 项目最有意思的地方，是它同时展示了 Coding Agent 带来的生产力提升和新的工程成本。
Claude 让 Anthropic 的代码合并量在几个月内增长了十多倍，迫使团队重新设计版本控制系统；而在新系统的开发过程中，Claude 又帮助一个 7 人团队完成了过去可能需要更长时间和更多工程师参与的基础设施改造。
这套系统已经在 Anthropic 内部运行，并取得了相当可观的性能收益。但它解决的是一个非常特殊的规模问题，距离成为行业通用方案还有很远。
对于更多正在引入 Coding Agent 的工程团队而言，Scion 提供了一个提前出现的案例：当代码编写速度不再是主要限制，版本控制、测试、代码审查和发布流程能否承受随之而来的变化，将成为新的工程挑战。
相关链接：
https://www.anthropic.com/engineering/redesigning-source-control
点击底部阅读原文访问 InfoQ 官网，获取更多精彩内容！
