AREX Feed Article
Anthropic 公开自研版本控制系统 Scion：5 个月把 monorepo 完全迁离 git
10 月 13 日，Anthropic 在工程博客发布文章，其官方 X 账号 （北京时间 10 月 14 日凌晨 0:36）。文章披露，Anthropic 自研了内部版本控制系统 Scion，并在 5 个月内把公司的 monorepo（单一代码仓库）完全从 git 迁出；同期交付的还有代码审查界面 Antique、代码搜索和一套源代码管理 IAM（身份与访问管理）系统。截至发稿，公告帖在 X 上已获得 7,500 余次点赞、78 万余次浏览。
按 Anthropic 的说法，推动这次重构的是合并量的增长：2026 年 5 月，公司 monorepo 日均合并约 2,500 个代码变更；到 9 月，这个数字超过 30,000，约为 4 个月前的 12 倍。博客开篇写道，「写代码已不再是构建系统或做研究的瓶颈」，现在的瓶颈变成了为人类规模（而非 agent 规模）构建的开发者基础设施：源代码管理、构建和 CI（持续集成）。这些内部数字与迁移、工具交付情况均为公司自述，未经独立核实。
近 100GB 的主分支历史与每天 2,500 万次代码检出
博客给出了一组负载数据，说明原来的工作方式为什么越来越吃力：monorepo 主分支的历史接近 100GB，压缩后的工作副本超过 25GB；仅 CI 每天就要执行约 2,500 万次代码检出，还没算开发环境、agent 沙箱和研究任务；如果朴素地抓取，这些检出每天会产生超过 600PB 的流量。博客所附的图表还把 9 月 9 日标注为单日合并 30,401 个。
他们试过这个领域常见的手段：浅克隆、稀疏检出、按需拉取对象的部分克隆，以及把内部 git 镜像和对象存储里的仓库快照（seeds）结合起来用。高峰期，Anthropic 运行着数百个内部 git 镜像。但合并率继续上升之后，这些镜像越来越难维护：seeds 在两次刷新之间会离 main 分支的尖端越来越远；diff、blame（逐行追溯改动者）这类依赖历史的操作，在部分克隆上也越来越难以维持。
促使他们换思路的是一个观察：多数公司把 git 当作中心化系统使用，只维护一份权威副本；而 Anthropic 的绝大多数客户端是 agent 和任务，按定义始终在线。让 git 在分布式、离线场景下表现出色的那些性质，在仓库变大后反而成了扩展的负担。于是他们换了一个设计前提：假设从第一天起 agent 就永远在线，据此重新设计源代码管理。
博客也承认这个负载并不典型：Anthropic 使用 Claude 写代码的规模远超几乎所有其他公司，所以更早感受到为人类规模设计的工具的局限；博客认为，其他使用 AI 编码工具的团队不久也会遇到类似压力。超大 monorepo 的源代码管理也有先例，博客点名 Google 的 Piper 和 Meta 的 Sapling，称 Scion 参考了这两套系统积累的经验。
假设「客户端永远在线」：Scion 的六条设计原则
博客列出了六条原则。其一，客户端永远在线：不假设需要完整仓库副本，客户端按需向服务端取数据。其二，客户端与服务端不对称：文件历史、blame、创建 commit（提交）、merge（合并）、rebase（变基）都在服务端完成；客户端只维护一个有界本地对象缓存，负责落盘工作副本、监听文件系统变化。它自身能计算的东西很少，换来的是本地数据需求大幅降低。
其三，一个全面的源代码管理服务可以支撑很多新应用：客户端用到的所有查询都通过 API 暴露，CI 任务在多数情况下不再需要本地仓库；Anthropic 的自动 bisect（二分定位问题提交）和 revert（回滚）流水线就建立在这种廉价的编程访问之上。其四，所有组件必须水平扩展：仓库数据分布式存放，任何地方（包括服务端）都没有完全物化的副本，也没有 packfile（git 压缩对象的打包形式）的等价物，因此不需要仓库维护。其五，commit 要便宜、增量、无锁：每次 commit、rebase、merge 都发生在服务端，成本必须随变更规模而不是仓库规模增长；除主 ref 和发布分支外，Scion 的开发流程不鼓励使用 refs（指向提交的指针，比如分支和标签）。其六，工作副本可选、默认稀疏：协议围绕稀疏检出和按需物化的虚拟化检出设计，任务只为实际读取的文件付费。
从 changeset 到三层缓存
在 Scion 里，工作单元叫 changeset（变更集），是预写日志（write-ahead log）中的一条记录。它与 git commit 的结构差异是关键：commit 存的是指向 tree（目录树）的指针，changeset 存的是相对第一父提交的变更文件列表，外加指向对象存储中压缩文件内容的内容寻址指针。changeset 在服务端创建、立即可用；没有 packfile 要接收，不需要加锁或跨服务端协调，也没有 refs 要移动。移动一个 ref 只是对 Spanner 单行的一次 compare-and-swap（原子比较交换），而且与创建 changeset 分开进行。
只有变更列表，回答不了「这行代码最后是谁改的」。Scion 因此会从 changeset 构建「派生数据」（derived data）：文件 blame、路径历史、commit 图的跳表等，全部通过一个递归的通用机制计算，某个 changeset 的派生值由其父提交的派生值推出。这样做有三个好处：新增一类派生数据很容易；每类数据可以选择即时计算或延迟计算；客户端看不到这些结构的内部实现，服务端优化它们不必改客户端。
这套基础设施分三层。客户端（scn）连接本机节点上的 scion-daemon；daemon 从一个定期刷新的快照启动，只与本区域的 scion-cache（保存树和文件内容的区域缓存）通信，缓存直接以 daemon 将要消费的磁盘格式，从内存里流式发送对象；缓存未命中时，再向权威的 scion-server 请求，由它按需读取 Spanner 或云存储。三层响应同一套 RPC（远程过程调用），客户端不需要知道缓存拓扑；层级之间被严格隔离，避免某个区域缓存的问题波及上游服务端。博客称，这套系统每一层的缓存命中率都超过 99%。
这套架构带来的结果：Scion 基础设施的 CPU 和内存占用缩减到原先 git 镜像体系的 1/200；CI 和研究任务检出代码快了两个数量级，从分钟级降到秒级；仅 CI 一项就带来 25% 的 CPU 容量收益；客户端和缓存都不需要做仓库维护。检出协商不涉及客户端已有的内容，只处理客户端想要的树和文件：每个请求针对一个永不改变的对象，任何缓存都能应答，过程可中途恢复，也不存在单个数 GB 的 packfile 响应。
7 人团队的其余交付：Antique、代码搜索与目录级权限
同期交付的工具里，代码审查界面 Antique 之外还有代码搜索和一套源代码管理 IAM。这套 IAM 支持仓库级访问控制，也能把权限作用到单个目录，让敏感代码在不脱离 monorepo 的前提下单独设限；审查工具还能表达复杂的语义审批约束，区分「只改注释」和「敏感的逻辑变更」，让人类审查者把精力集中在影响最大的变更上。
合并队列也换了一套做法：博客承认，没能有效复制行业标准的全局仓库锁，于是转而投入合并后与部署前的自动化测试。代价是并发变更可能冲突，但博客称 Claude 修复这些冲突通常比人类识别冲突还快。
完成这一切的核心团队有 7 个人：他们同时构建了 Scion、Antique 和约六个相关系统，完成了整个迁移，而当时每日合并量还在上涨。博客的另一张图表显示，截至 9 月，1 月以来写进 Scion 与 Antique 代码库的变更累计 12,257 个。
「工程师的角色是告诉 Claude 不行」
博客称，参与这套系统的所有工程师现在都认为，Claude 写代码比自己更强；工程师的价值在于对系统间高层组件的理解和设计取舍：决定要解决什么问题、要达到什么规模。他们的工作经常是告诉 Claude「不行」：agent 有时会为了迎合某个模式而违反核心系统约束。比如迁移期间，多个系统试图通过线性读取 commit 历史来查某个变更何时合入 main，而不是去询问代码审查工具；对抗性审查（adversarial review）虽然有效，也可能视野过窄，工程师要把 Claude 从为假想担忧堆砌校验的过度工程中拉回来。团队仍会审查系统的每一个变更请求，但检查的重点已经从逐行代码转到变更的意图。
博客里还有一个具体的例子：最早手写的 git-to-Scion 摄取管线，被一个早期内部版本的 Claude Mythos Preview 整体重写后，内存占用降到原来的 1/20、速度提升 4 倍；重写时没有追加指令，重写后的版本还保持了摄取顺序与数据结构上的全部隐式不变量。博客还提到，Scion 的构建与 Claude Mythos Preview、Claude Tag 在内部上线的时间大致重合，它们同时放大了对 Scion 的需求，也加快了构建速度。
监控同样交给了 Claude：团队大量使用 Claude Tag，为每个组件建立 Slack 频道，让 Claude 持续盯着单个组件的遥测和日志、刷新图表、查找异常，内部把这类 Claude 称为「superfans」。博客称，superfans 能发现传统告警难以捕捉的细微、新出现的问题。博客还称 Scion 是他们测试最充分、防护最完备的代码库之一：为每一种非平凡的基础设施与源代码管理交互都建立了完全隔离的模拟环境，另有模糊测试和精细限流；Claude 还发现了一个祖先关系（ancestry）查询的算法优化（其中漏掉了一个索引），博客称这类工作通常需要专家分析和调优数天到数周。
Scion 不面向通用场景，Anthropic 把思路分享给 git 生态
博客明确了 Scion 的适用范围：它不是 git 的通用替代品，这些概念只对真正巨大的 monorepo 有意义，要么有数万名工程师，要么有成群的 agent 大量产出代码；而且 Anthropic 的情况有其特殊性：它愿意为内部使用投入的 token，远超其他企业理性上愿意花的水平。博客表示，把 Scion 做成对广泛组织普遍有用的形式很困难：它与 git 差异太大，采用者要迁移开发生命周期的每一环，还得自备代码审查、代码搜索和 CI；内部版本的这些组件高度定制，其他组织难以直接采用。
他们因此选择把细节公开。博客认为，最有影响力的做法是分享这些思考，让开发者在不脱离 git 整体模型的前提下，把 Scion 中最成功的部分用到 git 上。博客列举的方向包括：git 的服务端不必和客户端以同样的方式工作，新的服务端架构已经能带来明显的扩展性改进；git 平台可以提供类似 Scion 的完整服务端 RPC，甚至以标准化方式跨不同的代码托管平台（forge）提供，让 git 客户端学会与之对话；协商协议也不必维持现状，稀疏和浅克隆的各种特性可以更好地组合。博客最后表示，希望与 GitHub、GitLab 和开源社区合作，支持开发者不断变化的需求。