Anthropic 开源 Scion：为 AI 智能体速度定制的 Git 替代品

今年早些时候的四个月里，进入 Anthropic 主仓库的代码合并从每天约 2500 次增长到 3 万次以上 —— 12 倍的增长，推动它的不是招聘潮，而是 Claude 智能体以任何人类工程团队都赶不上的节奏在写代码、审代码、提交代码。支撑着几乎所有现代软件开发的版本控制系统 Git，并不是为此设计的。周二，Anthropic 发表了一份详细记录，讲述当它试图让 Git 跑在这个速度上时发生了什么 —— 并发布了 Scion，其工程师用大约五个月造出来替代 Git 的定制版本控制系统。

这个时间点的意义不止于开源发布本身。Anthropic 的工程师认为这不是 Anthropic 独有的问题。「我们相信 AI 辅助开发会让业界其他公司在六到十二个月内面对类似的挑战，」团队写道。对任何正在让 AI 智能体跑在共享代码库上 —— 或计划这么做 —— 的组织而言，Scion 既是一份事后复盘，也是一张架构蓝图。

AI 智能体如何击穿 Git 的核心架构

Git 由 Linus Torvalds 在 2005 年设计，面向的是分布式、可离线、以人类节奏推进的开发。它的内部数据模型把完整的目录树快照打包成磁盘上的二进制「packfile」，并定期运行垃圾回收来压缩和重组这些文件。它的合并队列把提交串行化：两个分支需要合并时，Git 锁住队列、执行操作、再释放。对于以人类速度运作的团队 —— 每天几十或几百次提交 —— 这套架构是察觉不到的开销。

到了每天 3 万次合并，它就不再察觉不到了。Git 的 GC（垃圾回收）过程本是例行的后台任务，却开始在负载下以不可预测的间隔触发，造成 CI 流水线停摆。为串行的人类提交设计的合并队列成了瓶颈，在 Git 的架构内无法并行化。每个 CI 节点都各自重跑昂贵的图遍历操作 —— 计算祖先链、blame 数据、路径历史 —— 而这些其他节点已经算过又丢掉了。结果是一个吞掉 Anthropic 总 CPU 算力 25%、只为维护版本控制状态的系统。

根源在架构。Git 的模型假设客户端做计算、服务器存数据。当数百个节点的 CI 集群都需要对同一仓库状态执行相同的昂贵操作时，这个假设就崩了。

Scion 的变更集架构：Git 从没做过的事

Scion 的核心数据模型把这个假设倒了过来。Git 在每次提交时存储完整目录树快照，而 Scion 的工作单元是变更集（changeset） —— 一条预写日志（WAL）条目，只记录发生改动的文件，并用内容寻址的指针指向一个独立的 blob 存储。这与 PostgreSQL 这样的数据库和 RocksDB 这样的存储引擎用的是同一个结构性思路：把每次修改记录到一个不可变的顺序日志里，其余一切都从这个日志推导出来。

这个架构带来的后果意义重大。原始变更集之外的一切 —— blame 数据、路径历史、提交图跳表 —— 都被当作派生数据，从变更集日志中惰性计算并缓存。没有 packfile。没有重打包压力。没有 GC 风暴。当一个 CI 作业需要知道两次提交之间改了哪些文件时，它去问服务器，服务器从派生数据缓存里作答。CI 作业自己不重算这个答案。

这种服务端计算模型是与 Git 的第二个重大分野。Scion 明确是一个客户端—服务器系统：服务器执行全部的 diff、合并、变基和祖先计算。客户端 —— 无论是开发者的工作站还是 CI 运行器 —— 只维护一个有界的本地缓存。这消除了让 Git 的 CI 开销如此高昂的重复性昂贵工作。

提交加锁用的是 Google Spanner 的比较并交换（compare-and-swap）操作，而不是传统的串行合并队列。Spanner 全球分布、强一致的事务模型允许多个提交并行推进，冲突在数据库层解决，而不是靠队列串行化。这就是 Scion 能在没有合并队列瓶颈的情况下处理每天 3 万次以上合并的原因。

每天 2500 万次检出的三级缓存

要承接智能体规模的读流量，需要一套与写路径同样精心设计的缓存架构。Scion 使用三个层级：scion-daemon（每台机器本地的节点级缓存）、scion-cache（区域共享缓存），以及scion-server（在区域缓存未命中时从 Spanner 和云 blob 存储读取）。该系统在每天 2500 万次检出中实现了超过 99% 的缓存命中率。

检出本身的工作方式也不同。Scion 不是像 Git 那样从 packfile 物化出完整的工作目录，而是支持稀疏和虚拟化检出：文件按需获取，CI 作业还可以通过一个直接返回文件内容、不写盘的 API 完全绕过检出。对于 CI 作业只需要仓库中一小部分文件的大型 AI 生成代码库，这是显著的吞吐提升。Anthropic 称检出时间从分钟级降到了秒级。

Scion 管理的仓库并不小：Anthropic 主分支历史重达 100 GB，压缩后的工作副本 25 GB。至于这套基础设施比同等的 Git 部署小 200 倍的说法，是公司自报的，尚未经独立验证。

Claude 既是病因也是解药

Anthropic 现在约 80% 的代码由 Claude 编写 —— 这是 Anthropic 管理层公开引用过的数字，也解释了合并量的增长。但 Claude 还以超出被动生成代码的方式，嵌入在 Scion 的运维基础设施里。

延伸阅读：Anthropic 给 Max 和 Team 订阅送 API 额度，Pro 不在内

当 Anthropic 把现有的 Git 历史迁移到 Scion 的变更集格式 —— 一项涉及整个仓库提交图、技术上相当复杂的操作 —— 时，它用Claude Mythos Preview 重写了摄取流水线。据 Anthropic 称，重写后内存消耗降低 20 倍，处理速度提高 4 倍。

日常运维用的是 Anthropic 所称的「superfans」（超级粉丝）：专门分配去监控特定系统组件的 Claude Tag 实例（部署在 Slack 里的 Claude）。每个 superfan 盯着自己负责的组件的行为并标记异常 —— 一种无需人类值班负担就能扩展的、永远在线的运维可观测性。

人类工程师的角色也变了。当 Claude 智能体产生合并冲突 —— 在许多智能体写入重叠代码路径时这是家常便饭 —— Claude 解决冲突的速度比人类工程师找到冲突还快。工程师现在审阅的是所提改动背后的意图，而不是逐行审计 diff。Antique，一个与 Scion 一同构建的配套代码审查工具，正是为这种工作流专门打造的。标准的 pull request 工具假设的是人类审阅者批准一个个离散的 diff，而 Antique 支持复杂的语义级批准约束，以匹配智能体生成代码审查的规模与结构。

Scion 的坐标：Google 做过，Meta 做过 —— 现在轮到 Anthropic

Anthropic 不是第一家长到 Git 装不下的科技公司。Google 在 2010 年代初撞上 Subversion 的扩展极限后建了 Piper —— 一个先后由 Bigtable 和 Spanner 支撑的客户端—服务器 VCS —— 如今管理着约 20 亿行代码。Piper 从未开源。Meta 花了大约十年构建 Sapling（最初叫 Eden SCM），一个兼容 Mercurial、为其自身单体仓库规模优化的 VCS；Meta 于 2022 年 11 月开源了 Sapling。微软则从同一问题的另一个维度入手，推出 GVFS（VFS for Git），在保持 Git 兼容的同时为超大仓库虚拟化检出。

延伸阅读：Claude Code 的 mods 默认开启，无沙箱

Scion 与所有这些的区别在于设计任务书。Piper、Sapling 和 GVFS 是为扩展人类开发团队而建的。Scion 之所以诞生，是因为 AI 智能体在不到一年里让人类规模的工具过时了。那些架构选择 —— 基于 WAL 的变更集、服务端计算、Spanner 比较并交换提交、虚拟化 CI 检出 —— 直接回应的是智能体速度的需求，而不是人类速度的需求。

考虑采用 Scion 的组织要注意它对 Spanner 的依赖。按设计运行 Scion 需要 Google Spanner 或一个兼容的全球一致分布式数据库 —— 这不是大路货基础设施。该系统以参考架构的形式开源，而不是给跑标准云基础设施的团队的 Git 即插即用替代品。

业界接下来会怎样

Anthropic 关于六到十二个月内业界普遍出现 Git 扩展失败的预测，建立在催生 Scion 的同一笔账上：AI 智能体的采用正在每个主要 AI 实验室和越来越多的企业软件团队中加速。目前以低流量运行智能体辅助开发的组织，将遭遇 Anthropic 记录下的同样的合并队列争用、同样的 GC 压力和同样的 CI 集群 CPU 开销 —— 只是晚一些。

Scion 的开源给了这些组织一个 Anthropic 自己不曾有过的起跑优势。架构决策有详尽的文档：基于 WAL 的变更集模型、派生数据抽象、分层缓存拓扑、服务端计算模型，以及 Spanner 支撑的加锁策略，共同构成了对智能体规模 VCS 需求的一套连贯回应。无论业界最终是汇聚到 Scion 本身、分叉它，还是像 Google 和 Meta 各自独立做的那样构建竞争架构，Git 作为生产级 AI 开发基础设施无可争议的默认选项的时代，看来正在走向终结。