Anthropic 把 Git 换了：日合并 3 万次，旧架构扛不住了

当一家公司的代码合并频率在四个月里涨了 12 倍，最先撑不住的往往不是人，是工具链。Anthropic 遇到的正是这个局面。

一分钟速览

• Anthropic 将单体代码仓库从 Git 迁移到自研的 Scion；
• 单日合并变更从 5 月的约 2500 个增长到 9 月的 3 万多个；
• CI 每天执行约 2500 万次检出，主干历史接近 100GB，压缩工作副本超过 25GB；
• Scion 把提交、合并、变基、历史与追溯查询全部放到服务端；
• 各层缓存命中率超过 99%，CPU 与内存基础设施占用约为原 Git 镜像的 1/200。

Git 是怎么被顶到墙角的

Git 是为人设计的分布式版本控制：每个人本地有一份完整历史，离线也能提交、比对、切分支。这套模型在人类开发者的节奏下近乎完美，但当提交者变成成千上万个 AI Agent，前提就变了。

Agent 不需要离线独立性，它们需要的是高频、并发、可编程的仓库操作。Anthropic 之前试过浅克隆、稀疏检出、Promisor Remote、仓库快照，甚至维护数百个 Git 镜像，但随着合并频率继续上升，这些补丁的运维复杂度呈指数增长。

Scion 改了哪三件事

第一，把计算搬到服务端。提交、合并、变基、历史查询、代码追溯都在服务器执行，客户端只保留容量受限的对象缓存，检出时按需实体化文件。工具甚至可以通过 API 查差异、做部分写入，完全不用检出代码。

第二，换掉数据模型。Scion 的变更集记录相对于第一个父变更集发生了哪些文件变化，并用内容寻址指针引用压缩后的 Blob。创建变更集和更新引用是分离的，因此接收变更集不需要跨服务器协调——这对多地域、高并发的场景至关重要。

第三，把派生数据做成可演进的服务端结构。历史记录和追溯查询依赖一种叫派生数据的附加结构，按父变更集递归计算，可以预生成也可以按需生成。因为实现在服务端，改算法不用动客户端。

缓存是全部的秘密

检出时，客户端直接向服务端请求缺失的不可变树和 Blob，不再协商生成自定义 Packfile。节点本地守护进程在不同任务间共享缓存，区域缓存再从权威服务器取数，底层由 Spanner 和云存储支撑。区域缓存直接以守护进程的存储格式流式传输对象，省掉了每次请求的增量压缩。

结果是每一层缓存命中率都超过 99%，CI 与研究任务的检出速度提升两个数量级。这个数字不是通用基准，是 Anthropic 按自家负载测出来的，但方向足够明确。

别急着照搬

Anthropic 自己提醒：Scion 不是通用 Git 替代品。它依赖配套的代码审查、代码搜索和 CI 系统，而这些在 Anthropic 内部都是高度定制的。对多数团队来说，可借鉴的是设计思路——把重计算放到服务端、用不可变对象和分层缓存减少重复工作——而不是直接换掉 Git。

但这件事的信号意义很强：当 AI 开始大规模写代码，研发基础设施的设计前提正在被重写。版本控制、CI、代码审查，这些用了二十年的东西，可能要为新物种让路了。