Anthropic 自研版本控制系统 Scion：日合并从 2500 飙到 3 万后，Git 撑不住了
Anthropic 于 10 月 13 日发文称，公司 monorepo 日合并量从 2026 年 5 月约 2500 次升至 9 月逾 3 万次，主要由 Claude 等智能体写代码驱动；七人团队用约五个月自研服务端优先的版本控制系统 Scion，并完成从 Git 的迁移。官方明确 Scion 不适合一般团队、暂不对外发布。
Anthropic 工程团队于 10 月 13 日发布长文《Redesigning source control at Anthropic》，说明公司已把 monorepo 从 Git 迁到自研版本控制系统 Scion。
核心数字来自官方：2026 年 5 月日均合并约 2500 次，到 9 月已超过 3 万次。文中写明，瓶颈已从「写代码」转到为人类规模设计的开发基建——版本控制、构建与 CI；Claude 能自主迭代研究循环、微优化复杂程序并从零搭服务，但仓库体量与检出频率让 Git 的离线、全量副本假设难以撑住。
按文章描述，主分支历史 alone 已近 100 GB，压缩工作副本逾 25 GB，CI 每天约有 2500 万次代码检出；若按朴素方式拉取，流量会夸张到不可运维。团队曾靠数百台内部 Git 镜像与快照续命，但合并速率继续升高后仍不够用。
Scion 的设计原则与 Git 形成对照：
- 客户端默认在线：面向智能体与作业，假设服务器随时可达，按需取数据，而不是每人一份完整仓库；
- 客户端—服务端不对称：提交、合并、rebase、历史与 blame 等在服务端完成，客户端主要做本地缓存与工作区布局；
- 工作副本可选、默认稀疏：许多 CI 与写入可通过 API 完成，不必整仓检出；稀疏与虚拟化检出只物化真正读到的路径；
- 变更以 changeset 为单位：相对第一父提交只记录改动文件，并配合可水平扩展的缓存与派生数据（blame、路径历史等）。
官方称，Scion 相关基础设施在 CPU/内存占用上约为原先 Git 镜像方案的 1/200，CI 与研究作业检出从分钟级降到秒级；七人团队还同期做了代码评审界面 Antique、代码搜索与权限体系，并在约五个月内完成迁移。文中举例：早期 Git→Scion 入库流水线经内部 Claude 快照重写后，内存降到约 1/20、速度约快 4 倍。
Anthropic 明确表示：Scion 绝非面向一般用途的 Git 替代品，也不打算以「讨好所有人」的形式对外发布；更希望把经验反馈给 Git 生态与 GitHub、GitLab 等平台，推动服务端 RPC、协商协议与稀疏/浅克隆能力演进。详情见 Anthropic 工程博客原文。
对创作者意味着什么： 若你用 AI 编程助手批量改仓库、开大量并行任务，会先撞上的往往不是模型本身，而是合并队列、CI 与仓库体积。多数个人项目和中小团队远不到 Anthropic 这个量级，不必急着换版本控制系统；更务实的是：给智能体划清可改目录与「完成」标准、避免它为过测试去改测试本身，并关注 Git 托管平台后续的服务端能力升级，而不是照搬一家实验室的内部基建。
信息来源：Anthropic 工程博客（本文为编辑整理改写）
