Anthropic 工程团队用了 5 个月，把内部 monorepo 从 Git 迁移到自研版本控制系统 Scion
这也给了 AI 团队一份 “AI Agent 规模化的软件开发” 的一手实验报告：当写代码的瓶颈消失后，整个开发基础设施被重新审视了一遍！
报告地址：
https://www.anthropic.com/engineering/redesigning-source-control
为什么 Git 不适合了？
Claude 驱动的编码让合并量从 5 月的 2500 次/天暴涨到 9 月的 30000+ 次/天。主分支历史约 100 GB，工作副本压缩后 25 GB+，仅 CI 每天就要做约 2500 万次 checkout；如果老老实实按 Git 协议拉取，理论流量超过 600 PB/天。浅克隆、稀疏检出、promisor remotes、几百个内部镜像、blob 存储种子.. 这些补丁只是延缓了崩溃：种子与最新提交漂移，diff/blame 等历史操作逐步失效。
核心洞察：他们其实从来不需要“分布式”
Anthropic 实际上把 Git 当中心化系统在用：客户端（智能体、CI 任务）永远在线。Git 为离线/分布式场景设计的那些能力（本地完整历史、复杂的协商协议、packfile）在这里全部是负债而非资产。Scion 的全部设计都建立在一个反 Git 默认值的假设上：客户端永远在线。
由此推出六条原则：客户端按需拉取；客户端-服务器严格不对称（服务器管历史/blame/合并/rebase，客户端只做有界缓存和文件布局）；整个源控制系统即 API（CI 和工具常直接走 RPC，连本地仓库都不建）；全面水平扩展（任何地方都不物化完整仓库）；提交廉价、增量、无锁（正常流程中甚至不碰 ref）；工作副本默认稀疏、按需虚拟化。
技术方案的两根支柱
1. Changeset 取代 commit。 Git commit 指向完整 tree；Scion 的 changeset 则是写前日志（write-ahead log）中的一条记录，只存相对于第一父节点的变更文件列表加上指向 blob 存储的内容寻址指针。这个设计让提交成本只随变更大小扩展，与仓库规模无关；没有 packfile、没有锁、没有跨服务器协调。ref 仍然存在但被淡化：移动 ref 只是 Spanner 里一行的 compare-and-swap，与 changeset 创建完全解耦。脚注里说明“只记第一父节点”是有意取舍；trunk-based 开发下人们主要关心主线历史。
2. 递归式的派生数据（derived data）。 blame、路径历史、提交图上的跳表，全部用同一个通用递归机制计算：每个 changeset 的值由其父节点的值派生。这带来三个好处：新增派生类型（如复制检测、路径搜索）成本极低；每种类型可独立选择立即算还是惰性算；内部结构对客户端完全透明，可以随时重写优化。
分层缓存架构
客户端 scn 的协商协议与 Git 完全不同：不声明“我有什么”，而从根开始递归请求缺失的 tree，再请求 blob。每个请求都是不可变的内容寻址对象，任何一层缓存都能服务，天然可续传、无 packfile。三层结构：每节点的 scion-daemon → 区域级 scion-cache（直接以客户端磁盘格式从内存流式发送）→ 权威的 scion-servers（读 Spanner/云存储），响应同一套 RPC，但层级间严格隔离故障域。效果：每层缓存命中率超 99%，基础设施 CPU/内存占用缩小 200 倍，checkout 从分钟级降到秒级（约 100 倍），CI 释放出 25% 的 CPU。
更值得思考的部分：工程文化的变化
· 7 名工程师 5 个月建成 Scion + 代码审查工具 Antique + IAM、代码搜索等半打系统，且是在合并量 10 倍增长期间完成的迁移。
· 团队每个工程师都承认 Claude 写代码比自己强，但人提供系统级判断。核心工作之一是对 Claude 说“不”，比如阻止智能体为了合并期查询去暴力线性扫描提交日志。
· 对抗式审查会导致智能体为假想的质疑过度设计（某次审查不信任一个内部服务，Claude 就往上堆过量校验），需要人把方向拉回来。人的审查也从逐行阅读转向审查变更的意图。
· 弃用了合并队列的全局仓库锁（在智能体规模下无法复制）转向合并后/部署前测试，接受冲突发生，因为"Claude 解决冲突的速度比人类发现冲突还快"。
· 运维上出现了 "superfan"：每个组件配一个驻守 Slack 频道、盯着遥测和日志的 Claude 智能体，能发现让传统告警“显得一维”的细微新问题。
· 还有一句很现实的提醒：内部 token 花费“远超任何其他企业现实上愿意花的水平”。
定位与生态启示
Anthropic 明确说 Scion 不是给一般场景用的 Git 替代品，它只对超大规模 monorepo + 海量智能体吞吐有意义，而且必须配套自研的审查/搜索/CI。他们预测这类问题 6–12 个月内会在全行业蔓延，因此选择开源思路而非产品：最有号召力的一句话是 "Git 服务器不必和 Git 客户端一样工作"，forge 完全可以在不放弃 Git 模型的前提下采用全新的服务端架构、暴露标准化的服务端 RPC、改进协商协议、让 sparse/shallow 特性可组合。他们表示要和 GitHub、GitLab 及开源社区合作。