2026 年 5 月，Anthropic 每天向主分支合并约 2,500 个变更；到 9 月，这个数字超过了 30,000。Anthropic 用 Claude 写软件的程度几乎超过任何一家公司，而开发中最大的瓶颈竟然是 git。今天，Anthropic 的源码管理团队发布了他们如何用自研系统 Scion 替换 git。本质上，这是一个先为 AI 智能体、后为人设计的 git 替代方案。
下面简要说明：git 为什么撑不住了，新系统怎么运作，他们放弃了什么，以及哪些做法适用于只有两三个智能体、而不是成千上万个的普通项目。我有好几个仓库，每个里面都有编码智能体在干活。我不需要 Scion，但它的一部分思路我现在就用得上。
为什么 Anthropic 需要 git 替代方案#
先看文中的规模。仅主分支的历史就接近 100 GB，压缩后的工作副本超过 25 GB。光是 CI 每天就要做约 2,500 万次检出。如果每次都直接拉取，git 流量每天会超过 600 PB。
常见手段他们都试过：shallow 克隆、sparse 克隆、partial clone、预先放在 blob 存储里的种子副本。高峰时他们维护着几百个内部 git 镜像。合并越多，镜像越难运维，种子副本也离 main 的最新提交越来越远。
他们的核心判断是：git 作为分布式版本控制系统，是为离线工作、每人持有完整历史而设计的。而他们的客户端是始终在线的智能体和 CI 任务。git 实际上被当成集中式系统在用，分布式设计反而碍事。
Scion 如何工作#
Scion 假设客户端永远在线，其余设计都由此而来。
- 重活交给服务器。 历史、blame、提交、合并、变基都在服务器上计算。客户端只保留有上限的对象缓存，负责摆放文件、监听文件系统。
- 用 changeset 代替 commit。 工作单元是预写日志（write-ahead log）里的一条记录。它不指向整棵树，而是列出相对第一父提交改动的文件。changeset 在服务器端创建，所以不需要 push。
- 移动分支是一次原子操作。 更新 ref 是对 Spanner 中一行数据的 compare-and-swap，与创建 changeset 分开进行。除
main和发布分支外，他们尽量不用 ref，因为全局状态难以扩展。 - 客户端只要缺的东西。 在 git 里，客户端要告诉服务器自己已经有什么。在 Scion 里，客户端从根树出发，只请求缺少的树和 blob。对象不可变，任何一层缓存都能直接返回。
- 三层分发。 每台机器上的
scion-daemon、按区域部署的内存缓存scion-cache，以及基于 Spanner 和云存储的scion-server。三者协议相同，但层级隔离：某个区域缓存挂了，也不会把请求洪水般压到服务器上。 - 工作副本可有可无。 很多 CI 任务完全不检出，只调用 API。需要副本时，也是部分的或虚拟的：文件只有在被读取时才落到磁盘上。
这些思路并不新，作者自己也承认。超大单体仓库早有先例：Google 的 Piper 和 Meta 的 Sapling。新的是负载：客户端是智能体，数量比人多出几个数量级。
结果数据#
| 指标 | 数值 |
|---|---|
| 每日合并数 | 5 月约 2,500 → 9 月 30,000+ |
| 相比 git 镜像的基础设施规模 | 缩小到 1/200 |
| CI 检出耗时 | 从几分钟降到几秒 |
| CI 的 CPU | 释放 25% |
| 每层缓存命中率 | 99% 以上 |
| 团队与周期 | 7 人，5 个月 |
七个人在五个月里做出了 Scion、代码评审工具 Antique、代码搜索、权限系统和几个相关服务。迁移期间，合并量增长了十倍。开发过程中使用了 Claude：从 git 导入 Scion 的管道先由团队手写原型，随后由早期版本的 Claude Mythos Preview 重写，内存占用降到 1/20，速度提升 4 倍。
他们放弃了什么#
这是我觉得全文最有价值的部分。
它不能替代 git#
作者明确表示，Scion 不适合作为通用的 git 使用。为了采用它，他们不得不替换代码评审、搜索和 CI。由于内部工具定制化程度太高，他们也不打算对外提供。
历史只覆盖主线#
changeset 存储的是相对第一父提交的改动，blame 和路径历史都针对 main 做了优化。这只在基于主干的开发方式下成立。
合并队列没有全局锁#
在这样的速度下，他们无法复现业界标准的合并队列全局锁，转而依靠合并后和部署前的测试。并行的改动有时会冲突，而 Claude 通常在人还没注意到之前就修好了。对我来说，这是最重要的信号：合并队列是按人的节奏设计的，到了智能体时代，换一种机制可能比扩展它更容易。
工程师的工作：对 Claude 说“不”#
据作者说，架构和取舍仍由人来定。工程师最常做的事，是对智能体说“不”。文中的例子包括：智能体不去问评审工具，而是暴力遍历提交历史；在对抗式评审之后，智能体又往代码里堆过多的防御性检查。
评审者关注的是改动的意图，而不是逐行审查。生产环境由独立的 Claude 实例监控，每个组件一个，他们称之为“超级粉丝”。它们读取遥测和日志，发现静态告警漏掉的问题。
可以借鉴什么：不用 Scion，也能让 monorepo git 适配智能体#
我的规模完全不同：几个网站和应用，每个里面一两个智能体。但 Scion 的三个思路在普通 git 上同样适用。
1. 不需要的就不克隆。 partial clone 和 sparse checkout 在 git 里早就有了，智能体很少需要完整历史：
git clone --filter=blob:none --sparse https://github.com/org/monorepo.git
cd monorepo
git sparse-checkout set apps/ios packages/shared大仓库可以用 scalar clone，它从 git 2.38 起随 git 一起发布，会一次性开启这些设置和后台维护。
2. 每个智能体一个独立工作树。 今天有个智能体给 meteohealth.pro 推了一个修复，而我的工作分支上还有一个没推送的提交。它没有动那个分支，而是从 origin/main 新建了一个 worktree：
git worktree add -b fix-key ../site-main origin/main
git -C ../site-main push origin fix-key:main
git worktree remove ../site-main这就是 Scion 那种“廉价、可选的工作副本”的本地版本。
3. 检查自动化，并放在合并之前。 我没有全局锁，这个角色由 pre-push 钩子承担。在 meteohealth.pro 上，它会跑类型检查、翻译检查，以及在 108 种语言和宽度组合下的页头布局检查。智能体没法靠客气地请求绕过它。留给人的工作，和 Anthropic 一样，是判断改动的意图。
我不会照搬的：放弃分支，以及只保留第一父提交的历史。每天 3 万次合并时这个代价合理；每周 30 次合并时，它什么也换不来。
文章没有讲的#
- 源代码，甚至客户端
scn的 API 说明都没有。照着文章没法重建这个系统，作者也没打算让人这么做。 - 同等负载下与其他方案的对比。“缩小到 1/200”和“从几分钟到几秒”都是相对他们自己的 git 镜像方案测得的，没有和 Piper 或 Sapling 比较。
- 其他人什么时候会需要这些。作者预计这类问题会在 6 到 12 个月内变得普遍，并希望与 GitHub、GitLab 和开源社区分享思路。具体会提出哪些服务端 RPC、哪些 sparse 或 shallow 模式，目前还不知道。
如果你在用 git 管理单体仓库，而智能体的数量开始超过人，先检查上面三点，别等到要上镜像的那一步。怎样给智能体一份共享的项目记忆，我在通过 MCP 连接编码智能体的 wiki一文里讲过；多个智能体如何分工又不冲突，见共享 wiki 中的智能体任务认领。
