10 月 13 日，Anthropic 工程博客发布《Redesigning source control at Anthropic》。文章披露，Anthropic 的 monorepo 日均合并量从 2026 年 5 月的约 2,500 次增长到 9 月的 30,000 次以上，Git 因此成为最大的开发瓶颈。一个 7 人团队用 5 个月自研了版本控制系统 Scion，并把整个 monorepo 从 Git 迁移过去。本文梳理 Git 在这一规模下失效的具体位置、Scion 的设计原则与架构、迁移过程中工程师角色的变化，以及次日前 Meta 工程师 Rain 提出的署名争议。
这次迁移最值得讨论的是瓶颈移动的方向。
代码生成成本下降一个数量级之后，首先失效的是为人类速度设计的基础设施：版本控制、构建、CI、合并队列。Anthropic 的数字很直接：日合并量 4 个月增长 12 倍，CI 每天 checkout 约 2,500 万次，按 Git 的方式全量拉取，每天的流量会超过 600 PB。几百个 Git 镜像只能延缓问题，不能解决问题。
结论是，agent 写代码的速度一旦超过某个阈值，团队的工程重心就会从「怎么写得更快」转到「怎么让下游接得住」。Anthropic 是第一个公开撞上这堵墙的公司，但不会是最后一个，他们自己的估计是 6 到 12 个月内这类问题会变得普遍。
2,500 到 30,000：Git 在哪里先撑不住
Git 是分布式设计：每个 clone 都是完整的仓库，可以离线计算 diff、查历史、做 blame。对绝大多数仓库，这是正确的设计。
Anthropic 的 monorepo 已经超出了这个设计的适用范围。main 分支历史接近 100 GB，CI 每天约 2,500 万次 checkout 还不包括开发环境、agent sandbox 和研究任务，按 Git 方式全量拉取每天的流量超过 600 PB。
shallow clone、sparse checkout、promisor remote、内部镜像、blob storage 里的仓库快照，这些大仓库的标准手段 Anthropic 都用过。问题在于合并速度上来以后，快照距离 main 的最新提交越来越远，在部分 clone 上维持 diff 和 blame 正常工作的成本也越来越高。
原文里有一个关键观察：和多数公司一样，Anthropic 实际上把 Git 当作中心化系统用，只有一个权威副本；而几乎所有客户端都是 agent 和任务，天然在线。Git 为离线、分布式协作设计的特性，在这个场景下反而成了扩展的阻力。
Scion 的五条设计原则
基于「客户端永远在线」这个前提，Scion 定下了几条和 Git 根本不同的原则。
客户端与服务端不对称。 Git 的每个客户端都能充当完整的服务端。Scion 的服务端负责回答历史和 blame 查询、创建提交、执行 merge 和 rebase；客户端只维护有上限的本地对象缓存、在磁盘上铺工作副本、监听文件变化。客户端能独立完成的计算很少，换来的是本地数据量大幅下降。
所有查询都开放成 API。 在 Git 下，CI 任务想知道「这一行最后是谁改的」或「两个提交是什么关系」，要么维护一份本地仓库，要么依赖托管平台的私有接口。Scion 把客户端用到的所有查询都暴露为 API，很多任务因此根本不需要本地仓库。原文提到，内部的自动 bisect 和自动 revert 流水线，没有这种低成本的程序化访问就无法规模化运行。
每个组件都能水平扩展。 仓库数据分布式存储，任何地方都不存在一份完整物化的仓库，服务端也没有。没有 packfile，也就不需要仓库维护。
提交必须廉价、增量、无锁。 所有 commit、rebase、merge 都在服务端完成，不存在 push。创建提交及更新下游数据结构的成本，必须和变更大小成正比，而不是和仓库大小成正比。Scion 还刻意弱化 ref，除了 main 和发布分支基本不用，因为需要所有服务器达成一致的全局状态迟早会成为扩展瓶颈。
工作副本是可选的，并且默认稀疏。 CI 任务需要某个提交和 merge base 之间的 diff，直接向服务端要；很多写操作也能完全通过 API 完成，不需要 checkout。确实需要文件时，协议以 sparse checkout 和按需物化文件的虚拟化 checkout 为中心，客户端只为实际读取的内容付费。
changeset 与 derived data
Scion 的基本单位是 changeset，即预写日志中的一条记录。Git 的 commit 指向一棵完整的树；changeset 只记录相对第一个父提交改了哪些文件，以及指向 blob storage 中压缩内容的内容寻址指针。
这个结构让 Scion 能以极高的吞吐接收 changeset：没有 packfile 要接收，没有锁和跨服务器协调，也没有 ref 要移动。确实需要移动 ref 时，只是对一行 Spanner 记录做一次 compare-and-swap，和创建 changeset 相互独立。
只记录变化，就无法直接回答「这一行最后是谁改的」。Scion 的做法是从 changeset 上构建额外的数据结构：文件 blame、路径历史、提交图的 skip list。这类数据统称 derived data，用同一套通用机制计算，每种数据都递归定义，一个 changeset 的值由其父提交的值算出。
这套机制有三个直接收益：新增一种索引的成本很低；每种数据可以选择立即计算或延迟计算；客户端看不到这些结构的内部实现，服务端可以随时优化而不影响客户端。Scion 上线后陆续新增过复制检测、基于路径的文件搜索等多种索引。
三级缓存的 checkout 架构
文件内容的拉取和工作副本的物化，数据量远大于元数据查询，Scion 为此单独设计了协议。
Git 的 fetch 协商是客户端告诉服务端「我已经有什么」，服务端计算差量后打包返回。Scion 反过来，客户端只请求「我缺什么」：从根树开始检查本地缺失的树，递归请求，再对 blob 重复这个过程。每个请求针对的都是内容寻址、永不变化的对象，任何一级缓存都能应答。请求天然可断点续传，不存在单个数 GB 的 packfile 响应；sparse 和虚拟化 checkout 也不需要特殊支持，客户端不请求不需要的树即可。
部署上分三级：
- scion-daemon：每个节点一个，同一节点上的任务共享对象，从定期刷新的快照启动。
- scion-cache：区域级缓存，直接从内存以 daemon 可用的磁盘格式流式返回对象，不做差量计算和 delta 压缩。
- scion-server：权威服务端，按需读取 Spanner 或云存储。
三级响应同一套 RPC，客户端不需要知道缓存拓扑，但分级被严格执行，目的是隔离故障域，避免某个区域缓存失效后把上游服务端一并压垮。
结果上，各级缓存命中率都在 99% 以上，整套基础设施的 CPU 和内存占用比原来的 Git 镜像体系小 200 倍；CI 和研究任务的 checkout 从分钟级降到秒级，CI 整体省下 25% 的 CPU。
7 个人、5 个月：工程师的角色变化
Scion 和代码评审工具 Antique，加上另外五六个相关系统，由 7 人团队在 5 个月内完成开发和全量迁移，期间日合并量增长了 10 倍。原文的判断是，以往一家公司做这种迁移需要多年和多得多的工程师。
原文给了一个具体例子。Git 到 Scion 的数据导入流水线，第一版基本由人手写，团队自认质量不错。拿到 Claude Mythos Preview 的早期内部快照后，团队让它重写整条流水线，没有给任何额外指示，结果内存占用降低 20 倍、速度提升 4 倍，并且保住了导入顺序和数据结构上所有的隐含约束。
更有参考价值的是工程师实际在做什么。参与项目的工程师都认为 Claude 写代码比自己强，但系统间的边界、设计层面的取舍、目标规模的判断，仍由工程师负责。原文的说法是，工程师的工作很多时候是对 Claude 说「不」，典型场景有两类：
- 违反系统约束去套用旧模式。 迁移期间，多个系统试图线性扫描提交日志来查找某个变更何时合入 main，而正确做法是查询代码评审工具。
- 对抗式评审导致过度设计。 Anthropic 大量使用 adversarial review，但它有时只盯局部。有一次评审对另一个内部服务的可信度过度警惕，Claude 随之加了大量不必要的校验和复杂度。
团队仍然评审这个系统的每一个变更请求，但评审对象从逐行代码变成了变更的意图。
运维上，团队在 Slack 里为每个组件开了专门频道，让一个 Claude 实例只盯一个组件的健康状态，内部称为 superfan：scion-daemon superfan、scion-cache superfan、Antique merge queue superfan。它们能读遥测和日志，像一个除了刷图表没别的事可做的资深工程师。传统告警仍然保留，但原文称 superfan 能发现告警覆盖不到的细微异常。
merge queue 在 agent 规模下失效
这一节篇幅不长，但对其他团队的冲击可能最大。
原文明确指出，一个规范的 merge queue 在 agent 规模下已经没有意义：测试还没跑完，就可能有几百上千个变更合入。业界标准的做法是在 merge queue 上加全局仓库锁，Anthropic 无法有效复现这套机制，转而投入合并后测试和部署前自动化测试。代价是并发变更可能冲突，原文的处理方式是交给 Claude 修，修复速度比人类发现冲突还快。
这意味着「合并前保证主干绿色」这条许多团队默认的纪律，在足够高的合并频率下会被放弃，质量关口后移到部署前。
Mononoke 署名争议
10 月 14 日，Rain 发文《Anthropic's Scion is heavily inspired by Mononoke》，文章同样上了 HN 首页。Rain 在 2017 到 2018 年参与构建 Meta 的源码控制服务端 Mononoke，也参与过 Sapling 的开发。
Rain 把 Anthropic 对 derived data 的描述，和自己 2022 年描述 Mononoke 的文字并排放在一起：同样的概念名称，同样用来加速 blame 这类操作。Rain 的判断是，相似程度远超「洞见相近」。Anthropic 原文只在设计原则部分提到 Google Piper 和 Meta Sapling，称借鉴了它们「来之不易的经验」，Mononoke 完全没有出现。Rain 认为这「接近剽窃」，整篇文章给人的印象是 Claude 设计了这一切，而实际上是 Meta 团队近十年前提出的设计被 Claude 重新应用了一遍。
Rain 也明确说，不反对 Anthropic 照搬 Mononoke 的设计，开源本来就是为了传播好的想法。真正的问题在署名：Mononoke 是开源项目，在所有大模型的训练集里，Rain 提到，问 Opus 5.5 或 GPT-6 Astra 有哪些先例，两者都会立刻指出和 Mononoke 的相似之处。在 Rain 看来，大模型参与系统设计以后，给前人署名比以前更容易，也更重要。
这场争议和 Scion 的技术价值不冲突，但它指出了 AI 辅助设计的一个结构性风险：模型会大量复用训练集里已有的设计，而产出方不一定知道、也不一定说明这些设计从哪来。
对其他团队的参考价值
Anthropic 自己说得很清楚：Scion 不是 Git 的通用替代品，只适用于有数万工程师或大量 agent 同时写代码的超大 monorepo；它也不打算开源，因为脱离 Anthropic 内部的代码评审、代码搜索和 CI，Scion 很难单独使用。他们的建议是把 Scion 中有效的部分搬到 Git 体系里：Git 服务端不必和客户端同构，托管平台可以提供完整的服务端 RPC，协商协议可以重新设计，sparse 和 shallow 特性可以更好地组合。
按团队当前所处的阶段，可以参考的部分不同：
| 团队状态 | 可参考的做法 |
|---|---|
| agent 刚接入，合并量没有明显变化 | 暂不需要动版本控制；先统计合并量和 CI 排队时间，建立基线 |
| 合并量已明显上升，CI 排队变长 | 优先 sparse checkout、按需拉取；给 CI 和工具提供查询仓库的 API，减少本地 clone |
| merge queue 成为瓶颈 | 评估合并后测试和部署前测试，接受并发冲突，用 agent 处理冲突 |
| agent 大规模参与开发 | 代码评审从逐行转向审意图；用专职 agent 盯单个组件的运行状态；采用 AI 产出的设计时核对已有先例并署名 |
Scion 这件事的核心信息是：agent 把代码产量推高一个数量级以后，团队真正要重新设计的是代码之外的整条交付链路。