Scion

Scion 是 Anthropic 研发并于 2026 年全面上线的内部版本控制系统（VCS）。它专为 AI 驱动的高并发软件工程负载设计，取代了原有的 Git 单体仓库（Monorepo）架构。

在以 Claude Code 为代表的 AI Agent（智能体）成为主力开发力量后，编码本身不再是瓶颈，面向人类开发者设计的传统开发基础设施（版本控制、CI 检出、合并队列）反向成为制约研发速度的核心死锁。Anthropic 由 7 名工程师组成的核心团队在 Claude 的辅助下，用时 5 个月构建了 Scion、配套代码审查系统 Antique、代码搜索和源码 IAM，并完成了全库迁移。

背景：Git 在 Agent 规模下的失效

Git 是一个去中心化系统，设计假定客户端具备离线工作能力，每一次 clone 都持有一份完整的、自包含的仓库历史，可离线计算 diff、查看 blame 和检出任意版本。这一假定在人类开发时代是行业标准，但在数十万并发 Agent 连续迭代的大型 Monorepo 中完全脱离了设计适用域：

** 仓库体积与流量爆炸**：Anthropic 的 Monorepo 仅主分支历史就接近 100 GB，压缩后的工作副本超过 25 GB。在 CI、开发者环境、Agent Sandbox（Agent 沙箱）和研究实验集群中，每日代码检出（checkout）次数达到 2,500 万次 量级。若直接以原生 Git 机制拉取，每日将产生超过 600 PB 的网络流量。
** 合并速率激增突破上限**：2026 年 5 月，Anthropic 平均每日合并约 2,500 次代码变更；到 2026 年 9 月，日合并量突破 30,000 次（2026 年 9 月 9 日峰值达到 30,401 次，7 日均线逼近 18,000 次）。
** 传统扩展方案的运维死锁**：此前 Anthropic 采用了主流的大型仓库缓解方案，包括浅克隆（shallow clone）、稀疏检出（sparse checkout）、promisor remotes、云存储快照种子（seeds），并在峰值时期维护了** 数百台内部 Git 镜像服务器**。但随着合并速率以 10 倍速度暴增，种子快照在刷新间隙迅速偏离主分支顶端，增量包（packfile）生成与网络同步成为沉重负担，跨分支的 diff 与 blame 频繁因缺少历史而失效。

根本矛盾在于：** 绝大多数代码客户端本质上是永久在线的 Agent 与自动化作业，而 Git 却在为离线客户端支付极其高昂的去中心化代价。**

面向 Agent 规模的六项设计原则

针对 Agent 客户端的固有属性，Anthropic 确立了与 Git 截然不同的六项核心设计原则：

** 客户端永久在线（Clients are always online）**：由于执行主体是 Agent 沙箱与集群任务，服务器始终可达。客户端不再维护全量本地历史，按需获取数据。
** 客户端-服务端非对称（Client-server asymmetry）**：Git 中每个客户端都是完整服务器；而在 Scion 中，服务端统管 blame、历史回溯、commit 生成、merge 与 rebase。客户端（scn 命令行）仅维护有界的对象缓存、磁盘工作区文件排布和文件变更监听。
** 全能力 API 化（Comprehensive source control service via APIs）：所有版本控制能力均暴露为远程 RPC。CI、自动化平分定位（bisect）和回滚（revert）流水线只需通过 API 查询两提交间的差异或血缘关系， 完全无需在本地物化或克隆代码仓库**。
** 横向无状态扩展（Horizontally scalable）**：全系统无任何全量物化仓库副本，亦无类似 Git packfile 的打包文件与维护周期。所有数据内容寻址，服务端节点本质上是可无协调伸缩的大型计算与缓存集群。
** 廉价、增量、无锁的提交（Commits are cheap, incremental, and lock-free）**：创建 commit、rebase 或 merge 均在服务端瞬间完成，成本仅与该次变更的文件规模成正比，与全库体积完全脱钩。除主分支与发布分支外，系统严格限制全局 ref 指针，避免分布式锁协调瓶颈。
** 工作区可选且原生稀疏/虚拟化（The working copy is optional, and sparse by design）**：读写任务均可直接通过 API 进行。当需要将文件落盘时，采用稀疏检出（仅拉取声明目录）和虚拟化检出（按需即时物化文件），任务仅为实际读取的内容付费。

核心架构与数据流

Scion 在底层摒弃了 Git 的 Merkle Tree 全量树指针提交模式，借鉴了 Google Piper 以及 Meta Sapling（尤其是其服务端 Mononoke 和 Bonsai 数据模型）的设计思想。

数据结构：Changeset 与派生数据机制

Scion 的原子工作单元是预写日志（WAL）中的 Changeset（变更集）：

** 只存一级增量**：不同于 Git commit 保存整个目录树的 root tree 节点指针，Changeset 仅记录相对于第一父提交（first parent）发生变化的文件列表，以及指向云存储中内容寻址（Content-addressed）压缩文件的哈希指针。
** 无锁单行提交**：Changeset 元数据写入 Google Cloud Spanner。分支指针移动仅是一次独立的单行 CAS（Compare-And-Swap）操作，与创建 Changeset 解耦。
** 派生数据机制（Derived Data）**：Changeset 自身不存整树结构，如何快速回答文件 blame 或路径历史？Scion 引入统一的派生数据计算引擎：每个派生结构递归定义（由父节点的值与当前增量推导）。服务端既可预先计算（eager），也可惰性延迟计算（deferred）。由于客户端不感知派生数据内部格式，服务端可随时无缝上线新的索引类型（如跨文件复制检测、路径快速搜索）。

flowchart TD
    subgraph Spanner["Spanner：元数据层"]
        CS["Changeset (id: 9f2c...7ab0)
author: Claude
parents: d41c...88e2
file_changes:
• docs/guide.md → 3e1f...
• src/legacy.rs → Deleted
• tools/build.sh → 9b07..."]
        CS -->|"父提交链接"| P1["Changeset (id: d41c...88e2)"]
        CS -.->|"服务端递归派生
(不存入 Changeset)"| DT["派生根目录树 (Root tree: 5c0e...)
↳ 目录树 src/ (77f0...)
  ↳ app.rs (c5d2...)"]
    end

    subgraph Storage["Cloud Storage：文件内容层 (内容寻址不可变哈希)"]
        B1["Blob 9b07...5d18"]
        B2["Blob 3e1f...a2c4"]
        B3["Blob c5d2...0e77"]
    end

    CS -->|"增量指针"| B1
    CS -->|"增量指针"| B2
    DT -->|"树叶指针"| B3

双平面架构：控制面与对象面

Scion 将版本控制清晰划分为控制面（Control Plane）与对象面（Object Plane），并实施严格的多级故障隔离：

flowchart LR
    subgraph Clients["客户端层"]
        Antique["Antique 审查系统"]
        Dev["开发者机器"]
        CI["CI 与计算集群节点"]
    end

    subgraph ControlPlane["控制面 (RPC)"]
        Server["scion-server 集群"]
        SpannerDB[("Spanner
Changeset / 分支 / 树结构")]
        GCS[("Cloud Storage
文件内容 Blobs")]
    end

    subgraph ObjectPlane["对象面 (流式分发)"]
        Daemon["scion-daemon
(单节点本地守护进程)"]
        Snapshot["周期性种子快照
(Periodic Snapshot)"]
        Cache["scion-cache
(区域级内存缓存集群)"]
    end

    Antique -->|"分支/历史/Diff/Commit/Land"| Server
    Dev -->|"分支/历史/Diff/Commit/Land"| Server
    CI -->|"分支/历史/Diff/Commit/Land"| Server
    Server --> SpannerDB
    Server --> GCS

    Dev -->|"树结构与文件内容"| Cache
    Snapshot -.->|"初始化新节点"| Daemon
    CI -->|"树结构与文件内容"| Daemon
    Daemon -->|"Cache Miss"| Cache
    Cache -->|"Cache Miss"| Server

** 控制面（Control Plane）**：客户端通过统一的 RPC 接口与 scion-server 交互，处理分支、历史日志、diff 比对、提交以及代码合入（land）。scion-server 直连 Spanner 与 Cloud Storage。
** 对象面（Object Plane）**：树结构与文件对象按级联拓扑流式拉取：
- 节点级守护进程 scion-daemon：每台宿主机部署一个，由周期性快照种子预热，同节点所有任务共享对象缓存。
- 区域级缓存 scion-cache：以内存格式直接流式返回目标磁盘结构，无需消耗 CPU 进行动态增量打包（delta compression）。各级缓存命中率维持在 99% 以上。
- 故障域隔离：严格限制下级向上级的请求回源，防止单区域缓存故障冲击权威服务端导致雪崩。

生产性能与资源实测数据

Scion 上线后，Anthropic 监控到的核心性能与资源收益如下：

日常命令耗时对比（Git vs Scn）

环境	操作项	原 Git 耗时	Scion (`scn`) 耗时	加速倍数	宏观收益
开发者环境	Pull latest	87 s	3.5 s	×25	—
	Checkout	15 s	1.1 s	×14	—
	Rebase	13 s	2.7 s	×4.8	—
	Status	3.9 s	19 ms	×207	—
	Commit	1.4 s	1.1 s	×1.3	—
	Diff	407 ms	67 ms	×6.1	—
Agent 环境	New worktree	7.1 min	5.1 s	×84	彻底解除多 Agent 隔离瓶颈
	Pull latest	3.0 min	9.0 s	×20	—
	Commit	18 s	761 ms	×24	—
	Status	4.3 s	<0.2 s	×20+	—
	单次变更总耗时	34 min	3.7 min	×9.2	每日节省约 11,000 Agent 小时
计算与 CI	计算任务启动检出	175 s	22 s	×8.0	每日节省约 85,000 机器小时
	CI 单任务检出	31 s	3.5 s	×8.8	每日节省约 195,000 机器小时

基础设施总体开销

** 算力开销缩减 200 倍**：Scion 服务端与缓存集群的 CPU 和内存占用仅为此前数以百计 Git 镜像集群的 1/200。
CI 算力节省：仅检出耗时缩短这一项，就为整个 CI 集群释放了 25% 的 CPU 总体算力。

协同变革：Antique 与 Agent 研发新范式

Scion 的落地不仅仅是存储引擎替换，它推动了整个软件交付生命周期的重构：

1. 废黜 PR，转向 Antique 与语义审查

传统 GitHub Pull Request（PR）在日均上万次合并下彻底瘫痪。Anthropic 配套上线了自研审查界面 Antique，并在 2026 年 7 月至 8 月间完全淘汰了 PR，全面转向 Antique 变更请求（Change Request, CR）。

Antique 支持更丰富的语义权限控制：例如将“仅注释修改”与“关键逻辑变更”自动分流，让人类工程师的注意力集中在具有实质影响的代码段上。

与之对照，独立维护的 Claude Code 仓库虽然仍保留 GitHub PR 形式，但通过 Agentic Code Review（智能体代码审查）引入了多 Agent 投票、收敛控制、风险分级审批与 Merge Queue，构成了高吞吐下的另一条实用演化路径。

2. 抛弃全局锁合并队列（Merge Queue）

在人类规模下，带全局仓库锁的合并队列是防范回归的标准实践；但当数百至数千个变更在单次测试运行期间并发合入时，全局锁会让合并吞吐降为零。

Anthropic 彻底放弃了合并队列全局锁，转为** 合并后（post-merge）与部署前（pre-deploy）强自动化回归测试**。尽管并发提交可能偶发冲突，但实测表明：Claude 自动感知并修复冲突的速度，远快于人类定位问题的时间。

3. 人类工程师角色的蜕变：从“写代码”到“说 No”

在开发 Scion 与 Antique 的过程中，7 人团队在 9 个月内累计合入了超过 12,257 次 变更，几乎所有底层代码均由 Claude 编写（工程师自认 Claude 的编码能力已超越人类）。人类工程师的价值体现在：

** 把握高层架构与边界取舍**；
** 及时对 Agent 说“No”**：例如多个上层系统曾试图通过线性读取 Git commit 日志来强行查询分支合并时间，人类工程师制止了这类反模式，引导其调用元数据 API；
** 防范对抗性审查的短视膨胀**：在对抗性审查（Adversarial Review）中，模型会因虚构的极端场景过度设计防御逻辑（如对内部可信微服务增加过度的多重校验），需由经验丰富的工程师纠偏；
** 审查重心转向“变更意图”**：工程师不再逐行挑挑挑语法，而是把控变更的全局系统意图。

4. Claude 极端优化案例

在早期原型阶段，团队曾手写了一套 Git 到 Scion 的数据摄取流水线。在使用内部早期快照版本的 Claude Mythos Preview 对其进行全面重写后，** 在零提示额外指示的情况下，新流水线的内存消耗降低了 20 倍，运行速度提升了 4 倍**，且完整保留了隐式摄取顺序与数据不变量。

5. “Superfans” 运营模式

在可观测性层面，团队深度依赖 Claude Tag，在 Slack 中为每个系统组件配置了专职监控 Agent（被称为“Superfans”）：

scion-daemon superfan
scion-cache superfan
Antique merge queue superfan

这些专职 Claude 持续挂载遥测数据与系统日志，像资深值班工程师一样不知疲倦地分析图表异动。相比传统一维的阈值告警，Superfans 能敏锐捕获细微、新颖的多维隐患。

局限与对通用生态的启示

Anthropic 在文章中明确指出：Scion 绝非通用的 Git 替代品。它深度依赖 Google Cloud Spanner 和云原生基础设施，且要求全套配套工具（代码审查、代码搜索、CI 流水线）进行深度定制化重构。此外，Anthropic 拥有远超普通企业的内部推理 Token 预算，这也是该架构能成立的前提之一。

然而，Scion 揭示的技术方向正在为通用开发工具链指明路径：

Git 服务端与客户端不应保持对称，中心化托管平台（如 GitHub、GitLab）完全可以采用全新的分布式非对称服务端架构；
Forge 平台亟需提供标准化的细粒度 RPC 查询接口，使 CI 和本地客户端免于全量拉取；
随着 Agent 编码在全行业普及，面向“永远在线的 Agent Swarm”重新设计版本控制，将在未来 6 到 12 个月内成为广泛的工程刚需。