代码合并量暴涨12倍 Anthropic自研Scion版本控制系统

短短四个月内，某科技公司的单体代码仓库代码合并量从日均2500次暴涨至超过3万次，增幅超12倍。这一增长的核心驱动力，正是其自研的AI编码代理Claude。

AI编码代理能够自主完成代码修改、测试执行、程序优化甚至服务构建，大幅提升了代码生产效率，但也让原有软件开发基础设施不堪重负。最先遭遇瓶颈的是版本控制工具Git。该公司的单体代码仓库主分支历史已接近100GB，压缩后的工作副本超25GB，仅持续集成系统每天就需执行约2500万次代码检出，若采用传统Git数据获取方式，每天可能产生超600PB的数据传输需求。即便此前已通过浅克隆、稀疏检出、内部镜像等多种手段优化，甚至维护数百台镜像服务器，仍无法应对持续增长的代码合并量。

于是，该公司做出了重新开发版本控制系统的决定。10月13日，官方工程博客披露，一个仅7人的团队耗时五个月，开发出名为Scion的新版本控制系统并完成整个单体代码仓库的迁移，同时还推出了配套的代码审查工具Antique、代码搜索系统、权限管理等基础设施。迁移后，Scion的基础设施CPU和内存占用降至原有Git镜像方案的约1/200，代码检出速度提高约两个数量级，仅持续集成环节就节省了约25%的CPU容量。

Scion的核心设计思路是将版本控制从以本地仓库为中心的模式转向始终在线的客户端-服务器架构。在Git中，客户端需独立完成提交、变基等操作再推送，而Scion将这些主要操作移至服务器端，客户端仅负责维护本地缓存和工作目录，无需下载大量无关数据。这一调整让版本控制能力可通过API直接提供给其他系统，例如持续集成任务可直接请求服务器获取提交差异，无需检出整个仓库。从架构上看，Scion让版本控制操作的成本更多取决于实际修改的数据量，而非整个仓库的规模。

为实现这一目标，Scion重新设计了底层数据结构。它采用名为变更集的记录，将其写入预写日志，每条变更集记录相对于第一个父提交发生变化的文件，以及指向压缩文件内容的内容寻址引用。文件内容保存在二进制大对象存储中，版本关系和元数据由后端系统管理，使用分布式数据库系统存储部分需协调的元数据，减少跨服务器同步。这种设计让提交快速创建和分发，避免了Git打包机制的部分开销。

值得注意的是，Claude既是基础设施压力的来源，也是系统改造的重要助力。Scion的开发过程中，Claude承担了大量代码实现与优化工作。官方案例显示，Scion早期的Git数据导入管线由工程师手写，性能已不错，但Claude重新实现后，内存消耗降低20倍，执行速度提高4倍，同时保留了原有的数据顺序和结构约束。Claude还被用于日常运维，团队创建了专门监控Scion各组件的代理，持续检查系统状态，作为传统监控的补充。

Scion解决了版本控制系统的扩展问题，但现有软件开发流程仍建立在人类工程师的工作节奏上，合并队列就是典型例子。传统合并队列通过协调代码进入主分支的顺序降低风险，但当代码合并量达每天数万次时，测试运行时主分支可能已合并数百次修改，若坚持串行通过统一队列，吞吐量会受限。目前该团队未找到适配超大规模的合并队列方案，转而将更多资源投入合并后测试和部署前自动化测试，这也带来了新的问题，如如何保证主分支可用性、测试分工、故障传播控制等，相关细节尚未完全披露。

看到该公司重造版本控制系统，有人可能认为AI编码代理时代Git会被淘汰，但实际并非如此。类似的超大规模仓库专用版本控制系统，如Google的Piper、Meta的Sapling早已存在，Scion借鉴了这些经验，其特殊之处在于AI代理带来的代码产出速度，让小团队也遇到了类似的基础设施压力。Scion针对的是单体代码仓库超大规模、高频检出和高合并量的特殊场景，依赖配套的代码审查、CI等基础设施，普通团队迁移成本可能超过收益，因此不会成为通用Git替代品。该公司希望通过公开架构经验推动Git生态优化，而非直接开源Scion。

Scion项目展示了AI编码代理带来的生产力提升与新工程成本，对于引入AI代理的团队，这是一个重要的案例：当代码编写不再是主要限制，相关流程需适应新的吞吐量和并发模式，这将成为新的工程挑战。