2026 年 5 月，Anthropic 的 monorepo 平均每天合并约 2,500 次代码变更；到 9 月，这个数字超过 30,000，其中 9 月 9 日单日合并 30,401 次。增长来自 Claude：agent 自主迭代研究循环、微优化程序、从零搭建服务，代码产出的速度先超过了构建和 CI，如今轮到了源码管理。Anthropic 的解法是在五个月内自研一套版本控制系统 Scion，把整个 monorepo 从 git 完整迁移过去，配套重写了代码评审、代码搜索和一套细粒度权限系统。10 月 13 日，工程团队发文复盘了这次重构的全部细节。
git 卡在了设计假设上
先看规模。Anthropic 主分支的历史数据接近 100 GB，一份压缩后的工作副本超过 25 GB。CI 每天执行约 2,500 万次代码检出，这还不算开发环境、agent 沙箱和研究任务。如果每次检出都按 git 的方式完整拉取，每天会产生超过 600 PB 的传输量。
git 的应对手段一直存在：shallow clone、sparse checkout、promisor remote，再加上大厂常见内部镜像和放在对象存储里的仓库种子快照。Anthropic 全用过，峰值时期维护着数百个内部 git 镜像。这些补丁争取了时间，但随合并量上涨越来越难维护：种子在两次刷新之间落后 main 越来越远，diff 和 blame 这类依赖完整历史的操作在部分克隆上需要越来越多的照顾。
团队复盘时点出了关键矛盾：git 是为分布式离线协作设计的，每个克隆都是自包含的完整仓库；而 Anthropic 的实际使用方式是中心化的一份权威副本，客户端几乎全部是永远在线的 agent 和 CI 任务。git 最有价值的那些特性，在这个工作负载下反而成了扩展的阻碍。针对 HN 上「合并量是不是 agent 拿仓库历史当消息队列刷出来的」的质疑，源码控制团队在讨论串中回应：他们不允许 agent 用源码管理做协调，增长来自真实的代码写入。
六条设计原则
Scion 没有走「再修一版 git」的路线，而是按 agent 时代的工作负载重新立项。Google 的 Piper 和 Meta 的 Sapling 证明了超大规模 monorepo 可以脱离 git 模型，Scion 站在这两个前例的经验上，原则更进一步：
- 客户端永远在线。 不为离线工作设计，客户端按需向服务器取数据。
- 客户端-服务器不对称。 历史查询、blame、提交、合并、rebase 全部在服务器完成；客户端只维护有界的本地对象缓存、在磁盘上摆放工作副本文件、监视文件系统变化。它自己几乎不做计算，换来的是本地数据量的大幅下降。
- 源码管理即服务。 客户端能问的所有问题都通过 API 暴露，CI 任务和内部工具（自动 bisect、自动 revert 流水线）不需要本地仓库就能工作。
- 一切水平可扩展。 仓库数据分布存储，任何地方都不存在全量副本，服务器端也没有 packfile 对应物，因此不需要仓库维护。
- 提交必须廉价、增量、无锁。 每次提交、rebase、合并都发生在服务器端，没有 push 这个动作；这些操作的成本必须随变更规模而非仓库规模增长。分支和标签被刻意弱化，只保留 main 和发布分支，因为全局一致状态是扩展性的隐患。
- 工作副本可选，天然稀疏。 协议围绕 sparse checkout 和按需物化的 virtualized checkout 构建，CI 拿 diff、工具做查询这类工作负载可以完全不检出文件。
Changeset：写路径的重新设计
Scion 的基本工作单元叫 changeset，本质是写前日志（WAL）里的一条记录。它保存了 git 提交的大部分信息，但有一个关键区别：git 提交存储指向完整目录树的指针，changeset 存储的是相对第一个父级的变更文件列表，外加指向对象存储中压缩文件内容的内容寻址指针。changeset 在服务器端创建，创建后即刻全局可见。
这个结构让写入通道可以跑到很高的吞吐：没有 packfile 需要接收，没有锁，没有跨服务器协调，也没有需要移动的引用。Scion 技术上支持引用，但移动一个引用只是对 Spanner 单行的 compare-and-swap，与 changeset 的创建完全解耦。
changeset 只记录变更，所以它本身回答不了「这一行最后是谁改的」这类问题。Scion 用统一的「派生数据」机制补齐：blame、路径历史、提交图的 skip list 都是递归定义的——每种数据在某个 changeset 上的值，由其父级上的值计算得出。派生数据有三个好处：新增一种索引不需要改客户端；每种类别可以选择急切计算或按需延迟，避免物化没人用的数据；内部结构对客户端不可见，可以随时重写优化。团队在系统成长过程中多次追加派生数据，例如用于拷贝检测和按路径搜索文件的新索引。
读取路径：三层缓存架构
写路径解决了提交吞吐，读取路径的挑战是每天数千万次检出。Scion 的客户端 scn 在协商协议上与 git 分道扬镳：git 告诉服务器客户端已有什么，scn 只谈客户端想要什么。从根目录树开始，客户端检查本地缺失哪些树对象并递归请求，然后对 blob 重复同样的过程。每个请求都指向一个内容寻址、永不变更的对象，因此任何缓存都能应答，架构形态接近传统的分层缓存，也没有动辄数 GB 的打包响应，中断后可以续传。sparse 和 virtualized checkout 不需要任何特殊支持：客户端不请求不要的树，天然就是稀疏的。
部署形态分三层。每个节点跑一个 scion-daemon，为整台机器上的任务缓存对象，从定期刷新的快照引导；daemon 之上是区域的 scion-cache，直接从内存以磁盘格式流式输出对象，不做缺失对象计算，也不做增量压缩；缓存未命中时才请求权威的 scion-server，由它读取 Spanner 或云存储。三层组件响应完全相同的 RPC，客户端不需要知道缓存拓扑，但系统严格强制分层，为的是隔离故障域，避免一个区域缓存故障压垮上游。
这套架构的实测结果：每一层的缓存命中率都超过 99%；基础设施在 CPU 和内存上的占用是此前 git 镜像体系的 1/200；CI 和研究任务的代码检出快了两个数量级（分钟级降到秒级），仅 CI 一项就释放了 25% 的 CPU 容量；客户端和缓存都不再需要仓库维护。
性能对比：中位延迟全面下降
官方给出了迁移后原生 Scion 仓库上的日常操作中位延迟对比（git 对 scn 客户端）：
| 操作 | git | scn | 提升 |
|---|---|---|---|
| 拉取最新代码（开发者环境） | 87 s | 3.5 s | ×25 |
| status（开发者环境） | 3.9 s | 19 ms | ×207 |
| 创建新 worktree（agent 环境） | 7.1 min | 5.1 s | ×84 |
| agent 单次变更请求的源码管理总耗时 | 34 min | 3.7 min | ×9.2 |
| 计算任务开头的检出 | 175 s | 22 s | ×8.0 |
| CI 任务内的检出 | 31 s | 3.5 s | ×8.8 |
几组数字的含义需要放大看。status 从 3.9 秒到 19 毫秒，意味着 agent 在循环里可以随时查询仓库状态而不用把它写进成本预算。agent 单次变更请求的源码管理总耗时从 34 分钟降到 3.7 分钟，官方折算相当于每天省回约 11,000 个 agent 小时。两类 CI 检出分别对应每天约 85,000 和 195,000 个机器小时的节省。对以 token 和时钟计费的 agent 工作负载来说，这部分是直接的成本下降。
用 Claude 构建，为 Claude 构建
Scion 的开发时间线与 Claude Mythos Preview 和 Claude Tag 在内部可用的时间线重合，这两个版本既放大了构建 Scion 的必要性，也直接参与了构建。一个被官方反复引用的例子：年初手写的 git 到 Scion 迁移管道原型被团队认为已经够好，直到他们把 Claude Mythos Preview 的早期内部快照接上去，要求它重写整个管道。没有任何额外指令的情况下，重写版本内存占用降到原来的 1/20，速度提升 4 倍，同时保留了迁移顺序和数据结构方面的全部隐式不变量。这条管道在 git 与 Scion 并行的几个月里持续运行，性能收益是实打实的。
七个人的团队，五个月，交付了 Scion、代码评审工具 Antique、半打配套系统，并完成了全量迁移，同期日合并量还涨了 10 倍。按团队的说法，这种规模的迁移放在过去需要更多工程师和数年的迭代。组织方式也随之变化：工程师仍然评审每一次变更请求，但看的是变更的意图而非逐行代码；系统约束被 agent 破坏时由人踩刹车，例如多个系统试图用线性遍历提交日志的方式查询变更合并时间，而不是去问评审工具；对抗式评审有效但近视，曾让 Claude 为假想的威胁场景加进过多校验，也需要人来收敛。运维侧，团队给每个组件配了一个常驻 Slack 频道里的「superfan」Claude，盯着遥测和日志找异常，能发现传统告警覆盖不到的隐蔽问题。
流程层面的重新审视更彻底。merge queue 在 agent 规模下失去了意义：测试运行期间可能已有成百上千次变更合并，全局仓库锁又无法有效复制，团队把重心转向合并后和部署前的自动化测试。并发变更会冲突，但冲突由 Claude 修复，速度通常快于人类识别出冲突的速度。
边界：Scion 无意成为 git 的替代品
官方在文末把边界划得很清楚。Scion 只在真正巨大的 monorepo 上成立：数万工程师，或者蜂群般高产的 agent。Anthropic 内部 token 消耗的规模也远超其他公司愿意支付的水平，这既是开发需要，也是对 Claude 能力的测试。Diff 所以没有开源、也没有产品化计划：Scion 与 git 分歧太大，采用它意味着重写代码评审、搜索、CI 整个生命周期，而这些内部组件高度定制，做成公共服务试图满足所有人反而做不好。
团队预期这类问题在未来六到十二个月会变得常见，并给出了不离开 git 也能借鉴的方向：git 服务器不必复制客户端的工作方式，服务端可以用全新的架构承接扩展需求；托管平台可以提供全面的源码管理服务端 RPC，甚至跨平台标准化；fetch 协商协议有重新设计的空间；sparse 和 shallow 特性可以做得彼此组合良好。文末致谢段落把分寸感放在了正确的地方：git 社区为亿级开发者扩展这个平台花了近二十年，Anthropic 的贡献只是提供一份关于 agent 软件开发如何与这些系统交互的早期观察。
对普通开发团队来说，Scion 今天不构成任何迁移理由。它的真正信号在于：当写代码的成本曲线被 AI 压到足够陡，瓶颈会沿着工具链逐级上移，而每一环的基础设施假设都值得重新检查一遍。