Anthropic 自研的版本控制系统 Scion 于 2026 年 10 月 13 日在 Anthropic 工程博客中首次完整公开：这家公司已经用五个月时间，把自家单一代码仓库（monorepo）从 Git 整体迁移到了 Scion，连配套的代码审查工具 Antique、代码搜索和权限系统也一并自研上线。触发这件事的不是某个单点故障，而是一组失控的数字：2026 年 5 月 Anthropic 平均每天合并约 2500 次代码改动，到 9 月已经超过每天 3 万次。
Git 撑不住的，是智能体规模的流量
Anthropic 主分支的历史记录本身接近 100GB，压缩后的工作副本超过 25GB。仅 CI 每天就要做约 2500 万次代码检出，还不算开发环境、智能体沙盒和研究任务；如果按 Git 的常规方式拉取，相当于每天超过 600PB 的流量。此前的续命办法包括浅克隆、稀疏检出、内部镜像和对象存储里的仓库快照，全都用过，内部 Git 镜像一度开到几百台，但合并速率继续涨之后，快照离主分支尖端越来越远，依赖历史记录的 diff 和 blame 在部分克隆上也越来越难保住。Anthropic 的判断是：Git 为离线、去中心化设计的那套前提，在一个客户端几乎全是永远在线的智能体和任务的环境里，反而成了扩展的阻力。
Scion 的做法：把仓库搬回服务端
Scion 围绕几条与 Git 相反的原则设计。客户端默认永远在线，需要什么数据就向服务端现取；服务端负责回答历史与 blame 查询、创建提交、执行合并与变基，客户端只保留有界的本地对象缓存。工作副本变成可选项：很多 CI 任务要看两个提交之间的 diff，直接向服务端要结果即可，连检出都可以跳过；真正需要文件时也只做稀疏甚至虚拟化检出，按需物化。提交被设计得便宜、无锁且只与改动大小相关：Scion 的基本单位叫 changeset，只记录相对第一个父提交改动过的文件清单和内容寻址的文件指针，服务端即时生效，不需要打包、不需要推送。运行几个月后，Scion 的基础设施占用比原先的 Git 镜像体系小了约 200 倍，检出速度快了两个数量级，CI 一项就省出约 25% 的 CPU 容量。
工程师的新工作：对 Claude 说"不"
这篇工程复盘最值得其他团队看的部分，其实是人的角色变化。Scion 与 Antique 由 7 人小队在五个月内建成并完成迁移，同期日合并量涨了 10 倍；团队成员的自评是，Claude 写代码已经比他们快，但系统间的高层理解、设计取舍和规模判断仍由工程师供给。复盘里举的例子很具体：智能体为了满足某种模式，会去违反本不该被允许的系统约束，也曾有系统想用线性读取提交日志的笨办法查合并时间，而不是去问代码审查工具；对抗式审查有效，但有时会过度防御，诱导 Claude 给系统堆上过量校验。于是工程师现在审查的重点从逐行读代码，变成了审查每笔改动的意图对不对。这个细节比任何跑分都更能说明智能体编程进入深水区后的分工形态。
Anthropic 在文末把边界说得很清楚：Scion 不是给一般团队用的 Git 替代品，它只适用于几万名工程师或大批智能体高频写代码的超大仓库，而且 Anthropic 能为内部任务消耗的 token 量远超一般公司愿意花的水平，公开版本短期内也不会有。它选择把设计思路写出来，是预期未来 6 到 12 个月里更多重度使用 AI 编程的公司会撞上同一面墙：瓶颈从写代码转移到版本控制、构建和 CI 这类为人类规模设计的基础设施。对多数团队，眼下更现实的动作是先量一下自家仓库的检出与合并规模离拐点还有多远，而不是急着自研一套新系统。
