Anthropic 自研 Scion 版本控制系统，五个月迁完超大型单体仓库
七月 Entire 主张版本控制该为智能体重写，理由是 git 只记录最终文本，丢掉了代码产生的过程。三个月后，Anthropic 拿出了第一份工程实测。
他们的数字很直接。2026 年 5 月，公司每天合并约 2500 次代码变更；到 9 月，这个数字超过 3 万。写代码不再是瓶颈，瓶颈变成按人类规模设计的开发基础设施：源码管理、构建、CI。
git 的假设在这里失效。主分支历史接近 100 GB，压缩后的工作副本超过 25 GB，每天仅 CI 就触发约 2500 万次检出，朴素拉取一天要 600 PB 流量。峰值时他们维护着几百个内部 git 镜像，刷新越来越勤，镜像仍然追不上主干。
于是有了 Scion。它的核心判断是客户端永远在线——使用方几乎全是 agent 和作业，git 那套为离线分布式协作设计的完整副本反而拖慢速度。改动写进预写日志成为 changeset，服务端负责历史、blame、合并与 rebase，客户端只保留有界对象缓存。仓库数据分散存放，任何一层缓存的命中率都在 99% 以上。
结果是硬指标：Scion 的 CPU 和内存占用是旧镜像体系的 1/200，代码检出从分钟级降到秒级，光 CI 就省下 25% 的 CPU 容量。七个人的团队五个月里同时交付 Scion 和代码评审工具 Antique，期间合并量还涨了 10 倍。
有个细节值得单说。git 到 Scion 的导入管线最初是人手写的，他们拿到内部 Claude Mythos Preview 快照后让模型重写，没有额外提示，内存降 20 倍、速度快 4 倍，隐式不变量全部保住。但工程师没有被替代，工作变成了对 Claude 说“不”：挡掉为满足某种模式而违反系统约束的改动，也挡掉针对假想风险堆出来的过度防御。
HN 的讨论分成两路。一派追问：如果合并需求无限增长，仓库本身一直在流动，版本控制还有意义吗。另一条高赞评论则盯着闭源——Anthropic 五个月前也只有 2500 次日合并，自研工具却只留在内部。官方回应说 Scion 分歧太大，不适合做成通用产品，更愿意把思路公开，和 GitHub、GitLab 一起改 git 服务端。