当 AI 写代码快到 Git 撑不住：Anthropic 自研版本控制系统 Scion 全解读

本文是对 Anthropic 工程博客 Redesigning source control at Anthropic 的中文解读，图片引自原文。

在 Anthropic，写代码已经不再是构建系统和做研究的瓶颈。Claude 能自主迭代研究循环、微优化复杂程序、从零开始构建新服务，速度和规模前所未见。真正的瓶颈，变成了那些为”人类规模”设计的开发者基础设施：源代码管理、构建和 CI。

数字非常夸张：2026 年 5 月，Anthropic 平均每天合并约 2,500 次代码变更；到 9 月，已超过每天 30,000 次。而且增长没有放缓的迹象——合并代码的潜在需求几乎是无限的，每移除一个瓶颈，代码产量立刻进一步上升。

为了支撑这种增长，他们在 5 个月内完成了：自研版本控制系统 Scion 并将 monorepo 从 git 完全迁移、代码评审工具 Antique、代码搜索、一套完善的源码 IAM 权限系统、以及大批量评审代码的落地管理机制。

这里有一个很有意思的闭环：Claude 写代码的能力既是造成这个局面的原因，也是他们能快速造出高质量可扩展系统的手段。

一、Git 为什么撑不住了

先说清楚一个前提：Anthropic 用 Claude 写软件的强度远超几乎所有公司，所以总是最先撞上”人类规模工具”的天花板。他们的 monorepo 规模：

• 仅主分支的历史就接近 100 GB，压缩后的工作副本超过 25 GB；
• 每天为 CI 执行约 2,500 万次代码 checkout（还不算开发环境、agent 沙箱和研究任务）；
• 如果朴素地全量拉取，相当于每天超过 600 PB 的 git 流量。

Git 是去中心化系统：每个 clone 都是一份完整自包含的仓库，可以离线算 diff、读历史和 blame、checkout 任意版本。对绝大多数仓库来说这是正确设计，也是 git 成为标准的重要原因。但 Anthropic 把能用的招都用了——shallow clone、sparse checkout、promisor remotes、内部 git 镜像、blob 存储里的仓库快照（seeds）。巅峰期他们运营着几百个内部 git 镜像，这争取了时间，但随着合并率上升越来越难维护。

关键的洞察是：像大多数公司一样，Anthropic 实际上是把 git 当集中式系统在用（只有一份权威副本），而几乎所有客户端都是天然在线的 agent 和任务。git 为分布式离线工作设计的优秀特性，反而在拖扩展性的后腿。于是他们问了一个根本问题：

如果从一开始就按”agent 永远在线”来设计源代码管理，它会是什么样？

二、面向 Agent 规模的六条设计原则

超大 monorepo 的源码管理是有前人经验的——Google 的 Piper、Meta 的 Sapling。Scion 吸收了这些教训，形成了六条与 git 截然不同的核心原则：

1. 客户端永远在线。 Git 假设客户端离线工作、需要完整仓库副本。Scion 的客户端和协议围绕”服务器永远可达”设计，需要什么数据就拉什么。

2. 客户端-服务器不对称。 Git 里每个客户端都可以是完整的服务器。Scion 里，服务器负责回答文件历史和 blame、创建 commit、执行 merge 和 rebase；客户端只维护有界的本地对象缓存、在磁盘上铺工作副本文件、监听文件变更。客户端自己几乎不计算任何东西，但换来的是本地需要的数据少得多。

3. 全面的源码服务能催生新应用。 客户端使用的所有源码查询（谁改了这行、两个 commit 什么关系）同时通过 API 暴露。CI 任务和工具不再需要本地仓库副本。他们的自动 bisect、自动 revert 流水线，正是靠这种廉价的程序化访问才得以规模化。

4. 一切必须水平可扩展。 仓库数据分布式存储，每个组件独立扩展，服务器上也没有任何完整物化的仓库副本。没有 packfile（git 的压缩对象包），因此完全不需要仓库维护。

5. Commit 必须廉价、增量、无锁。 所有 commit、rebase、merge 都发生在服务器上，没有 push 这个动作。创建一个 commit 的成本必须与变更大小成正比，而不是与仓库总大小成正比。开发流程上不鼓励 refs（分支/标签），因为需要所有服务器达成一致的全局状态是扩展的大隐患。

6. 工作副本是可选的，且默认稀疏。 能不 checkout 就不 checkout：CI 要一个 commit 与 merge base 的 diff？直接问服务器。很多写操作也可以纯 API 完成。协议围绕稀疏 checkout（只含客户端要的目录）和虚拟化 checkout（按需物化文件）设计——真正用到什么，才为什么付费。

三、Scion 是怎么工作的

数据结构：changeset（变更集）

Scion 的工作单元是 changeset，一条写前日志（WAL）里的条目。它存了 git commit 该有的大部分内容，但有个关键区别：git commit 存一个指向 tree 的指针，而 changeset 存的是相对第一父节点的变更文件列表，加上指向 blob 存储中压缩文件内容的内容寻址指针。Changeset 在服务端创建，即时全局可见。

这个结构让 Scion 能以极高吞吐接收变更：没有 packfile 要收、没有锁、没有跨服务器协调、没有 refs 要移动。Scion 技术上支持 refs，但移动一个 ref 只是 Spanner 里一行数据的 compare-and-swap，与创建 changeset 完全解耦。

Changeset 只记录变更，本身无法快速回答”谁最后编辑了这一行”。为此 Scion 从 changeset 构建额外的数据结构：文件 blame、路径历史、commit 图的跳表等，统称为派生数据（derived data）。每类派生数据递归定义——某个 changeset 的值由其父节点的值计算而来。这个通用机制有三个好处：可以随时为加速某种操作新增数据结构类型；每类可以自行选择急切计算还是延迟计算；客户端看不到内部结构，可以独立优化而不影响客户端。

分层缓存架构

一小群 Scion 服务器对外提供源码 API：获取 changeset、算 diff、找 merge base、拉 blob。所有数据内容寻址、写入后不可变，任何服务器都可以无协调地缓存。这些服务器本质上是大缓存，顺便按需计算派生数据并写回 Spanner。

客户端 scn 的协商协议与 git 完全不同：不告诉服务器”我有什么”，只说”我要什么”。从根 tree 出发，客户端检查本地存储缺哪些 tree、递归请求，然后对 blob 重复这个过程。每个请求都是不变的特定对象，任何缓存都能回答——整个架构就像传统的分层缓存（类似 CDN）。过程高效且可恢复（不存在单个多 GB 的 packfile 响应）。稀疏和虚拟化 checkout 不需要任何特殊支持：不想要的 tree，根本不请求。

具体分三层，全部响应相同的 RPC，所以客户端无需感知缓存拓扑：

层级	角色	说明
scion-daemon	节点级守护进程	整个节点共享对象存储，同节点的任务复用大部分对象；从周期性刷新的快照启动
scion-cache	区域缓存	直接从内存以客户端要消费的磁盘格式流式传输对象，不算缺失对象、不做增量压缩
scion-server	权威服务器	缓存未命中时从 Spanner 或云存储读取

严格分层是为了隔离故障域——避免区域缓存故障冲垮上游权威服务器、拖垮整个系统。

成果数据

• 每层缓存命中率保持在 99% 以上，无长驻状态，随时可扩容；
• Scion 基础设施的 CPU 和内存占用比原来的 git 镜像体系小 200 倍；
• CI 和研究任务的 checkout 快两个数量级（秒级 vs 分钟级），仅 CI 就释放了 25% 的 CPU 容量；
• 客户端和缓存都不需要做仓库维护，任务生命周期管理大幅简化。

四、AI 时代造系统的六条经验

小团队快速开发会成为常态

7 个人，5 个月，建成 Scion + Antique（代码评审工具）+ 半打相关系统，并完成整体迁移——同期日合并量还增长了 10 倍。放在过去，这样的系统要一家公司花数年时间、多得多的工程师渐进式迁移。

一个惊人的例子：团队曾手写了第一版 git 到 Scion 的导入流水线原型，自认为不错。后来拿到 Claude Mythos Preview 的内部早期版本，让它整个重写——没有任何额外指令，产出的版本内存占用少 20 倍、快 4 倍，还保留了导入顺序和数据结构的所有隐式不变量。

工程师的价值没有下降，但工作变了

团队所有工程师现在都承认 Claude 写代码比他们强。但工程师提供的，是对系统间组件的高层理解和设计层面的权衡——判断该解决什么问题、要达到什么规模。很多时候，工程师的角色是对 Claude 说”不”：

• Agent 有时会为了满足一个本不该存在的模式而破坏核心系统约束。比如有多个系统试图线性读 commit log 来查找变更何时合入 main，而不是直接问代码评审工具；
• 对抗性评审（adversarial review）很有效，但也会短视，导致 Claude 为假想问题过度设计——某次评审对信任内部服务过于防御，导致 Claude 加了大量验证和复杂性，需要熟练工程师把它拉回来。

团队现在仍然评审每一个变更请求，但看的是变更的意图，而不是逐行读代码。

优化和质量达到了新高度

凭借 Claude 高速产出海量代码的能力，Scion 成了他们见过的测试最充分、防御最完善的代码库之一：为每一个遇到过的非平凡基础设施与源码交互构建了封闭模拟（hermetic simulation）、fuzzing 和复杂的限流。Claude 还随手发现了重要的算法优化——比如祖先查询漏用了一个索引——这类优化专家要花数天到数周的分析调优，而 Claude 做完第二天还能再来一次。

Monorepo 安全的新范式

Scion 从一开始就内建了安全：仓库级的细粒度访问控制、目录级权限（保护最敏感的代码又不失去 monorepo 的好处）。评审工具还能表达复杂的语义审批约束——区分”仅注释变更”和”敏感逻辑变更”——让人工评审聚焦影响最大的变更。

新水平的运维卓越：给每个组件养一个”superfan”

团队用 Claude Tag 为每个组件创建了一个 Slack 频道，让一个 Claude 痴迷地只关注单个组件的健康状态——他们称之为 superfan。有 scion-daemon superfan、scion-cache superfan、Antique 合并队列 superfan。它们接入遥测和日志，像一个无所事事、只会刷新图表寻找异常的资深工程师。传统告警在它们面前显得单一——superfan 能发现细微而新颖的问题。

重新审视所有为人类设计的前提

这个项目让他们重新审视了其他”人类规模”的工作流。比如：merge queue 在 agent 规模下几乎失去意义——当测试运行期间可能有成百上千个变更合入时，CI 到底意味着什么？他们没能有效复刻”全局仓库锁”这个行业标准，转而投入合并后、部署前的自动化测试。并发变更确实会冲突，但 Claude 修复冲突的速度通常比人类发现冲突还快。

五、Scion 不会取代 Git，但思路属于所有人

Anthropic 明确说：Scion 不适合作为 git 的通用替代品。这些概念只对真正巨大的 monorepo（数万名工程师，或海量 agent 高产写代码）才有意义。而且 Anthropic 内部消耗 token 的能力远超任何正常公司愿意支付的水平。

但他们预测这类问题在 6-12 个月内会更普遍，让每家用 git 的公司独自踩坑是工程资源的浪费。所以最有价值的是分享思路，让社区把 Scion 最成功的部分应用到 git 上而不必推翻整个模型：

• git 服务器不必和 git 客户端一样工作——新颖的服务端架构能带来显著扩展性提升；
• git 平台可以提供全面的服务端 RPC，甚至跨 forge 标准化，让 git 客户端学会调用；
• 协商协议可以不是今天的样子，各种 sparse/shallow 特性也可以组合得更好。

最后，原文向 git 社区近二十年的工作致意：Anthropic 的贡献要窄得多——只是分享了 agent 软件开发与这些系统交互的早期视角，希望与 GitHub、GitLab 和开源社区一起，支撑软件开发生命周期与 AI 指数曲线的交汇。We’re all in it together。

六、落地可能性：中型研发组织能搬走什么

先把前提说清楚：我们不是 Anthropic，规模差着好几个数量级，Scion 本身既不可复制、也不该复制。 原文自己都强调 Scion 不适合作为 git 的通用替代品。真正能搬走的是那套判断方法，和几个几乎零成本就能上手的实践。

说明：以下场景均为通用化描述，不涉及任何具体企业、项目或内部数据。

1. 最该先做的一件事：把度量点从”写代码”挪到”交付链路”

Anthropic 的教训是——代码产量上去之后，瓶颈变成了源码管理、构建和 CI。AI 编程助手在中型组织铺开时会遇到同一件事，只是晚一点、量级小一点。

所以在做任何工具改造之前，先建立交付链路的基线度量：

• clone / checkout 耗时、CI 排队时长、构建缓存命中率；
• 每日合并变更数、评审等待时长、变更返工率；
• 主干被阻塞的时长与原因分布。

没有基线，后面所有”提效”都无法被证明，也无法被反驳。

2. 五个可以直接抄的低成本实践

① CI 里用稀疏 checkout / partial clone。 流水线上的绝大多数任务只需要少数几个目录。--filter=blob:none 配合 sparse-checkout，能把 checkout 从分钟级压到秒级，改造成本接近于零。Anthropic 那句”能不 checkout 就不 checkout”，在中型仓库同样成立。

② 源码操作 API 化，不要在流水线里 clone。 自动 bisect、批量变更统计、审计追溯这类需求，直接调代码平台的 API 查询，而不是拉一份完整仓库到本地算。原文的第三条设计原则——“全面的源码服务能催生新应用”——本质就是这件事。

③ 目录级权限 + 代码所有权分层。 把最敏感的模块（凭据与证书相关、对外接口、合规规则引擎、核心算法）划成独立权限域，其余保持开放。这样既保住单仓协作的效率，又不牺牲管控粒度。这是 Scion 从一开始就内建的能力，用现成平台的 CODEOWNERS + 保护规则也能实现大半。

④ 语义化审批约束：按风险分配评审注意力。 区分”仅注释/文档/格式变更”与”敏感逻辑变更”——前者走轻量评审甚至自动通过，后者强制人工、必要时双人。评审者的注意力是最稀缺的资源，平均用力等于没有用力。

⑤ 给核心组件养一个 “superfan”。 这是全文最容易复制的一招：为某个组件单独建一个 AI 值班会话，接入该组件的日志与监控指标，让它只痴迷地盯这一个组件的健康度。传统阈值告警抓不到的那些”细微而新颖”的异常，往往正是这样被发现的。成本极低，而且不需要任何基础设施改造。

3. 评审方式必须跟着变：看意图，不逐行读

当 AI 承担大部分代码编写，逐行 review 既不可能也不必要。评审对象应该变成变更意图 + 影响面 + 测试证据。

同时要警惕原文点出的两个真实反模式，它们在任何组织都会复现：

• agent 为了满足一个本不该存在的模式，去破坏核心系统约束（例如绕开权威服务、直接线性扫描历史）；
• 对抗性评审带来的过度设计——为假想问题加一大堆防御性校验和复杂度，需要有经验的人把它拉回来。

这两个问题的共同解药是同一件事：工程师的价值在于对 AI 说”不”。

4. 强合规 / 内网 / 国产化环境下的额外约束

上述方法论大多与工具无关，但在受监管行业落地时会多出几道硬约束：

• 代码与数据不出域：云端 SaaS 型的编码助手与源码托管常常不可用，需要私有化部署或内网代理，选型范围明显收窄；
• 审计与留痕：每一次由 agent 发起的变更都要可追溯到人——发起人、审批人、评审结论缺一不可，这在合规审计里是硬要求，而不是最佳实践；
• 国产化软硬件栈：工具链在国产 CPU 与操作系统上的可用性需要单独验证，不能假设社区预编译二进制直接可用；
• 变更窗口与灰度：生产系统的发布节奏受业务窗口约束，“合并后、部署前的自动化测试”这类机制要先适配现有发布流程。

这些约束不会改变方法论，但会显著拉长试点周期，规划时要留足余量。

5. 建议的三阶段路线

阶段	目标	主要动作	退出标准
0–3 个月	看得见瓶颈	建立交付链路基线度量；CI 切换到稀疏 checkout；选 1 个核心组件试点 superfan	基线数据连续 4 周可采集；checkout 耗时有可量化下降
3–6 个月	管得住风险	评审按风险分级；敏感目录权限分层落地；补齐合并后-部署前的自动化测试	高风险变更 100% 走强制评审；主干阻塞时长下降
6–12 个月	放得开产量	多 agent 并行开发的冲突治理（变更集抽象 + 自动 revert）；把上述指标纳入效能看板常态运营	并行变更的冲突可被自动发现并修复，无需人工兜底

6. 明确不要做的事

• 不要自研版本控制系统。 投入产出比在任何中型组织都是负的。
• 不要盲目上 monorepo。 规模不够时，它只带来权限与构建复杂度，换不来协作收益。
• 不要在没有基线的情况下宣称提效百分比。 这类数字一旦被追问就无法自证，反而会摧毁后续所有改造的信任基础。

Anthropic 说这类问题会在 6–12 个月内变得更普遍。对中型组织而言，这个时间窗的意义不是”要不要自研”，而是趁瓶颈还没到，先把度量、权限和评审这三件事做对。

---

一句话总结：当 AI 把写代码变成流水，为人类节奏设计的 git、构建、CI 都会逐个成为瓶颈；Anthropic 用”agent 永远在线”这个前提重造了版本控制，而造出它的，正是造成瓶颈的同一个 AI。你的团队离这一天，可能只有 6-12 个月。