Anthropic 自研 Scion 替换 Git，接住 AI 写代码的合并洪流

2026 年 10 月 13 日，Anthropic 在工程博客发布题为《Redesigning source control at Anthropic》的文章，公开了一套自研的版本控制系统 Scion，并确认已经把公司内部那个超大单体仓库（monorepo）从 Git 完整迁到 Scion 上，整个迁移用了五个月。这是少数头部 AI 公司第一次系统性地讲清：当写代码的主体变成 AI 智能体之后，最底层的源码管理工具为什么会先撑不住、又该怎么改。

与 Scion 一起落地的，还有代码审查界面 Antique、代码搜索、源码控制的身份与权限系统，以及一批用来批量管理和合入已审查代码的新工具。官方表示，这些系统都由同一个七人小团队在五个月内建起来并完成迁移，同期仓库的日均合并量还涨了约十倍。文章原文可在 Anthropic 工程博客查看。

Anthropic 给出的数字很直接：2026 年 5 月，内部平均每天合并约 2500 处代码变更；到 9 月，这个数字已经突破每天 3 万笔，四个月涨了约 12 倍。官方认为这还只是开始——“合并代码的潜在需求几乎是无限的”，每去掉一个瓶颈，代码产量马上再上一个台阶。

仓库本身也已经大到反常：仅主分支的历史记录就接近 100GB，压缩后的工作副本超过 25GB。为了让 CI（持续集成）跑起来，Anthropic 每天要做约 2500 万次代码检出，如果按朴素方式拉取，每天的 Git 流量会超过 600PB。为此他们在高峰期维护了几百个内部 Git 镜像，但随着合并量上涨，快照离主线越来越远，diff、blame 这类依赖历史记录的操作在部分克隆上也越来越难维护。

他们的结论是：瓶颈已经从“写代码”转移到了那些为人类开发者设计的开发基础设施上，版本控制、构建和 CI 首当其冲。Git 是为“客户端可能离线、需要完整仓库副本”设计的分布式系统，而 Anthropic 的绝大多数“客户端”其实是永远在线的智能体和自动化任务，这些特性反而成了扩容的阻碍。

Scion 不是把 Git 换个皮肤，而是在几个核心假设上直接反过来做。官方列出了六条设计原则。第一，客户端始终在线：默认服务器随时可达，客户端需要数据时再去取，不再假设要留一份完整仓库。

第二，客户端与服务器不对称：在 Git 里每个客户端都能当服务器，而 Scion 把提交、合并、rebase、查文件历史和 blame 都放在服务器端，客户端只保留一个有上限的本地对象缓存。第三，源码控制变成一项服务：客户端用到的所有查询都通过 API 暴露，CI 作业很多时候根本不需要本地仓库，就能问清“某一行是谁改的”“两个提交什么关系”。

第四，一切都要能水平扩展：仓库数据分散存放，服务器上也没有完整副本，更没有 Git 那种压缩包（packfile），因此不需要维护仓库。第五，提交要便宜、增量、无锁：一次提交或合并的成本只跟改动大小成正比，而不是跟整个仓库大小成正比。第六，工作副本可选、默认稀疏：很多读写可以直接走 API，真正需要落盘时，只按实际读到的文件付费。官方也承认，这套思路参考了大型单体仓库的成熟经验，比如谷歌的 Piper 和 Meta 的 Sapling。

在 Scion 里，工作的基本单位叫“变更集”（changeset），本质是预写日志里的一条记录。它和 Git 的提交很像，但 Git 提交存的是指向整棵代码树的指针，变更集存的是“相对第一个父级改了哪些文件”的清单，外加指向对象存储里压缩文件内容的内容寻址指针。变更集在服务器端创建，创建完就能在任何地方被立即取到。

光有变更集还回答不了“谁最后改了某一行”这类问题，所以 Scion 会基于变更集再算出一批“派生数据”，包括文件 blame、路径历史和提交图的跳跃表。这些派生数据用同一套机制递归计算，可以即时算也可以延迟算，而且因为客户端看不到它们的内部结构，Anthropic 可以在不改客户端的前提下持续优化。

整套系统分成三级：客户端（scn）、节点上的守护进程（scion-daemon）、区域缓存（scion-cache）以及权威服务器（scion-server）。每一层的缓存命中率都超过 99%，且不需要长期保存状态，所以能按需扩容；每一层还严格分层，避免某个区域缓存出问题把上游服务器一起拖垮。客户端协议也不再像 Git 那样先告诉服务器“我已经有什么”，而是只请求自己想要的树和文件，因此没有单个几十 GB 的大包要传，断点可续，CPU 开销也远低于 Git 服务端。

官方公布的收益相当具体。就 CPU 和内存占用而言，Scion 的基础设施规模大约是过去 Git 镜像方案的 1/200；CI 和研究作业检出代码的速度提升了两个数量级，从原来的几分钟缩短到几秒钟；仅 CI 一项就释放了约 25% 的 CPU 容量。此外，客户端和缓存都不需要做仓库维护，作业的生命周期管理也随之简化。

一个能说明“AI 写代码”威力的细节是：团队早年手写过一个把 Git 数据导入 Scion 的管道原型，自认为还不错；直到用上 Claude Mythos Preview 的早期内部快照，让模型重写整个管道——在没有任何额外指令的情况下，它交出了一版内存占用降到 1/20、速度快 4 倍、同时保留所有隐含不变量的实现。

文章还透露了一些工程文化上的变化：所有参与这个系统的工程师现在都认为 Claude 写代码比自己强，但人的价值转向了更高层的判断——理解系统之间的取舍、决定要解决什么问题、以及经常对模型说“不”。团队不再逐行读代码，而是审查改动的意图；他们还用 Claude Tag 给每个组件配了盯指标的“超级粉丝”，像不知疲倦的资深工程师一样刷新图表、找异常。

先说结论：对谁有影响，要看规模——绝大多数团队现在用不上 Scion。官方自己反复强调，Scion 绝不是 Git 的通用替代品，它只对真正巨大的单体仓库有意义——要么有数万名工程师，要么有大量智能体在高速写代码。而且 Anthropic 花 token 做内部工具的能力，也远超一般公司愿意投入的水平，这套方案很难被广泛复制。

但对“已经在大规模用 AI 编程工具、代码量肉眼可见地涨起来”的团队，它是一个值得警惕的早期信号。如何验证自己会不会撞上同一堵墙？可以盯几个可量化的指标：仓库每天的合并量、CI 的检出次数、构建和测试的排队时长，以及是否开始靠内部镜像、快照、稀疏克隆这类临时方案续命。一旦这些数字开始陡增，版本控制、CI、代码审查就会依次成为新瓶颈，而不只是“工具好不好用”的问题。

编辑判断：这件事真正值得关注的，不是“要不要把 Git 换成 Scion”，而是它点出的方向——源码管理可以从客户端为中心，转向服务端提供更完整的接口。对普通开发者和团队来说，短期内的行动是记录并观察自己的代码吞吐变化，而不是急着迁移；真正需要跟进的是 GitHub、GitLab 这类平台会不会采纳类似的服务端优化。

文章最后把边界划得很清楚：Anthropic 不会推出面向大众的 Scion 版本。因为 Scion 与 Git 差异很大，采用它意味着把整条开发生命周期——代码审查、代码搜索、CI——全部换掉，而他们内部的这些组件都高度定制，别的组织很难直接照搬，硬做一个人人都满意的公共版本反而不会好用。

他们更想做的，是把思路贡献给 Git 生态：比如 Git 服务端不必和客户端用同一套工作方式，服务端完全可以提供像 Scion 那样更完整的 RPC；不同代码托管平台甚至可以标准化这套接口，让 Git 客户端学会去对接；协商协议也不一定要保持今天的样子，稀疏克隆和浅克隆可以组合得更好。官方明确表示，希望和 GitHub、GitLab 以及开源社区一起，应对开发者需求的变化。

下一步值得盯三件事：Anthropic 是否会开源 Scion 的部分组件；GitHub、GitLab 是否跟进服务端层面的优化；以及还有哪些重度使用 AI 编程的团队会公开遇到同类瓶颈。从编辑视角看，Scion 是“AI 编程正在改写软件工程底层”的一个具体样本——它不要求你今天换工具，但清楚地说明：当写代码的人从人变成智能体，连 Git 这样的地基也要重新考虑。

本文由 AI 潮汐编辑部基于官方公告与公开资料整理，补充了行业影响、适用场景和行动建议，帮助你在阅读原文前先理解这条信息为什么重要。

原始来源：https://www.anthropic.com/engineering/redesigning-source-control

如发现事实、价格或链接有误，可通过 联系我们 提交更正。