在Anthropic，编码不再是构建系统或进行研究的瓶颈。Claude能够自主迭代研究循环，微优化复杂程序，并从零开始构建新服务，速度和规模都达到了前所未见的水平。现在的瓶颈是为了满足人类规模而建立的所有开发者基础设施：源代码控制、构建和持续集成。到2026年5月，Anthropic每天平均合并约2500个代码变更；截至9月，我们每天合并超过30000个代码变更。我们并不期待这种增长速度在近期内会放缓；合并代码的潜在需求几乎是无限的，我们移除的每个瓶颈都会立即导致我们产生的代码量进一步增加。从2026年1月到9月，我们每天合并到单一代码库的变更数量。为了支持这种增长，我们构建了Scion，一个内部版本控制系统，并在五个月内将我们的单一代码库从git完全迁移过来。我们还在同一时期内构建并推出了代码审查界面（名为Antique）、代码搜索、丰富的源代码控制IAM系统、管理和处理大量审核代码的新方法，等等。在这篇文章中，我们将重点介绍我们是如何构建Scion的。它是一个有趣的案例研究：Claude的编码能力既是我们最初进入这种情况的原因，也是我们能够迅速构建高质量、可扩展系统以应对这种情况的原因。扩大我们的单一代码库在我们探索所构建内容之前，我们应该承认我们的工作负载有多么不寻常。不出所料，Anthropic使用Claude编写软件的频率远超过几乎所有其他公司，因此我们经常是第一个看到为人类规模构建的工具开始出现压力的地方。源代码控制就是一个例子。虽然我们并不期待许多组织在短期内会遇到这些问题，但我们怀疑在不久的将来，使用AI编码工具的其他组织也会经历这些相同的压力点，这就是我们希望分享我们所构建的内容和我们所学到的原因。Git是一个去中心化的系统：每个克隆都是一个完整的、自包含的代码库，可以计算差异、读取历史记录和责任，并在完全离线的状态下检查任何版本。对于绝大多数代码库来说，这种设计是正确的，这也是git成为标准的一个重要原因。随着我们的单一代码库的增长，它越来越多地不适合这一设计空间。我们主分支的历史记录几乎达到100GB，压缩后的工作副本超过25GB。我们每天进行约2500万次代码检出用于持续集成，还没有计算开发者环境、代理沙箱和研究工作。如果天真地计算，这将超过600PB的git流量每天。Git提供了处理代码库切片的工具，比如浅克隆、稀疏检出和承诺远程仓库。除此之外，还有针对大型单一代码库的标准变通办法，比如在blob存储中保持的内部git镜像和代码库快照（种子）。我们使用过所有这些方法——在我们的高峰时期，我们操作了几百个内部git镜像来应对负载。这为我们赢得了时间，但随着我们的合并速率增加，它们变得越来越难以操作。种子在更新之间距离主分支的顶端越来越远，并且保持依赖历史记录的操作（如差异和责任）在部分克隆上正常工作变得越来越困难。为扩展git检出设计的典型设置。退一步来看，我们注意到，像大多数公司一样，我们将git作为一个集中式系统使用，拥有一个权威的副本，但几乎所有的客户端都是在线的代理和工作。使git在分布式、离线工作中表现出色的特性实际上削弱了我们在代码库扩展时的能力。因此，我们问自己：如果我们从一开始就考虑到代理始终在线的事实来设计源代码控制，它会是什么样子？代理规模源代码控制的原则通过代理编程，关于软件开发的许多常见假设正在演变。我们在构建Scion时采纳了这些变化，这使我们能够在多个核心原则上采取与git根本不同的方法。针对大型单一代码库的源代码控制有先例，特别是Google的Piper和Meta的Sapling，因此我们能够结合他们辛苦获得的经验教训来构建Scion。我们的原则是：客户端始终在线。Git假设客户端在离线工作，并需要代码库的完整副本。由于我们几乎所有的客户端都是代理和工作，我们围绕一个始终可达的服务器设计了Scion的客户端和协议，并让客户端在需要时获取数据。客户端-服务器不对称。在git中，每个客户端都能够成为一个完整的服务器。在Scion中，服务器回答关于文件历史和责任的问题，创建提交，执行合并和变基，等等。客户端维护一个有限的本地对象缓存，在磁盘上布局工作副本文件，监控文件系统的变化，并为用户提供相应的反馈。