AI 编程

Anthropic 把 monorepo 从 git 迁到自研 Scion：agent 时代，源代码控制成了新瓶颈

当 Claude 把写代码变成"不稀缺"，稀缺的就成了源代码控制、CI 这些为人规模设计的基础设施。Anthropic 日均合并量 4 个月涨了 12 倍，git 镜像上百个也顶不住，于是自研 Scion 并在 5 个月完成迁移：CPU/内存占用降到 1/200，checkout 从分钟级变秒级。本文完整编译其架构与经验，包括"工程师最常做的是对 Claude 说不"。

一句话结论：AI 编程的瓶颈正在从"写代码"转移到为人规模设计的开发者基础设施。Anthropic 披露：2026 年 5 月日均合并约 2,500 次变更，9 月已超过 30,000 次；monorepo 主分支历史近 100 GB、CI 每天约 2,500 万次 checkout——git 成了最大瓶颈。为此他们自研了 Scion（内置版本控制系统），并在 5 个月内完成 monorepo 从 git 的完整迁移，同时重做了代码评审、代码搜索与权限系统。

本文完整编译自 Anthropic Engineering 博客《Redesigning source control at Anthropic》（2026-10-13），并做中文整理。

一、先看数字：一天 3 万次合并

在 Anthropic，写代码已经不是瓶颈：Claude 能自主迭代研究循环、微优化复杂程序、从零构建新服务。瓶颈变成了源代码控制、构建和 CI——这些工具是为人类规模设计的。

Changes merged per day：Anthropic monorepo，2026 年 1–9 月

图 1：Anthropic monorepo 每日合并变更数（2026 年 1–9 月）——蓝色为 pull request，橙色为 Antique change request，黑线为 7 日均值；9 月 9 日单日合并 30,401 次（来源：Anthropic）。

几个关键数字：

指标	数值
5 月日均合并	约 2,500 次
9 月日均合并	30,000+ 次
主分支历史大小	近 100 GB
压缩后的工作副本	超过 25 GB
CI 每日 checkout	约 2,500 万次（未计开发环境、agent 沙箱、研究任务）
朴素 fetch 的日流量估算	超过 600 PB

他们并不是没救过：shallow clone、sparse checkout、promisor remote、内部 git 镜像、blob 存储里的快照（seeds）全都用过——高峰期维护了数百个内部 git 镜像。这些手段买到了时间，但随合并率上升越来越难运维：seeds 刷新后离 main 顶端越来越远，依赖历史的 diff 和 blame 在部分克隆上越来越难保持正确。

图 2：为 git checkout 扩容的典型方案——内部镜像、快照（seeds）等（来源：Anthropic）。

二、git 的设计，为什么在这里反成负担

Git 是去中心化系统：每个克隆都是完整、自包含的仓库，可以离线计算 diff、读历史与 blame、检出任意版本。对绝大多数仓库，这是正确的设计，也是 git 成为标准的原因。

但在 Anthropic 的场景里，几乎所有客户端都是 agent 和作业（jobs）——它们天然在线。他们实际是在把 git 当中心化系统用（只有一份权威副本），却为每个客户端付出了分布式系统的代价。于是他们反过来问自己：

如果从第一天就假设"客户端永远在线"来设计源代码控制，它会是什么样？

三、Scion 的六条原则

Anthropic 参考了 Google Piper 与 Meta Sapling 的经验，确立了六条原则：

客户端永远在线。不再假设客户端需要完整仓库；客户端按需从服务端取数据。
客户端—服务端不对称。git 里每个客户端都能当完整服务端；Scion 中服务端负责历史与 blame 查询、创建提交、合并与 rebase；客户端只维护有界的本地对象缓存、把文件铺到磁盘、监视文件系统变化，本地几乎不做计算。
源代码控制作为服务，可以支撑新应用。Scion 把客户端用到的所有查询都暴露为 API——CI 作业或工具问"谁最后改了这一行""两个提交什么关系"时，不必再维护本地仓库。他们的自动 bisect 与 revert 流水线，离开这种廉价的程序化访问就不可行。
一切必须能水平扩展。仓库数据分布存储，任何地方都没有仓库的完整实体副本（连服务端也没有）；没有类似 packfile 的结构，也就没有仓库维护作业。
提交要便宜、增量、无锁。在 Scion 中，每次提交、rebase、合并都发生在服务端；创建提交与更新下游数据结构的成本必须随变更大小扩展，而不是随仓库大小扩展。其开发生命周期不鼓励 refs（分支、标签等）——因为"所有服务端都要达成一致的全局状态"是迟早要爆的扩展问题。
工作副本可选，且天生稀疏。CI 大量任务根本不需要 checkout：需要 diff 与 merge base 就直接问服务端，很多写负载也能纯 API 完成。协议以稀疏检出和虚拟化检出（按需物化文件）为核心，作业只为真正读到的文件付费。

四、数据结构：changeset 与 derived data

Scion 的工作单元是 changeset——一条预写日志（write-ahead log）记录。它存的东西大多和 git commit 类似，但有一个关键区别：git commit 存指向整棵树的指针，changeset 只存"相对第一个父提交发生变化的那批文件"，以及指向 blob 存储中压缩内容的内容寻址指针。

图 3：Scion changeset 的形状——只记录变更，配合内容寻址的 blob 指针（来源：Anthropic）。

这个结构带来高吞吐：没有 packfile 要收、没有锁或跨服务协调、没有 ref 要移动。Changeset 在服务端创建、立即全局可见；ref 虽被支持，但移动它只是对单个 Spanner 行做一次 compare-and-swap，与创建 changeset 解耦。

Changeset 本身只记录"变了什么"，无法直接回答"谁最后编辑了这一行""哪些提交影响过这个文件"。为此 Scion 从 changeset 构建派生数据：文件 blame 结构、路径历史结构、提交图的跳表（skip list）等。有意思的是实现方式：每种派生数据递归定义——某个 changeset 的值由它父提交的值算出。好处有三：

需要新的加速结构时，可以随时新增一类派生数据；
每类可以选择急切或延迟计算，避免物化用不到的数据；
客户端看不到这些结构的内部，服务端可以自由优化而不改客户端。

五、扩缩容：把仓库拆成"缓存 + 权威源"

Scion 的服务端是一队无状态感很强的服务器：提供取 changeset、算 diff、找 merge base、拉 blob 等 API。因为所有源代码数据都是内容寻址的（存下就不再变化），任何服务器都能安全缓存，几乎没有跨节点协调——本质上是一大堆"可以现场计算派生数据并写回 Spanner 的缓存"。

客户端 scn 的 fetch 协议与 git 很不一样：协商时不告诉服务端"我有什么"，而是只围绕"客户端想要的树和 blob"操作。从根树开始，客户端查本地缺哪些树、递归拉取，再对 blob 重复同一过程。每个请求都是针对某个永不变的具体对象，因此任何缓存都能应答，架构接近传统的分层缓存；过程可续传，也没有"单个几 GB packfile 响应"的问题。稀疏甚至虚拟化检出不需要特殊支持——客户端不想要的树，不问就行了。

图 4：Scion 的检出架构——节点守护进程、区域缓存、权威服务三层（来源：Anthropic）。

部署上分三层：

scion-daemon：跑在每台节点上的守护进程，为本节点所有作业存储对象；从一个周期性刷新的快照起步，只与同区域的缓存服务器通信；
scion-cache：区域缓存服务器，直接从内存按客户端消费的磁盘格式流式发送对象，不做缺对象计算、不做 delta 压缩；
scion-server：权威服务器，缓存未命中时按需读取 Spanner 或云存储。

三层对同一协议回应相同的 RPC，客户端不需要知道缓存拓扑；但层间严格分级以隔离故障域——避免某个区域缓存故障把上游权威服务器压垮。Anthropic 公布的效果：

指标	迁移后
每层缓存命中率	> 99%
基础设施资源占用（CPU/内存）	比原 git 镜像体系小 200 倍
CI / 研究作业 checkout	快两个数量级（秒级而非分钟级）
CI 自身	释放出 25% CPU 容量
仓库维护作业	客户端与缓存都不需要

六、工程经验：7 个人、5 个月、代码量 10 倍

Scion 和代码评审工具 Antique（外加半打相关系统）由一支 7 人团队构建，5 个月内完成完整迁移——期间每天合并的代码量还涨了 10 倍。他们分享了这些经验：

小团队快速开发会越来越常见。 过去开发和部署这样一套源代码控制系统，通常要一家公司投入更多工程师、迭代多年；现在这种"快而灵活"的迁移会变多。

工程师的价值没降低，但工作内容在变。 参与该系统的工程师如今都认为 Claude 写代码比自己强；但工程师仍然提供跨系统的高层理解与设计取舍——决定要解决什么问题、要达到什么规模。他们发现，工程师的角色常常是对 Claude 说"不"：agent 有时会为了满足某个本不该存在的模式而违反核心系统约束（例如多个系统试图线性扫提交日志来查找"变更何时合入 main"，而不是去问代码评审工具）；对抗式评审虽然有效但可能短视，导致过度防御、过度设计。团队仍然评审每一个变更请求，但方式从"逐行读代码"变成"审变更的意图"。

质量与优化反而更强。 因为 Claude 能写得比人多得多，Scion 成了他们测试最充分、防御最完备的代码库之一：对所有非平凡的基础设施与源代码控制交互都做了封闭仿真，还有模糊测试与精细限流。Claude 还顺手找到了祖先查询里漏用一个索引的算法级优化——这类问题过去要专家花几天到几周。

图 5：Scion 与 Antique 代码库每周合并的变更数（2026 年 1–9 月）（来源：Anthropic）。

一个具体案例：他们早期手写了一个 git→Scion 摄入流水线的原型，自认为不错；拿到内部早期版 Claude Mythos Preview 后让它重写——在没有任何额外指令的情况下，内存占用降到 1/20、速度快 4 倍，并保住了摄入顺序与数据结构上的全部隐式不变量。

图 6：原生 Scion 仓库上观测到的性能改善（来源：Anthropic）。

其他值得记录的做法：

安全：Scion 支持仓库级访问控制，以及按目录授权——不必为了敏感代码放弃 monorepo 的收益；评审工具能表达语义化的审批约束，把"只改注释"和"敏感逻辑变更"区分开，让人的注意力集中在最重要的变更上。
运维：团队重度使用 Claude Tag，为每个组件建 Slack 频道让 Claude 专盯其健康度（自称 "superfans"）——scion-daemon、scion-cache、Antique merge queue 各有一个；它们能发现比传统告警更微妙的异常。
重新思考先验：agent 规模下，传统 merge queue 的意义在变——测试运行时可能有成百上千个变更合入，全局仓库锁已无法复制；他们转向合并后 + 部署前自动化测试，并发冲突则交给 Claude 修——"通常比人识别得还快"。

七、边界：Scion 不是 git 的通用替代品

Anthropic 自己强调：Scion 绝不适合一般用途，只对"几万名工程师或一大批 agent 疯狂写代码"的超大 monorepo 才有意义；而且 Anthropic 的内部 token 预算远超一般企业愿意承担的水平。他们更希望别人借鉴思路而不必离开 git：

git 服务端不必和客户端一样工作，新的服务端架构能带来可观的扩展收益；
git 平台可以提供像 Scion 那样完整的服务端 RPC，甚至跨 forge 标准化；
fetch 协商协议可以改进，稀疏/浅克隆特性应该能更好地组合。

八、对团队的启示

大多数团队短期内不会遇到 3 万次/天的合并量，但方向已经清楚：

先量化自己的压力点：合并频率、仓库大小、CI checkout 成本、评审队列长度——瓶颈会先出现在最依赖"人规模假设"的那一环；
短期不必自研 VCS，但可以为 agent 产出量做准备：评审带宽的分配、CI 容量、版本管理与权限粒度；
把"审意图"纳入流程：当代码量超过人的阅读带宽，评审的重点从逐行检查转向意图、约束与风险，并保留人工复核的最终责任。

参考来源

Anthropic Engineering：《Redesigning source control at Anthropic》（2026-10-13）https://www.anthropic.com/engineering/redesigning-source-control
Simon Willison 的导读与讨论：https://simonwillison.net/2026/Oct/13/redesigning-source-control-at-anthropic/
Scion 相关背景：Google Piper（https://en.wikipedia.org/wiki/Piper_(source_control_system)）、Meta Sapling（https://sapling-scm.com/）