# Anthropic 自研版本控制 Scion

![](https://leafw-blog-pic.oss-cn-hangzhou.aliyuncs.com/scion-cover.png)

2026 年 10 月 13 日，Anthropic 在工程博客发文 *Redesigning source control at Anthropic*。官文写：公司自研版本控制系统 **Scion**，约五个月把 monorepo 从 git 全部迁完；同窗口还上线了代码评审面 **Antique**、代码搜索、源码权限体系，以及大批量已审代码如何合入落地等，本文焦点是 Scion。做 Scion、Antique 及相关系统的团队大约七人。

核心数字按官文口径：2026 年 5 月日均合并约 2,500 次，到 9 月日均超过 30,000 次，涨幅十倍多；合并需求几乎无限。官文配图旁的峰值说明里，有一天（9 月 9 日）标到 30,401 次合并——这是配图标注，本文未另做独立核验。

对用 agent 写代码的人，这篇更像一份「瓶颈挪到哪」的现场记录。官文写：编码本身已不再是瓶颈，瓶颈落到为人规模设计的源码管理、构建和 CI。

![日合并量曲线](https://leafw-blog-pic.oss-cn-hangzhou.aliyuncs.com/scion-merges-per-day.png)

*图：日合并量（2026 年 1–9 月）。来源：Anthropic Engineering · 2026-10-13；峰值 30,401 为配图标注。*

### 压力从哪来

Anthropic 的 monorepo 体量，官文给了几组硬数字：仅主分支历史就近 100GB；压缩工作副本超过 25GB；仅 CI 每天约 2,500 万次 checkout（还不含开发机、agent 沙箱和研究任务）。若按朴素全量去拉，官文估到每天数百 PB 级 git 流量（原文写超过 600 PB）。

他们试过浅克隆、稀疏检出、promisor、内部镜像、仓库种子快照等常见手段。高峰时内部 git 镜像到过几百台。镜像买来了时间，但合并速率上去之后，种子快照越来越跟不上主分支最新提交；依赖历史的 diff、blame 在部分克隆上也不好伺候。

![典型 git 镜像扩展架构](https://leafw-blog-pic.oss-cn-hangzhou.aliyuncs.com/scion-git-mirrors-setup.png)

*图：典型 git 镜像扩展架构。来源：Anthropic Engineering · 2026-10-13。*

官文的判断是：他们其实一直把 git 当集中式权威在用，而绝大多数客户端是 agent 和任务，本来就在线。为离线分布式设计的那套完整本地副本，反而拖累规模扩展。

### 设计原则

官文列了几条与 git 不同的出发点（文中也提到可参考 Google Piper、Meta Sapling 的经验）：

1. **客户端默认在线。** 不为「断网也能完整干活」预留完整仓库副本，需要时向服务端取数据。
2. **客户端与服务端不对称。** 历史、blame、提交、合并、rebase 等由服务端做；客户端维护有界本地对象缓存、铺开工作副本、监视文件系统变化，并提供好用的操作入口。
3. **源控服务用接口驱动多类应用。** 许多 CI 不必先 checkout：问「谁改过这行」「两个提交什么关系」可以直接调接口。
4. **整层可横向扩展。** 仓库数据分布式存放；任何地方都没有完整实体副本，也没有 git 那套 packfile 维护。
5. **提交要便宜、增量、无锁。** 创建提交、rebase、合并都在服务端发生；成本应按「这次改了多少」缩放，不能按整个仓库大小计。全局分支/标签一类共享状态尽量少碰，以免成为扩展瓶颈。
6. **工作副本可选，且默认稀疏、可虚拟化。** 能不问磁盘就不问；真要文件落地时，只为实际读到的路径付成本。

数据结构上，工作单元叫 **changeset**：相对第一父记录变更文件列表，外加内容寻址的 blob 指针；服务端创建后立刻处处可用。changeset 本身答不了 blame、路径历史一类问题，于是再算一层派生数据（blame、路径历史、提交图跳表等），并可按需急算或懒算。官文还写，迁移早期甚至先只答元数据查询，等客户端与协议就绪后再做重量级的文件落地。

### 架构与收益

![Scion checkout 分层架构](https://leafw-blog-pic.oss-cn-hangzhou.aliyuncs.com/scion-checkout-architecture.png)

*图：Scion checkout 分层架构。来源：Anthropic Engineering · 2026-10-13。*

客户端链路大致是：命令行客户端 `scn` → `scion-daemon`（节点级对象存储）→ 区域内的 `scion-cache` → 权威 `scion-server`（读 Spanner 或云存储）。协商协议按「客户端还缺哪些树和 blob」要对象，不必把「我已有什么」整包告诉服务端；任意一层都能答内容不变的对象请求。官文写：各层缓存命中率超过 99%。

各层都响应同一套远程调用，但严格分层，避免区域缓存故障把上游权威服务端一起拖垮。

相对原先的 git 镜像基建，官文报告 CPU 与内存占用大约小 200 倍；CI 与研究任务的 checkout 大约快两个数量级（从分钟级到秒级）；仅 CI 一项约多出 25% 的 CPU 容量。客户端与缓存都不必做仓库维护。

### 他们学到什么

官文把构建窗口与内部可用的 Claude Mythos Preview，以及用来盯系统的 Claude Tag 放在一起讲。举例：当年早些时候手写的 git→Scion 摄入管线，在 Mythos Preview 上重写后，官文写内存大约降到原先的 1/20、速度大约提高到 4 倍，且保留了摄入顺序与数据结构上的隐含不变量。

学习点按官文归纳，大致是：

- **小团队快速交付会更常见。** 约七人同时做 Scion、Antique 和一批相关系统，并在五个月内切完，期间日合并量涨了约十倍。
- **工程师价值在高层设计，以及敢对 Claude 说「不」。** 官文写：参与者现在会认为 Claude 写代码比自己强；人仍要定问题边界与跨系统取舍，拦住为满足一时模式而违反核心约束的改动，并在对抗式评审里避免过度防御地加复杂。团队仍审每一笔变更请求，重心放在意图上，不必逐行读完。
- **测试与运维。** 他们做了各类关键交互的隔离仿真、模糊测试和限流；用 Claude Tag 养了一批「超级粉丝」式 Claude，盯单个组件健康——官文称这类盯法能注意到传统告警显得单薄的细微异常。
- **合并队列与全局锁难在 agent 规模下原样复制。** 测试还在跑时，可能已有成百上千笔变更合入。他们更多投向合并后、部署前的自动测试；冲突交给 Claude 修，往往比人先发现还快。

安全面上，官文还写了目录级权限，以及能区分「只改注释」与「敏感逻辑变更」的语义审批，让人审力用在更重的地方。

### 适用边界

Scion **不适合**当通用 git 的替代品。这套假设主要对超大 monorepo 有意义——数万工程师，或大量 agent 在狂写代码。Anthropic 内部可用的 token 预算，也远超一般公司愿意为自研软件花的量。

做成广泛可用的产品同样难：它与 git 差得远，换系统意味着评审、搜索、CI 整套生命周期一起迁；内部组件又高度定制。官方更想分享思路，让人在仍用 git 的前提下借鉴：服务端可以与客户端不对称；可以提供更完整的服务端远程调用；协商协议不必一成不变；稀疏与浅层能力也可以组合得更好。文末致谢写明作者为 Nick G. 与源控团队等。

### 对我们意味着什么

官文自己也没把它卖成「赶紧把公司仓库换成 Scion」的产品建议。它更像一份提前到达的压力测试报告：当 agent 把合并吞吐拉高一个数量级，为人离线设计的完整本地副本、镜像农场、合并队列全局锁，会先露怯。

对日常还在用 Claude Code、Codex 一类工具的人，更可带走的是验收侧：多写代码不等于多出可上线的软件；瓶颈会滑到源码管理、构建、CI、以及「谁来看意图、谁来拦坏约束」。Anthropic 用小团队加 Claude 把基建重做了一遍，同时承认这套东西难对外产品化。

### 参考资料

1. https://www.anthropic.com/engineering/redesigning-source-control