Git 成了瓶颈？Anthropic 自研 Scion 为 AI 智能体重构版本控制

Anthropic 的合并量从 5 月的每天 2500 次变更，飙升到 9 月的每天超过 30000 次——短短四个月增长 12 倍。Git 没能扛住这个量级，于是他们自研了一套源代码控制系统，名为 Scion，并发布在工程博客上。这篇文章在 Hacker News 上获得了 700 多条评论，其中一半在说"这不就是重新发明了 SVN 吗"。他们并没有，但帖子背后的争论，值得每个大规模运行编程智能体的人认真看一看。

Anthropic Scion 源文章截图

压垮 Git 的那些数字

Anthropic 在博文中给出了这组数据：

主分支历史：约 100 GB
压缩后的工作副本：25 GB+
每天 CI 检出次数：2500 万次
这些检出产生的原始 Git 流量：每天 600+ PB
外加数百个内部 Git 镜像，还得有人持续维护它们

算一笔账：600 PB 除以 2500 万次检出，约等于每次检出 24 GB。也就是说，每一次都是完整的的工作副本拉取。没有人偷懒，问题在于 Git 正在以它从未被设计支持的规模，做它本来被设计要做的事。

为什么 Git 的设计和智能体相互对抗

Git 假设使用者是一名离线工作的开发者，手持完整的本地副本，偶尔同步一次。这些假设对人类是功能，对智能体就是负担：

离线优先意味着每个客户端都携带完整历史。智能体永远在线，付出了代价却从不需要这个特性。
完整本地仓库意味着一次冷启动的 CI 任务或沙箱，在写出第一行代码前就要拉取几个 GB。
镜像是扩展 Git 读取的手段，却是一项随消费者数量增长而膨胀的运维负担。
Git 的部分克隆工具（浅克隆、稀疏检出、promisor remote）确实存在，但都是可选项、配置繁琐，像是硬贴上去的补丁。

Anthropic 重新框定了问题：如果我们设计源代码控制时，默认智能体永远在线，它会是什么样子？

文中提到的浅克隆、稀疏检出和 promisor remote 是 Git 为缓解"完整历史+完整工作副本"代价而提供的三种部分克隆手段，但它们的成熟度和易用性差异很大。

**浅克隆（shallow clone，--depth=N）**只拉取最近 N 个提交，历史被截断，因此无法正常执行 blame、log 追溯或基于旧提交的合并，很多 CI 场景用起来会立刻踩坑。

**稀疏检出（sparse-checkout）**解决的是工作副本层面的冗余：只物化指定目录，但仓库对象库依然是完整的，磁盘和网络开销不减。

promisor remote 是三者中最接近"按需拉取"的机制，配合 --filter=blob:none 可以延迟下载 blob，但它要求服务端支持 filter 协议，且在网络不稳定或离线时会退化，本质上仍是 Git 原有模型的补丁。

这些工具共同的问题是：默认关闭、配置琐碎、语义与完整克隆不完全一致，所以在大规模自动化场景里很难作为可靠的一等公民使用——这正是 Scion 选择从零重构默认假设的动机。

Scion 到底做了什么

它的设计原则可以概括为：

客户端始终在线。 没有离线模式。
服务端做重活。 历史、blame、提交、变基和合并都在服务端完成，客户端只保留有界缓存。
API 优先。 每次查询都是一次 RPC。要问仓库的问题，不需要本地仓库。
水平可扩展。 任何数据都没有单一物化副本。
无锁、增量提交。 成本与变更大小成正比，而非与仓库大小成正比。
虚拟化或稀疏检出，不物化用不到的文件。

底层实现上，变更集是预写日志中的条目。它们存储相对于父级的文件增量，并指向内容寻址的 blob。与 Git 的树对象不同，这让服务端无需跨服务器协调就能创建提交。派生数据（blame、路径历史、跳表）按需或主动从变更集计算。

读取都经过三层缓存，它们使用同一套 RPC：

层级	职责
`scion-daemon`	每节点有界本地缓存，从快照启动
`scion-cache`	区域性缓存，从内存流式传输对象
`scion-server`	权威层，由 Spanner 和云存储支撑

协商基于"你需要哪些树和 blob"，而不是 push/pull。因此任意一层都能应答。

文中多处出现的"内容寻址"（content-addressable storage）是理解 Scion 与 Git 差异的关键概念。它的核心思想是：数据的存储位置由数据本身的内容哈希决定，而非由文件名或路径决定。Git 的 blob 和 tree 对象就是内容寻址的——同一份文件内容无论出现在哪个提交里，只存一份。

Scion 沿用了这一点，但把寻址对象放在变更集的增量层上：每个变更集是预写日志中的一条记录，存储相对于父级的文件增量，并指向内容寻址的 blob。这与 Git 的 tree 对象形成对比——Git 的 tree 是分层快照结构，创建一次提交往往需要跨多个对象读写，在分布式服务端上难以避免协调。

内容寻址带来的直接好处是去重和免协调：相同内容天然共享，服务端可以在任意节点独立生成提交而无需全局锁，这也是 Scion 声称"无锁、增量提交"和"水平可扩展"的底层依据。

实验数据

Anthropic 报告的结果包括：

基础设施占用（CPU 和内存）缩小约 200 倍
检出速度快约 100 倍：从几分钟缩短到几秒
更快的代码获取为 CI 节省了约 25% 的容量
各层缓存命中率 99%+
零仓库维护

这些是 Anthropic 自家工作负载上的自测数据，应当视为"在完全掌控技术栈时可以达到的上限"，而不是你能直接复现的基准。

理解 Anthropic 数据时需要注意一个方法论前提：这些数字几乎全部来自自家工作负载、自家硬件、自家技术栈上的端到端对比，且基线是"规模失控下的 Git 镜像集群"而非理想配置的 Git。

具体来说，"基础设施占用缩小约 200 倍"统计的是支撑同等检出流量所需的 CPU 与内存总量，而不是单次操作的资源消耗；"检出快约 100 倍"是从冷启动到可用工作副本的墙钟时间，天然有利于任何避免全量拉取的方案。缓存命中率 99%+ 也依赖于工作负载高度重复——同样的树和 blob 被大量智能体反复请求。

换句话说，这些数字说明的是"当你完全掌控客户端、服务端和缓存层时，理论上限有多高"，而非"任何团队迁移后都能获得 100 倍加速"。把厂商自测当作方向性证据而非可复现基准，是阅读此类工程博客的稳妥态度。

最值得玩味的一个细节

七名工程师在五个月内构建了 Scion 及其配套代码审查工具 Antique，而同期合并量还在增长 10 倍。

他们高度评价了 Claude Mythos Preview。其中一例：手写的 Git 到 Scion 数据迁移原型，被模型无需额外指令地重写，结果内存占用降低 20 倍，运行速度提升 4 倍，同时保留了隐含的顺序不变量。工程师的角色转向了设计决策、审查意图，以及在模型试图违反系统约束（比如暴力搜索提交日志）时说"不行"。

如果对此存疑，很合理——这是厂商在描述自家工具。但这也是最具实用价值的部分：人的价值转移到了约束和审查，而不是敲键盘。

Hacker News 讨论对了什么，又错了什么

"所以他们重新发明了 SVN。" 表面上看，服务端权威加瘦客户端确实和 SVN 相似。但 SVN 没有内容寻址存储，没有派生数据层，也没有为大量自动化客户端设计的缓存层级。这是不同的物种。

"本地优先的历史才是 Git 和 jj 的意义所在。" 这是最好的反驳。做微小的本地提交、反复修改、丢弃重来，是真实的工作流，而 Scion 放弃了它。这能成立，只是因为 Anthropic 的智能体永不掉线。而我们大多数人，有时候仍会离线。

"这是在无人审查的情况下发布代码吗？" 博文并未如此声称，并且将意图审查描述为人的职责。但这个疑问是合理的，毕竟每天 30000 次合并这个数字本身就在引人发问。

如果你不是 Anthropic，需要在意吗？

大体上：不需要，至少不需要 Scion 本身。作者表示，它只对拥有数万名工程师或智能体集群的超大型单体仓库有意义。迁移意味着围绕它重建代码审查、搜索和 CI。他们预计会将一些理念推回 Git 生态，让托管平台在保留 Git 模型的同时，采纳服务端 RPC 和新的服务端架构。

但有三点是免费的：

测量你的检出成本。 如果你的智能体或 CI 每次运行都全新克隆，你很可能在为永远不读的历史付费。浅克隆和 --filter=blob:none 是成本最低的第一步：

git clone --depth=1 --filter=blob:none --sparse https://example.com/big-repo.git
cd big-repo
git sparse-checkout set services/my-service

把仓库当作服务，而不是文件夹。 如果智能体需要 blame、历史或搜索，API 优于本地克隆。
在 Git 成为瓶颈之前，审查才是你的瓶颈。 Anthropic 在构建版本控制系统的同时构建了代码审查工具，这不是巧合。

我的看法

真正有意思的主张不是"Git 已死"，而是 Git 的默认设定编码了一套人类工作流，而智能体工作负载几乎推翻了其中的每一条。可以预期托管平台会以服务端操作和更好的部分克隆体验来回应，也可以预期更多大厂会悄悄打造自己的方案。

Git 已经挺过了二十年的"Git 之后是什么"。它很可能也挺得过这一波。只不过，它作为智能体直接对话的层，可能不会持续太久了。

来源：Redesigning source control at Anthropic 以及 Hacker News 讨论。