Anthropic 七人团队五个月换掉 git，日均合并冲上三万次

压垮 git 的不是人，是 agent

博文给出的起点数字很直接：今年 5 月，Anthropic 主仓库每天合入约 2500 次变更；到 9 月，这个数字超过 3 万次，四个月涨了十倍有余。按 Anthropic 的说法，这些代码大部分由 Claude 编写，源码管理随之成了全公司最大的开发瓶颈。

仓库本身的体量也早已越过 git 的舒适区：主干历史约 100 GB，压缩后的工作副本超过 25 GB，CI 每天要做约 2500 万次检出。博文估算，如果这些检出都老老实实走 git 拉取，流量会超过每天 600 PB。此前团队靠数百个内部 git 镜像、浅克隆、稀疏检出、partial clone，以及存在对象存储里的仓库快照硬撑，合并越快，这些快照和主干的偏差越大，diff、blame 之类的操作也越来越难维护。

真正的矛盾在设计哲学上。git 生来是为分布式、可离线的人类开发者准备的，每个客户端都揣着一份完整历史；而 Anthropic 如今的“客户端”几乎全是常驻在线的 agent 和 CI 任务，离线能力对它们毫无价值，反倒成了扩展的负担。

把重活全部搬回服务端

Scion 的思路可以概括为一句话：客户端只拿自己需要的那一点，其余全交给服务器。具体来看：

• 历史查询、blame、创建提交、合并与 rebase 都在服务端完成，成本与变更大小相关，而不是与仓库总大小相关；
• 基本存储单位是 changeset，只记录相对父提交变化的文件，文件内容以内容寻址方式存进对象存储；引用更新则是 Spanner 上单行的比较并交换操作，分支只保留 main 和发布分支；
• 缓存分三层：每个节点一个 scion-daemon、区域级的 scion-cache、权威的 scion-server，接口一致但故障域隔离，博文称每层缓存命中率都在 99% 以上；
• 拉取协议反过来设计：客户端不再向服务端申报“我有什么”，而是从根树开始按需递归请求缺失的对象，没有大 packfile，天然支持断点续传和稀疏、虚拟化检出。

这样做的直接结果，就是 TG 消息里那几组数字：基础设施 CPU 和内存占用缩小约 200 倍，CI 与研究任务的检出快了两个数量级，CI CPU 容量省下约 25%。很多 CI 任务甚至不再需要本地仓库，自动二分定位、自动回滚这类流水线直接调 API 就能完成。

七个人怎么在五个月里做完

同一时间段里，这个 7 人团队还上线了代码审查工具 Antique、代码搜索、源码权限系统等约六个配套系统。博文没有回避其中的取舍：代码大多由 Claude 写，工程师的主要工作变成判断设计与约束，而且“经常需要对 Claude 说不”。

文中举的反面例子相当具体：Claude 习惯线性扫描提交日志，而不是去查代码审查系统；对外部服务过度防御，把校验逻辑写得过于复杂；做对抗性审查时又容易为假设性风险过度设计。团队仍然审每一个变更请求，只是重点从逐行读代码转向审查意图。另一面，Claude 也找到过算法层面的优化，比如一个漏掉索引的祖先查询；团队还专门养了几个盯着各组件遥测数据的“超级粉丝”Claude 实例，持续巡检异常。

合并流程同样被迫改写。博文提到，在这种规模的 agent 并发合并下，传统的全局合并队列锁已经不现实，团队转而依赖合入后测试和部署前测试，冲突则交给 Claude 去修。

不开源，但话是说给 GitHub 听的

Scion 不会开源。Anthropic 明确表示它不适合作为通用的 git 替代品，内部组件高度定制，难以剥离出通用版本；发文的目的是分享思路，希望 GitHub、GitLab 和开源社区把服务端 RPC、更灵活的协商协议、更好用的稀疏与浅克隆等理念带回 git 生态。

回头看，这篇博文的分量不在于“又一家大厂自研版本控制”。Google 有 Piper、Meta 有 Sapling，巨型单仓库自研工具并不新鲜；新鲜的是驱动力。前人是被几万名工程师的规模逼出来的，Anthropic 只有一支小团队，却被 agent 的产出速度在几个月内逼到同样的墙前。如果日均三万次合并会变成更多公司的常态，git 那套“人人一份完整副本”的前提，可能是下一个要被重新讨论的东西。