> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# Anthropic 把 monorepo 从 git 迁到自研 Scion：agent 时代，源代码控制成了新瓶颈
- URL: https://www.hubwiz.com/blog/anthropic-scion-agent-scale-source-control/
- Published: 2026-10-15T01:55:56.000Z
- Updated: 2026-10-15T01:55:55.000Z
- Description: 当 Claude 把写代码变成"不稀缺"，稀缺的就成了源代码控制、CI 这些为人规模设计的基础设施。Anthropic 日均合并量 4 个月涨了 12 倍，git 镜像上百个也顶不住，于是自研 Scion 并在 5 个月完成迁移：CPU/内存占用降到 1/200，checkout 从分钟级变秒级。本文完整编译其架构与经验，包括"工程师最常做的是对 Claude 说不"。
- Author: admin
- Tags: AI 编程, Vibe Coding, 源代码控制, Anthropic, Monorepo

**一句话结论**：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 月](https://www.hubwiz.com/blog/content/images/2026/10/img_dc0eb79294a517512873a8730e8372fb.png)

*图 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 在部分克隆上越来越难保持正确。

![为 git checkout 扩容的典型方案](https://www.hubwiz.com/blog/content/images/2026/10/img_8292c59b223616c6ca7893c6014a491f.png)

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

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

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

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

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

## 三、Scion 的六条原则

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

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

## 四、数据结构：changeset 与 derived data

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

![Scion changeset 的结构](https://www.hubwiz.com/blog/content/images/2026/10/img_7d25b2b3f3dd27e0272fedc37972fb3a.png)

*图 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 响应"的问题。稀疏甚至虚拟化检出不需要特殊支持——**客户端不想要的树，不问就行了**。

![Scion 的 checkout 架构](https://www.hubwiz.com/blog/content/images/2026/10/img_42b51b7ee18faa8f225d745d29cb8f36.png)

*图 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 还顺手找到了祖先查询里**漏用一个索引**的算法级优化——这类问题过去要专家花几天到几周。

![Scion 与 Antique 每周合并变更数（2026 年 1–9 月）](https://www.hubwiz.com/blog/content/images/2026/10/img_0e2d9cf8cda07168720bc0fbada3bc08.png)

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

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

![原生 Scion 仓库上的性能改善](https://www.hubwiz.com/blog/content/images/2026/10/img_ed52ecc96637814ac585f37e62fb80b0.png)

*图 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 万次/天的合并量，但方向已经清楚：

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

---

## 参考来源

- 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/）

## 延伸阅读（本站）

- [AI 编程 / Vibe Coding 完全指南](https://www.hubwiz.com/blog/vibe-coding-stack/)
- [给智能体构建护栏（Go 版）](https://www.hubwiz.com/blog/building-guardrails-for-ai-coding-agents-in-go/)
- [智能体时代还需要代码评审吗？](https://www.hubwiz.com/blog/do-we-still-need-code-reviews-in-the-age-of-coding-agents/)
- [如何大规模评估 AI 生成的代码](https://www.hubwiz.com/blog/how-to-evaluate-ai-generated-code-at-scale/)
- [100 小时评测：Pi vs OpenCode](https://www.hubwiz.com/blog/100-hour-evaluation-pi-vs-opencode/)

本文由 汇智网 · Software 2.0 编译整理，转载请注明出处。