Git 撑不住日均 3 万次合并，Anthropic 自研 Scion

2026 年 5 月，Anthropic 平均每天向主代码仓库合并 2,500 个变更。到了 9 月，这一数字已突破 3 万，9 月 9 日单日更达到 30,401 个。激增的来源是 Claude：它如今能自主运行研究循环、优化复杂程序，并从零构建后端服务。于是，基于 Git 的源代码管理和 CI（每次变更时自动构建和测试的系统）这类按人类节奏设计的工具，成了公司最大的瓶颈。Anthropic 在 10 月 13 日发布的技术文章中介绍，一个七人团队开发了名为 Scion 的新版本控制系统和名为 Antique 的代码审查工具，并用五个月把单体仓库从 Git 迁出。任何高度依赖 AI 编程智能体的团队，迟早也可能撞上同一堵墙。

Git 为何跟不上这样的工作量

Git 建立在这样的前提之上：代码由人编写，生产成本高，值得人工仔细审查。它还是分布式的。每个克隆，也就是仓库在本地的完整副本，都保存全部历史，在本机计算 diff，并能离线工作。这适合开源项目和人类规模的团队，但面对巨型单体仓库，即把许多项目的代码放进同一个仓库，又有机器昼夜不停地生成和测试变更时，就力不从心了。

检出是把代码从仓库中取出、供作业使用的步骤；上述每日次数不包括开发者环境、智能体沙箱和研究作业。Anthropic 尝试过只拉取部分仓库的常见变通办法，例如浅克隆、稀疏检出和无 blob 克隆，还运行了数百台内部 Git 镜像服务器。但随着合并速度加快，这套方案越来越脆弱。镜像的种子快照总是追不上主分支的最新提交，部分克隆则让计算 diff 或 blame（记录每一行最后由哪次变更改动）的成本变得很高。

更深层的问题在于用户变了。传统版本控制假定用户经常断网、需要离线工作。而 Anthropic 源代码管理的主要用户是智能体、CI 机器人和计算作业，它们始终在线。让 Git 擅长分布式离线开发的那些特性，在自动化的工作量面前反而成了掣肘。Anthropic 从第一性原理出发重新思考版本控制，借鉴了谷歌的 Piper 和 Meta 的 Sapling 等大规模系统。Meta 自己也曾为应对其单体仓库而大幅改造 Mercurial。

▲ 复制整个仓库的成本

Scion 背后的原则

Scion 颠覆了 Git 的许多默认做法：

• 重活交给服务器。 历史、diff、blame、合并和变基，都由掌握权威数据的服务器处理。客户端只保留容量有上限的本地缓存，并根据磁盘上的改动同步工作副本。
• 源代码管理即 API。 CI 作业和各类工具无需下载仓库，就能远程查询提交之间的关系和文件历史。Anthropic 用来定位并撤销问题变更的自动二分查找和回退流水线，也是这样隔离故障的。
• 提交轻量且无锁。 由于提交只叠加增量、不加锁，数百个智能体可以同时提交而无需排队。提交、变基和合并直接在服务器上完成，一次提交的成本取决于变更的大小，而不是仓库的大小。需要跨服务器达成一致的全局分支指针，仅限于主干和发布分支。
• 系统横向扩展。 没有任何服务器或存储节点保存仓库的完整副本，Git 用来存储和传输对象的压缩包，也就是 packfile，也不复存在。
• 本地副本可有可无。 工作副本默认是稀疏的。虚拟化检出会让文件显示在本地文件系统中，但只有进程真正读取时才下载内容，因此作业只为实际用到的字节付出成本。只需要 diff 的作业向 API 请求元数据即可，写入作业无需任何检出就能提交变更。

用变更集取代完整的树

Scion 的基本单位是变更集，即预写日志中的一条记录；预写日志是按顺序记录变更、只追加不改写的日志。Git 的提交指向一棵描述整个目录结构的树，而变更集只列出相对于第一个父节点发生变化的文件，并以内容地址，也就是由文件内容推导出的 ID，来引用每个文件。author、committer、时间戳、提交信息和父节点等元数据存放在 Google Cloud Spanner 中，文件内容则存放在 Google Cloud Storage 中。Scion 只追加数据，保存的是完整且不可变的文件而不是增量差异，因此既不需要 packfile，也不需要分布式锁或跨服务器协调，还免去了从冗长的增量链中重建文件的开销。

分开设置的 author 和 committer 字段，分别记录由哪个人或系统提出变更、由哪个智能体实际完成变更。变更集本身无法回答的问题，例如某一行最后是谁改的，交由服务器计算的派生数据处理：blame 结构、路径历史，以及用于遍历提交图的跳表。每个值都由父变更集递归定义，可以预先计算，也可以按需计算，并隐藏在 API 之后。因此，Anthropic 无需修改客户端代码，就能添加复制检测等索引。

只拉取需要的内容

客户端不再协商 packfile，而是先检查本地存储，从根节点往下请求缺失的树节点，再只拉取所需的文件内容。小请求取代了数 GB 的响应，因此拉取可以断点续传，也便于缓存。缓存分为三层：

1. scion-daemon 运行在每台开发者机器和 CI 节点上，为该机器上的所有进程提供服务。
2. scion-cache 按区域部署，从内存中直接传输可立即写入磁盘的对象。
3. scion-server 是掌握权威数据的一层，缓存未命中时从 Spanner 读取元数据，从 Cloud Storage 读取文件内容。

三层使用同一种 RPC 协议（让一个程序调用另一台机器上功能的方式），但严格的分层规则确保某个区域缓存宕机时，请求不会涌向权威服务器。由于已提交的数据永不改变，任何服务器或缓存都无需相互核对即可直接响应。Scion 也是分阶段上线的：起初只作为元数据服务，专用客户端和传输协议是后来才加入的。

▲ Scion 的三层缓存

成效

据 Anthropic 介绍，缓存命中率超过 99%，CPU 和内存占用仅为原有 Git 镜像方案的两百分之一。这次切换让 CI 腾出了 25% 的 CPU 容量，检出时间也从几分钟缩短到几秒。

前三项数据来自开发者环境；工作树（worktree）是挂在同一仓库下的另一个工作目录。节省下来的时间合计每天超过 1,000 个智能体小时和约 17.5 万个机器小时。

七个人如何在五个月内完成

这个七人团队在每日合并代码量增长十倍的同时，开发了 Scion 和 Antique，并迁移了约六个相关内部系统。团队还推出了内部代码搜索、面向源代码管理的访问管理、用于合入大量已审代码的工具，以及保护单体仓库内敏感目录的细粒度访问规则。过去，这类迁移往往需要大型部门花上好几年。

Claude 承担了很大一部分工作：

• Claude Mythos Preview 在没有人工指示的情况下，重写了把 Git 历史导入 Scion 的流水线的手写原型。新版本内存用量降到原来的二十分之一，运行速度快了四倍，同时遵守了所有隐含的顺序规则。
• Claude 生成了与外部系统隔绝运行的封闭式仿真测试、通过输入随机数据寻找漏洞的模糊测试工具，以及限流系统，使 Scion 成为 Anthropic 测试最充分的代码库之一。
• Claude 还在一直缺少数据库索引的祖先查询中找到了细微的优化点，这类工作通常需要性能专家花数天到数周来调优。

工程师还做什么

Anthropic 表示，工程师依然不可或缺，但他们的工作已上移到架构层面：系统之间的约束，以及其中的权衡取舍。工作的关键之一，是在智能体提出破坏核心规则或绕开系统的方案时，对 Claude 说“不”。迁移期间，曾有多个 Claude 智能体不去查询 Antique，而是逐条扫描 Git 日志来重建拉取请求的历史。智能体之间的对抗式审查也导致了防御性的过度设计，写出了用来回应假想审查意见的多余校验代码。如今，人工审查关注的是意图和架构是否合理，而不是语法；Antique 则通过语义规则，让审查者可以跳过表面性的修改。

部署在 Slack 专用频道中的 Claude 智能体，还负责监看 scion-daemon、scion-cache 和 Antique 合并队列等组件的遥测数据。Anthropic 称它们为这些组件的“超级粉丝”，并认为它们比标准告警更善于发现跨越多份日志和图表的细微异常。

先合并，快验证

开发实践也随之改变。以合并队列为例，它会把变更排成队列，在合入前进行测试。CI 运行期间锁住整个仓库的队列，在成千上万个智能体变更同时涌入时，会成为无法化解的瓶颈。Anthropic 放弃了这种做法，现在接受并发变更，在合并后、部署前自动验证，并让 Claude 迅速解决合并冲突。

这似乎遵循了一个更宽泛的思路：把风险从合并按钮本身移除。自动检查在人工查看之前验证变更，而分阶段发布、先面向少量用户的金丝雀发布以及即时回滚，则能在出问题时限制损害。既然再多的合并前流程也拦不住所有有问题的变更，在智能体的规模下，投资于快速恢复看来是更现实的选择。

Scion 为何只在内部使用

Anthropic 表示，Scion 并不是 Git 的通用替代品。它面向的是由数千名工程师和大批智能体共用的巨型单体仓库。采用它意味着要在代码审查、搜索以及构建和部署流水线中全面放弃 Git；而且 Anthropic 内部在 token（AI 模型处理文本和计费的单位）上的花费，远超大多数企业能为基础设施工具承担的水平。为此，该公司提议从服务器端对 Git 进行现代化改造，采用标准的 RPC 协议和协商接口，让普通 Git 客户端可以与 GitHub、GitLab 等平台配合使用。Anthropic 预计，大多数团队不会马上触及这些限制，但大量用 AI 生成代码的团队终将遇到，而且这一问题会在 6 到 12 个月内在业界变得普遍。

现在该做什么

当智能体写代码的速度超过人和工具的消化能力，瓶颈就会从编写代码转移到源代码管理和 CI。Scion 用服务器端计算、无锁提交、按需拉取和合并后验证来应对。目前需要自建 Scion 的团队还不多，但以下几步值得去做：

1. 算清 Git 给 CI 带来的成本。 一家小型创业公司审查自己的 CI 记录后发现，约 46.5 万次检出仅在 Git 准备环节就用掉了近 1,000 个运行器小时，相当于约 42 天的机器时间，光是等待就花费了 $350-600。
2. 不要强制完整克隆。 只需要 diff 或元数据的作业，可以用稀疏检出或虚拟文件系统，只拉取实际读取的文件。
3. 分别记录提出者和执行者。 把提出变更的人和实际完成变更的智能体分开记录。
4. 把投入放在恢复而非关卡上。 与其在合并前增加更多阻力，不如优先做好合并后测试、分阶段发布和快速回退。
5. 约束负责审查的智能体。 告诉智能体不要添加基于猜测的防御措施或多余的校验层，人工审查则聚焦于意图和设计。

在标准工具真正因规模而失灵之前，不要用自研工具取而代之。不过，推理成本正在快速下降，大约一年内，普通软件公司或许也能以不高的成本，搭建贴合自身工作量的源代码管理层。先从衡量自己的瓶颈正在往哪里转移做起。