Anthropic 用 Scion 换掉 git 之后：智能体时代的版本控制该换吗
Anthropic 七人五个月把 monorepo 迁到自研 Scion，日合并量翻十二倍。拆解这套系统的取舍，并给普通团队一份先别急着换 Git 的判断框架。
2026 年 10 月 13 日，Anthropic 在工程博文《Redesigning source control at Anthropic》里确认：公司已用自研的版本控制系统 Scion 全面替换 git，整个 monorepo 的迁移由七名工程师在五个月内完成。直接动因是规模——日合并量从 5 月的约 2,500 次涨到 9 月的 30,000 次以上，CI 每天要执行约 2,500 万次代码签出，按博文的原话，git 成了「我们最大的开发瓶颈」。
这篇文章要回答的问题比「Scion 是什么」更实际：coding agent 把写代码的速度拉高一个数量级后，你的团队该跟着换版本控制系统吗？ 结论先放这里——对几乎所有团队，答案是否；但知道「否」的理由比知道 Anthropic 做了什么更有用。
要点
- Anthropic 的迁移由 7 人团队在 5 个月内完成，同期日合并量从约 2,500 次增至 30,000 次以上；CI 签出从分钟级降到秒级（官方称快约 100 倍），CI 因此释放约 25% 的 CPU 容量，基建足迹比原 git 镜像群缩小 200 倍。
- Scion 是在线、中心化的系统：写路径完全在服务端，提交单位叫 changeset 并直接落入预写日志，没有 push；读路径分开发机 daemon、区域缓存、权威服务器三级，每级缓存命中率都超过 99%。它明确不做开源，也不定位为通用 git 替代品。
- 与 Scion 同期建成的还有评审系统 Antique、代码搜索、按目录授权的 IAM、自动 bisect/revert 管道等约六个配套系统——Scion 是一次开发栈迁移，不是换一个 git 命令。
- 官方与社区的数字都没有第三方核实渠道；HN 上「git 是否真的到极限」「30k 合并量是否等于有效产出」的质疑同样成立。
先看瓶颈在哪
Anthropic 博文里最有信息量的不是架构图，是那张曲线：每一次 Claude 模型发布都标在时间轴上——2 月的 Opus 4.6、4 月的 Mythos Preview、9 月 1 日的 Fable 5.1 与 Mythos 5.1——曲线在每次发布后都更陡一层，9 月 9 日单日合并冲到 30,401 次。博文作者之一 Nick G. 在 Hacker News 上确认，把大块代码委托给 Claude 的能力在 Mythos Preview 上线后出现了「阶跃式」提升。
这条曲线该被怎么读，HN 上的讨论分成了两派，两派的意见都值得看。质疑派问：代码变更数量暴涨，等于软件变得更好吗？一条获得不少认同的评论说，「近 100 GB 的主分支历史很荒谬」，怀疑 Anthropic 把 git 历史当成了消息队列用；也有人追问需求变化为何加速、合并量能否无限增长。支持方的论证更工程化：Anthropic 的体量下，签出流量本身就是成本——按博文数据，若继续用原生 git，每日 CI 签出流量估算将超过 600 PB，这个数量级上「签出慢一分钟」等于每天烧掉几千机时。
对读者的启发是：合并量、签出量、仓库体积是三个独立的指标，要分开量。想看 git 侧的应对，alphaXiv 的 OpenResearch 把每个研究方向拆进独立 worktree。一个团队可以合并很少但仓库巨大（历史没清理），也可以合并很多但仓库很小（微服务加浅历史）。Anthropic 三者全中，这才是它必须动手的原因。
Scion 改了什么
Scion 的架构选择，用一句话概括是：放弃离线能力，把一切挪到服务端。理解这三个设计，就能理解它为什么不适合你。
写路径没有 push。 在 git 里，提交先发生在本地，push 才同步到远端；Scion 的提交单位叫 changeset，作为预写日志条目直接落库，创建 changeset 不需要移动任何引用——引用更新是对 Spanner 单行的比较交换，主分支与发布分支是少数保留的引用。这样设计的代价显而易见：没有本地历史，就没有离线提交；收益是「提交即全局可见」，且服务端成为唯一真相来源，合并冲突的裁决不必等各克隆点同步。
读路径三级缓存。 开发机上的 scion-daemon、区域 scion-cache、权威 scion-server，三者暴露同一套 RPC；客户端只请求它需要的树和 blob，内容寻址的对象不可变因而可缓存，官方称每级命中率都超过 99%。稀疏签出与虚拟化签出让文件按需物化——这解决了「为了改一个文件而签出 25 GB 工作副本」的问题。
为什么可以放弃离线。 Simon Willison 的独立分析引用了工程师的解释：Claude 是 Scion 迄今最重的用户，「而它必然在线」。这句话是整套设计的前提——Anthropic 的工作负载里没有「断网写代码」这个场景。你的团队大概率不是。
Simon 还把 Scion 读作「沿 Subversion 路线对中心化版本控制的再发明」，并指出其派生数据设计深受 Mononoke 影响——那是 Meta 的 Sapling 服务端组件。这个谱系很重要：Scion 不是第一个这么做的系统，Google 内部的 Piper 与 Meta 的 Sapling 都被官方列为参考。区别在于，前两者服务的是「数万人一个 monorepo」的规模，而 Scion 服务的是「数万个智能体会话一个 monorepo」——并发写作者的密度又上了一个量级。
| 维度 | 原生 git（ Anthropic 迁移前） | Scion |
|---|---|---|
| 提交模型 | 本地提交 + push 同步 | 服务端 changeset，无 push |
| 离线能力 | 完整 | 无（明确放弃） |
| 签出模型 | 全量或稀疏（cone 模式） | 稀疏/虚拟化，按需物化 |
| 冲突裁决 | 各克隆点协商 | 服务端单点权威 |
| 配套系统 | 自建（镜像群） | 同期建成（Antique 等六套） |
| 开源状态 | 开源生态 | 不开源，非通用替代品 |
Git 还没走到的中间路线
把 Anthropic 的选择理解成「git 不行了」是误读。git 官方文档里有两项能力，恰好对应 Scion 解决的两个问题，而且大多数团队从没用满。
partial clone（部分克隆） 针对的是仓库太大：clone 或 fetch 时用 --filter 让服务端省略不需要的树或 blob，缺失对象按需再取。文档同时说清了代价——它依赖网络与 promisor 远端，动态获取可能很慢（可能一次只取一个对象，走 protocol V0），取一个对象还会连带取它引用的对象。也就是说，partial clone 用「按需网络往返」换「本地磁盘与时间」，适合大仓库里的局部工作，不适合把整个 CI 农场建在它上面。
sparse-checkout（稀疏签出） 针对的是工作副本太大：cone 模式是默认推荐，指定目录后 Git 不再填充选区外的文件，但它们仍在版本控制内；稀疏索引能改善 status、add 这类命令的性能，但文档标注为实验特性。这正是 Scion「虚拟化签出」的 git 版对应物——区别是 Scion 把它做进了协议与服务端，而不是客户端选项。
社区路线里还有第三条：Meta 的 Sapling 可以当 git 前端用（克隆、推送、拉取仍走 git），也支持本地提交、修改与撤销；但官方文档明确说，支撑其千万级文件规模的服务端与虚拟文件系统「尚未公开」，且 git 兼容「可能还有一些待解决的毛边」。对想渐进采用中心化工作流的团队，这是比自研更现实的起点——Anthropic 自己也把 Piper 与 Sapling 列为参考，并向社区建议改进 git 服务端（服务端 diff/merge、更聪明的协议协商、组合稀疏与浅克隆），表示愿与 GitHub、GitLab 合作。
真正的成本：一整套开发栈
Scion 最容易被忽略的事实是：它从来不是一个人在战斗。博文列出与版本控制同期建成的还有带语义级审批约束和合并队列的评审系统 Antique、代码搜索、按目录授权的 IAM、自动 bisect/revert 管道等约六个配套系统。作者的观点很直接：别处采用这类系统，意味着要迁移整个开发生命周期——评审、搜索、CI 缺一环，新 VCS 就只是半成品。
这也是 HN 上「为什么不改进 git 而要重写」质疑的合理之处。一条高赞评论的算法是：从「原生 git」到「自研 VCS」之间有很多级——服务端镜像、partial clone、sparse checkout、Git LFS、monorepo 工具链——多数团队在第一级到第三级就能解决问题。反方同样有力：七个人五个月，在 Anthropic 的规模下可能确实比改造 git 生态便宜；而且这套系统的数据摄取管道本身就是交给 Claude Mythos Preview 重写的，官方称比工程师手写的原型省 20 倍内存、快 4 倍——用 Claude 造工具给 Claude 用，这个循环一旦转起来，「重写」的边际成本就在持续下降。
对读者而言，这两派争论指向同一个判断：「自研 vs 采用」的盈亏平衡点正在移动，但移动的方向因团队而异。有 agent 基础设施、能承受定制维护成本的团队，平衡点向「自研」偏；没有专职平台团队的小团队，反而更不该碰——你连 git 镜像都还没配满。
给普通团队的判断框架
如果 CI 日签出量已经上万，或者每次 clone 要以分钟计，按这个顺序做，多数团队在前两步就能止血：
- 先量，再改。 采集一周数据：CI 日签出次数、P95 签出耗时、签出传输量、镜像缓存命中率、CI CPU 消耗。没有这些数字，「git 慢」只是感觉。Anthropic 的决策建立在 600 PB/日这个可计算的事实上。
- 用满 git 现有能力。 sparse-checkout（cone 模式）收窄工作副本，partial clone 按需取 blob，CI 固定用浅克隆加镜像；历史膨胀就评估截断或迁移策略——HN 上「语义截断历史」的建议虽不礼貌，方向没错。
- 修配套，不只是 VCS。 签出慢经常不是 git 的错：CI 缓存策略、制品库位置、测试选择器（只跑受影响的测试）往往收益更大。
- 只有前三步都确认无解，才评估中心化 VCS。 此时按「要不要离线」「谁来维护」「迁移评审与 CI 的成本」三问筛候选；Sapling 这类兼容 git 的方案优先于自研。
- 别照搬 Anthropic 的时间表。 博文预计这类规模问题会在「未来六到十二个月」扩散到更多组织——但扩散的是「签出压力」这个问题，不是「自研 VCS」这个答案。
诚实的收尾：本文所有性能数字——100 倍签出加速、25% CPU 释放、200 倍足迹缩小——全部出自 Anthropic 自述，无第三方复测，Scion 不开源也无法外部验证。事件快讯见本站此前的 Anthropic 弃 git 换自研 Scion。它能证明「这套设计在 Anthropic 的规模上成立」，不能证明「它在你的规模上最优」。git 没有死；这只是智能体开发节奏倒逼的基础设施重估——写代码的边际成本趋零时，瓶颈沿流水线上移：先是评审，再是签出，下一个值得盯。