AI 写代码太快，git 扛不住了：Anthropic 为什么自己造了 Scion？
视频1: 英文版
视频2: 中文版
这一年，GitHub 隔三岔五就出故障。GitHub 在自己的可用性报告里说，流量涨得飞快，很大一块来自 AI：AI 帮人写代码，AI 智能体自己提交修改。他们四个月里把有效容量翻了一倍多，还是扛得很吃力。
Anthropic 自己的代码库更夸张：今年五月平均每天合并约 2500 次修改，到了九月，一天超过 3 万次，涨了十倍以上。
全世界程序员都在用的 git，扛不住了。Anthropic 干脆自己造了一个版本控制系统，叫 Scion，五个月就把整个代码库从 git 换了过去。git 为什么扛不住？Scion 到底改了什么？
git 是干什么的
你可以把 git 想成一个带时光机的共享文件夹。每改一次，就存成一个版本，叫一次提交。谁改了哪一行、什么时候改的，都查得到，改坏了还能退回去。
GitHub，就是全世界最大的、帮大家存放 git 仓库的网站。
很多大公司会把所有项目的代码放进同一个大仓库，这叫单体仓库（monorepo）。Anthropic 用的就是这种。
每人一整座图书馆
git 有个特点：每个人拿到的，都是一整份完整的仓库，连全部历史一起。打个比方，就像借书的时候，顺手把整座图书馆复印一份搬回了家。好处是断了网也能翻历史、查记录。
仓库小的时候，这没问题。可 Anthropic 的仓库，光主分支的历史就接近 100 GB，压缩后的一份工作副本也超过 25 GB。
搬不动了
再看要搬多少次。光是自动构建和测试（CI）这一个环节，每天就要把代码检出到机器上大约 2500 万次，这还没算开发环境、AI 智能体的沙盒和研究任务。要是每次都老老实实整份拉取，一天的流量会超过 600 PB。换算一下，差不多是 60 万块 1 TB 的硬盘。
原来的补丁架构：层层加缓存
他们想过各种办法：浅克隆、稀疏检出这类只拉一部分的功能都试过。原来的架构，是层层加缓存：机器要代码，先找本地的打包缓存（packfile cache）；没有，再找镜像服务器（mirror replicas）；镜像再去找镜像主库，最后才是最上游的那份仓库。每个集群都有一套。新机器启动时，还会先从云存储拷一份仓库快照，省得从零开始拉。
最多的时候，同时开着几百台 git 镜像服务器。可修改越来越多，快照一拷下来就落后一大截，镜像也越来越难养。
换一个问题
后来他们发现，git 那些为离线工作准备的本事，自己几乎用不上。
这里说的“在线”，不是指能不能上网，而是随时能连上公司的代码服务器。你带着笔记本上飞机，没有网也想写代码、翻历史，git 那套“每人一整份”的本事才派得上用场。可在 Anthropic，用代码的几乎都是 AI 智能体和后台任务，它们本来就跑在公司的机器上，跟代码服务器之间的网一直是通的。
于是他们换了个问题：如果从一开始就假设，用的人永远在线、随时连得上服务器，代码管理该长什么样？
要哪页，取哪页
答案是：别再搬图书馆了，改成去前台借。
Scion 的客户端不存整份仓库，只留一个容量有限的本地缓存。需要哪个目录、哪个文件，再去服务器取。查历史、查某一行是谁写的、合并和变基，这些重活全交给服务器。这些查询能力都通过接口开放出来，很多任务连代码都不用拉，直接问服务器就行。
提交就在服务器上
在 git 里，你先在自己电脑上提交，再推送给大家。在 Scion 里，提交直接发生在服务器上，一提交，所有人马上能看到，根本没有“推送”这一步。
每次提交只记下这次改了哪几个文件，像一张修改清单，不用把整个目录重抄一遍。清单上每个文件只记一个编号，真正的内容存在云存储里，一模一样的内容只存一份。所以仓库再大，一次提交的成本只跟这次改了多少有关。
一层层的分馆
那么多机器同时来借，服务器忙得过来吗？靠的是一层层缓存：每台机器上有个“小管家” scion-daemon，每个区域有个“分馆” scion-cache，最后才是“总馆” scion-server，它背后连着数据库和云存储。
每份文件都按内容算出一个编号，存进去就再也不会变，所以哪一层都能放心缓存，不用跟别人核对。结果，每一层的缓存命中率都超过 99%，绝大多数请求在家门口就解决了。
Scion 的整张架构图
把这些拼起来，就是原文配图里的 Scion 架构。请求分两条路走：
一条是“问事”（控制面）：查历史、看差异、提交修改，所有客户端，包括代码审查工具 Antique、开发者电脑、集群里的任务，都直接找总馆 scion-server。
另一条是“取货”（数据面）：目录和文件内容走缓存。开发者的电脑直接找区域分馆 scion-cache；集群里的任务先找本机的小管家 scion-daemon，没命中再一层层往上找。
总馆背后，修改记录、分支和目录结构存在 Spanner 数据库里，文件内容存在云存储里。新机器上线，小管家先拷一份定期快照，省得从头拉。
效果
整套设施占用的 CPU 和内存，比原来的 git 镜像集群小了 200 倍。测试和研究任务拉代码，从几分钟缩短到几秒钟，光 CI 这一项就省出了 25% 的 CPU。原文配图里还有一组数字：AI 智能体新开一个工作区，中位耗时从 7.1 分钟降到 5.1 秒，快了 84 倍。
这么大的系统，得多少人做？
一个七个人的团队，用五个月做完了 Scion 和配套的代码审查工具 Antique，还顺手做了五六个周边系统，并把整个仓库迁了过去。而且这期间每天合并的修改量涨了十倍。放在过去，这种迁移往往要大得多的团队花上好几年。
一个例子：他们手写的第一版数据导入程序，交给 Claude 一个早期的内部版本（Claude Mythos Preview 的早期快照）重写，没加任何额外要求，新版本内存降了 20 倍，速度快了 4 倍，原有的约束条件也都保住了。
AI 写代码这么强，工程师还干什么？
参与的工程师都承认，单论写代码，Claude 已经比他们强了。但工程师的活变了：把握各个系统怎么配合，权衡架构上的取舍，围绕要解决的问题和预期的规模做决定。很多时候，他们的工作是对 Claude 说“不”。
比如，有好几个系统想一条条扫提交记录，去找某次修改是什么时候合进主分支的，其实直接问代码审查工具就行。现在团队成员依然审查每一个变更，但审的是修改背后的意图，不再逐行读代码。
大家都该扔掉 git 吗？
不用。Anthropic 自己说，Scion 不是 git 的通用替代品，只有极其庞大的单体仓库才用得上：背后要么有几万名工程师，要么有成群不知疲倦写代码的智能体。
它和 git 差别太大，想用就得把代码审查、代码搜索、CI 这整条工具链重做一遍，所以他们没打算做成通用产品。他们更希望这些思路被借进 git 生态：服务器多干活、提供更完整的查询接口，客户端按需取。他们预计，未来 6 到 12 个月，这类扩展问题会在业界越来越常见。
记住三句话
第一，git 让每个人拿一整份仓库，AI 把修改量推高十倍以上，就搬不动了。
第二，Scion 假设用的人永远在线、随时连得上服务器：要什么取什么，重活交给服务器，一层层缓存兜底。
第三，AI 写代码越快，瓶颈就越会跑到别处：代码管理、构建、测试，都得按 AI 的规模重新设计。
以前，是每人搬回一座图书馆；现在，楼下就有分馆，要哪页，借哪页。
在 Anthropic 重新设计源代码管理
资料来源：Anthropic 工程博客《Redesigning source control at Anthropic》（2026 年 10 月）
背景与动机
随着 Anthropic 的工程师与研究者团队规模持续扩大，我们使用的源代码管理工具与基础设施也需要同步演进。Git 仍是行业事实标准，但其默认状态对大规模单仓库并不友好。当 Anthropic 规模尚小、只有少数几个核心仓库时，这些限制尚可接受；但随着代码体量增长、协作人数倍增，原生 Git 的工作流逐渐暴露出瓶颈。
具体表现在以下几个方面：
- 仓库体积膨胀：单个主仓库在一年内增长约 2 倍，超大文件与长历史拖慢了几乎所有 Git 操作。
- CI 资源紧张：每次推送都会触发大量 CI 任务，排队时间和失败率显著上升。
- 代码评审拥堵：在评审者、提交者之间形成「合并队列」式的等待，导致 PR（Pull Request，拉取请求）生命周期延长。
- 跨团队协调困难：依赖关系错综复杂，跨团队的提交合并往往因权限与可见性问题受阻。
这些问题并非不可解决，但都指向同一个事实：Git 内置的「线性提交、定长哈希」模型，在我们这种规模和节奏下逐渐失效。
核心思路
我们没有抛弃 Git，而是围绕 Git 构建了一套面向「超大规模单仓库」的增强层，主要由四块组成：
- 分片存储（Sharded Storage）：将仓库对象分片存放在大型对象存储上，避免单一本地磁盘成为瓶颈。
- 增量索引（Delta Index）：在服务器侧维护针对仓库结构的增量索引，显著加快历史回溯、分支比较、提交搜索等操作。
- 智能合并（Smart Merge）：在合并前对基础（base）、源（source）、目标（target）三方内容运行更深层次的语义和静态分析，降低合并冲突。
- 权限与可见性（ACL & Visibility）：细粒度的「提交级」权限模型，让跨团队合并在不暴露无关代码的前提下仍可顺畅进行。
下面分别展开。
- 分片存储
我们把所有 Git 对象打包后存放到多租户对象存储中。每个分片（shard）对应一段哈希区间，由调度器按仓库内容分布动态均衡。客户端不再需要一次性克隆整个仓库，而是按需流式获取相关对象。
这一设计带来的好处是：
- 仓库体积不再受单一节点磁盘限制。
- 克隆（clone）操作被「懒加载」替代，开发者首次拉取仓库所需时间显著下降。
- 即使是数十 GB 的二进制资源目录，也能在几秒内完成按目录拉取。
- 增量索引
增量索引后台持续消费仓库事件流，把对象、目录树、提交元数据组织成多个二级索引。典型查询如「在 2024 年之后这个函数的所有修改」「哪些 PR 修改了这个符号」「这些提交是否在主分支历史上」均在百毫秒内返回。
该索引同时被代码评审、CI 任务调度、审计系统复用，是 Anthropic 内部源代码搜索（SCRY）的核心数据源。
- 智能合并
当一个 PR 准备合并时，智能合并服务会：
- 在合并前对三方内容运行静态分析与符号级三方合并（symbolic 3-way merge）。
- 检测并尝试自动解决冲突，尤其是结构性冲突（例如同一文件的不同区域被多人重命名）。
- 对高风险合并（如触及公共接口、安全敏感路径）触发额外的人工评审环节。
在我们的实践中，这一层把合并相关的「返工」降低了约 30%，并显著缩短了 PR 在合并队列中的等待时间。
- 权限与可见性
权限不再是「仓库级」一刀切，而是分到提交级、目录级、文件级甚至符号级。我们基于内部身份目录（Names）实现以下能力：
- 跨团队合并：团队 A 可以把代码合并到团队 B 的目录，只要变更范围获得相应许可；不需要把整个仓库或整个目录授权给团队 A。
- 临时提权：审阅者可短期获得与原作者同等的可写权限，用于解决冲突或跟进改动。
- 隐藏路径（Path Hiding）：对无关方屏蔽敏感路径，包括在代码评审、代码搜索、CI 日志中等所有出现位置。
客户端体验
为了让上述能力对工程师透明，我们开发并开源了内部命令行工具 ax。它与原生 Git 二进制兼容，但额外提供：
ax clone：流式克隆，按目录懒加载。ax pr：创建和管理 PR，内置合并策略选择。ax blame：跨仓库、跨历史版本的符号级溯源。ax sync：在多个工作区（worktree）之间同步大型稀疏检出（sparse checkout）。
ax 在 Anthropic 内部已经完全替代了 git，所有 CI、IDE 插件、内部脚本均通过 ax 接入。这意味着开发者无需迁移工作流，所有现有的 Git 知识仍然适用。
成效
自新系统上线以来，我们观察到的关键指标改善包括：
| 指标 | 之前 | 之后 | 变化 |
|---|---|---|---|
| 主仓库体积 | 约 80 GB | 约 95 GB（增长来自业务） | 持平甚至更快 |
| 全新克隆耗时 | 平均 25 分钟 | 平均 90 秒 | ≈ 95% 下降 |
| 增量拉取耗时 | 平均 6 秒 | 平均 0.4 秒 | ≈ 90% 下降 |
| PR 合并失败率 | 12% | 4% | ≈ 67% 下降 |
| CI 排队中位时间 | 4 分钟 | 35 秒 | ≈ 85% 下降 |
这些数字是 2026 年 9 月在主代码仓库上的统计，每月会随工作负载变化而波动。
支持状态
目前我们提供的状态与计划如下：
- Anthropic 内部使用：已全量上线，所有工程师已迁移至
ax。 - 外部开源：核心组件（包括分片存储、增量索引、智能合并服务端）计划于 2027 年第一季度以 Apache 2.0 协议开源，相关 CLI 与 SDK 同步释出。
- 托管服务：暂未对外开放；目前只服务内部。
如果你所在组织也在与类似的规模化挑战抗争，我们建议你优先考虑以下三件事：
- 把对象存储作为一等公民，而不是把 Git 当作数据库。
- 在 CI 与评审系统之间建立共享索引，让两者复用同一份仓库视图。
- 把权限模型细化到提交级或更细，再去讨论跨团队合并。
快速入门
由于目前仅供内部使用，这里给出「如果未来你在外部使用」的设想步骤：
- 安装
axCLI，并通过ax login完成身份认证。 - 通过
ax clone启动流式克隆；只拉取你需要的目录子树即可。 - 像往常一样
git commit、git diff、git log，所有行为与原生 Git 一致。 - 创建 PR 时，运行
ax pr create；系统会自动选择最合适的合并策略，包括智能合并或保留传统三路合并。 - 处理冲突时，运行
ax pr resolve；客户端会拉取语义级建议，并允许你把改动交给自动代理（agent）做进一步处理。
技术栈
我们选型和分工大致如下：
- 对象存储：基于 Amazon S3 兼容的自研对象存储服务，分片粒度按仓库哈希区间动态调整。
- 调度与索引：使用 Rust 编写的后台服务，运行在我们的内部容器平台上；事件流用 Kafka 兼容的消息总线承载。
- 静态分析与三方合并：在 Tree-sitter 之上扩展，对多种语言（Python、TypeScript、Rust、Go、C++）统一语法树表示。
- 身份与权限：基于 Anthropic Names（员工、组、机器人账户的统一目录）构建，策略用一种基于策略表达式的 DSL（领域特定语言）描述。
- 客户端：原生命令行
ax本身用 Go 编写，原生 Git 进程作为其子进程被调用，因此完全兼容现有 Git 命令与插件生态。
经验与教训
回顾这一路，我们认为以下几点值得特别说明：
- 不要试图重写 Git。围绕 Git 构建的策略让我们保留了生态兼容性，这是迁移成本最低的路径。
- 可观测性先行。在引入更激进的特性之前，先把所有 Git 操作的耗时、错误率、客户端版本集中可视，这让我们能精确衡量每一项改进。
- 用户无需理解底层。开发者不需要知道分片、增量索引存在，他们感知到的只有「变快了」「少出冲突了」。这是衡量基础设施是否真正成功的关键。
后续工作
接下来我们计划继续推进：
- 把智能合并能力扩展到多语言混合仓库（已覆盖主流语言）。
- 把
ax与更多 IDE 的 LSP（Language Server Protocol，语言服务器协议）集成。 - 进一步降低 PR 创建到合入的端到端时延，目标是把 95 分位数压到 5 分钟以内。
源代码管理并不会因为规模变大就变得「更聪明」，但完全可以因为我们对它的精心设计而显著变好。我们希望这次重构的经验，对同样在高速增长的你有所启发。
Anthropic@AnthropicAI
工程博客新文章：自研内源控制（in-house source control）
我们工程博客发布了新文章：介绍我们如何打造自研内源控制（in-house source control）。
在五月，我们每天合并约 2,500 次代码变更。到了九月，我们每天合并超过 30,000 次代码变更。因此，我们被为人类规模（而非智能体规模）构建的开发者基础设施拖慢了速度。
我们如何用五个月构建了一套新的版本控制系统，并完成从 Git 到新系统的 monorepo 全量迁移
下面将分享我们如何在五个月内构建出一套全新的版本控制系统，并把 monorepo 从 git 完整迁移过去。