大家好，我是小林。
前两天，Anthropic 官方博客发了一篇文章，叫《Redesigning source control at Anthropic》，翻过来就是「重新设计 Anthropic 的源码管理」。
文章讲的事情挺炸裂。Anthropic 自己造了一套版本控制系统，叫 Scion，只花了 5 个月，就把公司的大仓库从 Git 整个迁了过去。
为什么要这么折腾？原因藏在一组数字里。
2026 年 5 月，Anthropic 平均每天合并大约 2500 个代码变更。到了 9 月，每天合并的变更超过 3 万个，四个月涨了十多倍。
▲ 2026 年 1 月到 9 月每天合并的代码变更数
代码合并得这么猛，最先扛不住的是 Git 这一层。
更有意思的是，Anthropic 现在大量代码都是 Claude 写的。说起来也挺讽刺，把 Git 压垮的，正是 Claude 写代码的速度。
看到这估计有同学坐不住了，那我们是不是也得赶紧把 Git 扔了？
下面就跟大家聊聊在 Anthropic 里 Git 为什么扛不住、Scion 是怎么设计和实现的，以及这件事对普通团队意味着什么。
────一、Git 为什么扛不住了？────
以前开发里最慢的一环是写代码。现在这一环交给 Claude，速度一下子上了好几个档次，写代码反倒成了最不用操心的事。
这就像一条流水线，前面的产量突然翻了十几倍，后面的质检、打包还是按原来的速度在干，货自然就堵在半路了。对 Anthropic 来说，堵住的地方就是源码管理、构建和 CI。
而且这种堵，短期内只会越来越严重。想合并代码的需求几乎没有上限，每疏通一个环节，代码产量马上又会往上涨一截。
那问题来了，Git 用了这么多年，全世界都在用，怎么到 Anthropic 这里就不灵了？
得先从 Git 的设计说起。
你可以想象一个团队里，每个人手里都抱着一整套完整的项目档案，所有历史版本都在。断网了也不怕，想查谁改过哪行、想看两个版本的差别、想切回半年前的代码，自己在本地就能搞定。
这就是 Git 的分布式设计。每次 clone，你拿到的都是一个完整、独立的仓库。对绝大多数仓库来说，这个设计没毛病，这也是 Git 能成为行业标准的一大原因。
可 Anthropic 的仓库已经越来越不适合这种设计了。
主分支光历史就将近 100 GB。检出一份工作副本，也就是磁盘上能直接打开的那套代码，压缩后也超过 25 GB。光是 CI，每天就要检出代码大约 2500 万次，这还没算开发环境、Agent 沙箱和研究任务。
如果每次都老老实实全量拉取，每天的 Git 流量会超过 600 PB。
讲真，这个数字已经离谱到很难想象了。每人手里抱一整套档案，在人少的时候很方便。要是每天有几千万个「人」来领档案，档案室直接就被挤爆了。
那他们一开始就没想过补救吗？当然想过。
只拉最近历史的浅克隆、只拉部分目录的稀疏检出、内部搭 Git 镜像分摊压力、提前打好仓库快照，这些大仓库的常见招数，Anthropic 全用过。高峰期，他们内部跑着几百个 Git 镜像来分担负载。
这些办法确实帮他们争取了时间，但合并速度越来越快，维护也越来越难。快照是隔一段时间才刷新一次的，合并一快，两次刷新之间主分支又往前跑了一大截，新任务拿到的快照就越来越旧。
浅克隆这类只拉了一部分的仓库，本来就缺一部分历史。想让 diff、blame 这些要翻历史的操作在上面不出错，也越来越费劲。
退一步看，Anthropic 其实和大多数公司一样，一直把 Git 当成中心化系统在用。全公司只有一份权威的仓库，大家都往上面推代码。
而且他们的客户端，几乎全是 Agent 和各种任务，这些东西天生就是在线的。
那 Git 最引以为傲的离线能力、每人一整套完整仓库，对他们来说就没什么用了，反而成了扩展的拖累。
于是他们问了自己一个问题，如果从一开始就按「Agent 永远在线」来设计源码管理，它应该长什么样？
────二、给 Agent 用的版本控制长啥样？────
到了 Agent 写代码的时代，很多关于软件开发的老假设都在变。
Anthropic 自己造的版本控制系统 Scion 干脆顺着这些变化来设计，一共定了 6 条原则，我一条条跟 Git 对照着讲。
第一条，客户端永远在线。
Git 假设客户端会离线工作，所以需要一份完整的仓库。
Scion 反过来，假设服务端随时都连得上，客户端需要什么数据，用到的时候再去拿。
第二条，客户端和服务端分工不对等。
在 Git 里，你本地 clone 下来的仓库和服务器上那份没有本质区别，拿出来就能当服务端用。Scion 把重活全交给服务端，查文件历史、查 blame、创建提交、合并、rebase，都在服务端完成。
客户端这边只干几件轻活，维护一个有大小上限的本地缓存，把文件铺到磁盘上，再盯着哪些文件被改了。
简单来说，客户端自己算不了多少东西，但换来的好处是，本地需要的数据少了很多。
第三条，源码管理要做成一个完整的服务。
在 Git 里，一个 CI 任务或者工具想问仓库一个问题，比如这行代码最后是谁改的，两个提交之间是什么关系，要么自己在本地维护一份仓库，要么指望代码托管平台恰好提供了对应的 API。
Scion 把客户端用到的所有查询都开放成了 API，很多任务根本不需要本地仓库。
比如 Anthropic 内部有自动 bisect（二分查找是哪个提交引入了问题）和自动 revert（回滚出问题的提交）的流水线。这类工具要不停地向仓库发问，要是每次都得先在本地维护一份仓库，在这个规模下基本跑不起来。
第四条，所有东西都要能水平扩展。
前面说了，高峰期他们跑着几百个 Git 镜像，非常吃资源。更要命的是，每个镜像都得完整装下一整份仓库。仓库一旦大过单台镜像机器的磁盘或内存，镜像加得再多也白搭，因为哪一台都装不下。
Scion 的仓库数据是分布式存储的，每个组件都能单独扩容。任何地方都没有一份完整展开的仓库，服务端也没有。
第五条，提交要便宜、增量、不加锁。
在 Git 里，你先在本地提交，然后 push 出去分享。在 Scion 里，每一次提交、rebase、合并都直接发生在服务端，也就不存在 push 这一步了。
看到这估计有同学就问了，所有提交都压在服务端，服务端扛得住吗？
这就是这条原则的重点。创建一个提交的开销，必须只跟这次改动的大小有关，跟整个仓库多大无关。
比如你只改了 3 个文件，服务端就只处理这 3 个文件，不能因为仓库有 100 GB 就跟着变慢，不然服务端肯定跟不上。至于怎么做到不加锁，后面讲变更集时会说到。
第六条，工作副本可以没有，有也只拉需要的部分。
仓库这么大，CI 每天又要检出几千万次，他们希望能不检出就不检出。
比如一个 CI 任务需要某个提交和它的合并基点（两条分支最近的共同祖先，通常就是分支当初从主干分出来的那个提交）之间的 diff，直接找服务端要就行，用不着把代码拉下来。写操作也一样，很多写入任务也可以全程走 API。
真要把文件放到磁盘上，也有两种省法。一种是稀疏检出，只拉任务点名要的那几个目录。另一种叫虚拟化检出，哪个文件被读到了，才把哪个文件的内容拉到磁盘上。任务实际读了多少，就只为多少付出代价。
────三、Scion 是怎么做的？────
原则讲完，再来看具体实现。这里我挑三个最关键的设计来聊。
第一个，提交只记改了什么。
在 Git 里，一个提交（commit）记录的是一个指向整棵文件树的指针。也就是说，每个提交都能直接告诉你，此刻整个项目长什么样。
Scion 的基本单位叫变更集（changeset），你可以理解成一本只能往后追加的流水账里的一条记录。
变更集里也有作者、提交说明、父提交这些 Git 提交里常见的信息。最大的区别在文件这块，变更集只列出这次比上一个提交改了哪些文件，每个文件再带一个指针，指向它存在对象存储里的内容。
变更集都在服务端创建，一创建好，所有地方立刻就能看到。
这种结构有什么好处？吞吐量可以做得非常高。收一个变更集，不用处理 Git 那种压缩打包文件，不用加锁，也不用在服务器之间协调。
看到这估计有同学就问了，变更集只记了改了什么，那「这行代码最后是谁改的」「哪些提交动过这个文件」这种问题，怎么快速回答？
确实，光靠变更集本身答不快。所以 Scion 会基于变更集，再算出一些额外的数据结构，比如专门服务 blame 和文件历史的索引，他们统称为「派生数据」。
派生数据是一步步递推出来的。
比如有三个先后的提交 C1、C2、C3，算 C3 的文件历史时，不用从第一个提交开始翻，直接拿 C2 已经算好的结果，再把 C3 这次改的文件补进去就行。而且客户端看不到这些数据的内部细节，服务端想加新索引、想优化，都不用动客户端。
第二个，数据存进去就永远不变。
Scion 有一小组服务器，提供客户端需要的各种源码管理 API，比如获取变更集、计算 diff、找合并基点、拉取文件内容。
这里有个关键设计，所有源码数据都是按内容寻址的。简单来说，每份数据的名字是根据它的内容算出来的，内容哪怕改一个字，算出来的名字也跟着变。所以同一个名字背后永远是同一份内容，存进去就不会再变。
不会变有什么用？任何一台服务器都可以放心缓存它，不用和其他服务器核对。
所以这些服务器可以水平扩展，彼此之间几乎不需要协调。说白了，这些服务器本质上就是一组大缓存，只不过还能现场计算派生数据。
第三个，客户端只说要什么。
Scion 的客户端叫 scn，它拉代码的方式和 Git 很不一样。
Git 拉代码时，客户端会先和服务端协商，告诉服务端「我已经有哪些东西了」，服务端再算出你缺什么，打包发给你。
scn 不这么干。它从来不告诉服务端自己有什么，只说自己要什么。从根目录开始，本地缺哪些目录就要哪些，一层层往下，最后再要文件内容。
这么做有什么好处？每个请求要的都是一个具体的、永远不会变的对象，所以随便哪个缓存都能回答。也不会再有一个好几个 GB 的大包，中途断了能接着拉。至于只拉部分目录，客户端不想要哪些，不去要就行了。
基于这一点，他们搭了一套三层缓存。
最底下是集群里每个节点上跑的 scion-daemon，同一个节点上的任务要的对象大多一样，存一份大家共用。往上是每个区域的一组 scion-cache，最顶上是权威的 scion-server。下层缺了数据，就找上一层要。
有意思的是，这三层对外用的是同一套接口，理论上谁都能越级直接找谁要数据。但他们硬性规定只能一层层往上找，图的是隔离故障。他们最怕某个区域的缓存出了问题，大量请求一下子全涌到最上面的 scion-server，把整个系统拖垮。
最后看效果，数字相当亮眼。
每一层缓存的命中率都在 99% 以上。和以前的 Git 镜像设施相比，Scion 用到的 CPU 和内存只有原来的两百分之一。
CI 和研究任务检出代码快了两个数量级，从几分钟变成几秒，光 CI 一项，就省出了 25% 的 CPU 容量。而且客户端和缓存都不需要做仓库维护，省心了很多。
────写在最后────
回到开头那个问题，我们也要扔掉 Git 吗？
Scion 只是应对 Agent 规模化写代码的一种解法，拿来给面临类似挑战的团队做参考可以，但它绝对不适合拿来当通用的 Git 替代品。
为什么？有两个原因。
第一，这些设计只对真正巨大的单体仓库有意义，要么有几万名工程师，要么有成群的 Agent 在疯狂写代码。
第二，Anthropic 本身就很特殊。他们愿意花在内部的 token，远远超过任何一家正常公司会花的量。这样做，一是为了解决自己的开发需求，二是为了测试 Claude 的能力。所以他们有条件、也舍得为自己专门造一套系统，一般公司没必要这么折腾。
对我们大多数团队来说，Git 照样好用，没必要跟风。
但这件事真正值得琢磨的，其实不在 Scion 本身。
Anthropic 等于提前给我们演示了一遍，当 Agent 写代码的速度上来以后，会发生什么。
写代码不再是瓶颈，瓶颈会往后挪，挪到源码管理、构建、CI、代码评审这些原本按人类速度设计的环节上。
还有一点挺扎心。参与 Scion 开发的工程师都承认，Claude 写代码已经比自己强了。
但系统怎么设计、要扛住多大的规模，这些判断还是得靠人。
这可能也是我们接下来最该练的本事。
参考链接：https://www.anthropic.com/engineering/redesigning-source-control
推荐阅读：