Anthropic 用 7 人 5 个月打造 Git 替代品 Scion

Anthropic 做了一件在传统工程直觉里不太合理的事：用 7 名工程师、5 个月时间，从零开发出内部源代码控制系统 Scion 和配套代码审查工具 Antique，并把整个单体代码仓库从 Git 完整迁移过去。这个团队规模和时间窗口，放在过去通常只够完成一套版本控制系统的早期原型。

驱动力不是技术理想，而是负载。Anthropic 公布的数据显示，其平均每天合并的代码变更从今年 5 月的约 2500 次增长到 9 月的超过 3 万次，4 个月内增长 12 倍以上，并且预计这种增长短期内不会放缓。代码合并的潜在需求几乎没有上限——每当解决一个瓶颈，代码产出量就会进一步增加。

Anthropic 自己判断，短期内不会有太多公司遇到同样的 AI 编程规模瓶颈，但预计其他公司不久后也会碰到类似问题。这也是他们决定公开 Scion 设计和开发经验的原因。换句话说，这套系统更像是一个提前到达的样本，而不是所有团队当下必须复制的方案。

Git 是去中心化系统，每次克隆都得到一份完整、独立的代码仓库，即使完全离线也能计算差异、查看历史、追踪某一行代码的修改记录、检出任意版本。对绝大多数仓库来说，这套设计非常合理，也是 Git 成为行业标准的重要原因。但 Anthropic 的仓库规模已经越过了这个设计的舒适区。

具体数字是：仅主分支的历史数据就接近 100GB，压缩后的工作副本超过 25GB。仅 CI 系统每天就要执行约 2500 万次代码检出，还没有算上开发环境、Agent 沙箱和研究任务。如果每次都直接从 Git 获取所需数据，每天产生的数据传输量将超过 600PB。

Anthropic 并非没有尝试过常规方案。他们用过浅克隆、稀疏检出、Promisor Remote，也搭建过内部 Git 镜像，把仓库快照保存在对象存储中。在负载最高的时候，他们运行着几百台内部 Git 镜像服务器。这些方案确实撑了一段时间，但随着合并量增长越来越难维护：两次快照刷新之间，快照与主分支最新版本的差距会越来越大；要让部分克隆的仓库正常执行 diff、blame 等依赖历史信息的操作，维护投入也越来越高。

Anthropic 重新审视使用方式后发现，他们实际上一直把 Git 当作集中式系统使用，所有开发工作都围绕一份权威仓库展开，而客户端几乎都是 Agent 和自动化任务，本来就始终在线。Git 为分布式和离线开发提供的那些特性，反而在仓库不断增长时限制了扩展能力。