Anthropic 公开内部版本控制系统 Scion

AI 公司 Anthropic 于 10 月 13 日在工程博客上公开了内部版本控制系统 Scion。公司表示，已用五个月将存放全部代码的单体仓库从 git 完全迁移到 Scion。起因是合并量。据 Anthropic 介绍，每日合并的代码变更在 2026 年 5 月平均约为 2500 次，到 9 月已超过 3 万次。公司公布的图表显示，仅 9 月 9 日一天就合并了 30401 次变更。Anthropic 源代码管理团队在文中写道：“编码已不再是构建系统或开展研究的瓶颈。”团队判断，如今的瓶颈是源代码管理、构建和 CI 等按人类规模设计的开发基础设施。

首先是仓库体量超出了 git 的设计范围。据 Anthropic 介绍，仅主分支的历史就接近 100GB，压缩后的工作副本超过 25GB。CI 每天进行约 2500 万次代码检出，这一数字还不包括开发环境、智能体沙箱和研究任务。如果直接拉取，每天的 git 流量将超过 600PB。公司用过浅克隆、稀疏检出、内部 git 镜像以及存放在 blob 存储中的仓库快照，高峰时运行了数百个内部 git 镜像。随着合并速度提升，快照与主分支末端的距离越拉越远，在部分克隆上维持变更历史和逐行作者追溯也变得越来越麻烦。

方向的转变源于对使用方式的观察。git 是分布式系统，每个克隆都能离线读取历史并检出任意版本。Anthropic 指出，公司和大多数企业一样，一直把 git 当作只有一份权威副本的集中式系统来用，而且几乎所有客户端都是按定义始终在线的智能体和任务。团队提出的问题是：如果从一开始就以智能体始终在线为前提来设计源代码管理，会是什么样子？团队还借鉴了谷歌 Piper 和 Meta Sapling 留下的经验。

在 Scion 中，大部分工作由服务器承担。服务器负责文件历史和逐行作者查询、创建提交以及执行合并和变基，客户端只管理容量有限的本地对象缓存和工作文件。工作单元是预写日志中的一个条目，即变更集（changeset）。变更集只记录相对于第一个父提交改动的文件列表，以及指向 blob 存储中压缩文件内容的内容寻址指针。由于没有 git 的打包文件，也没有锁和服务器之间的协调，吞吐量很高。移动分支等引用的操作被单独拆分为对谷歌 Spanner 中单行数据的比较并交换。即使在服务器上，也不存在完整展开的仓库副本。

检出通过三层缓存完成。每个节点上的 scion-daemon 向区域级 scion-cache 请求对象，缓存未命中时再上溯到读取 Spanner 和云存储的 scion-server。据 Anthropic 介绍，每一层的缓存命中率都超过 99%。按 CPU 和内存计算，Scion 基础设施比此前的 git 镜像基础设施小 200 倍。CI 和研究任务的检出从分钟级缩短到秒级，速度提升约 100 倍，仅 CI 就释放了 25% 的 CPU 容量。

打造这套系统的主力大多也是 Claude。据 Anthropic 介绍，一个七人团队开发了 Scion、代码审查工具 Antique 以及六个左右的相关系统，并在五个月内完成了迁移。在此期间，每日合并量增长了 10 倍。团队开始开发 Scion 的时间，恰好与 Claude Mythos Preview 和 Claude Tag 在公司内部开放的时间重合。年初由人工几乎手写完成的 git 到 Scion 数据导入管道原型，交给 Claude Mythos Preview 的早期内部版本重写后，在没有额外指令的情况下，得到了一个内存占用减少 20 倍、速度快 4 倍的版本。公司表示，新版本还保留了导入顺序和数据结构方面的隐性约束。

人的工作转向了设计与否决。参与开发这套系统的所有工程师如今都认为 Claude 写代码比自己更好，但系统之间的架构和设计取舍仍由工程师决定。团队写道：“我们常常发现，工程师的角色就是对 Claude 说‘不’。”有好几个系统试图通过从头线性读取提交日志来查找变更何时合并到主分支，而不是去询问代码审查工具；还有一次，对抗式审查对另一个内部服务过度不信任，导致 Claude 添加了不必要的校验和复杂度。团队成员至今仍审查每一个变更请求，但关注的是变更意图，而不是逐行阅读代码。在运维上，团队把 Claude 部署在 Slack 频道里，让它专注盯住单个组件的健康状况，并称之为“超级粉丝”。

工作方式的前提也在改变。在测试运行期间可能有数百乃至数千次变更合并的环境里，Anthropic 无法复现锁住整个仓库的合并队列，转而投资于合并后和部署前的自动化测试。公司表示，并发变更可能产生冲突，但 Claude 通常在人类察觉冲突之前就已修复。METAL 曾报道 Anthropic 向所有候补用户开放 Claude Code 项目，而这篇文章展示了在最大量使用这一编程智能体的公司内部，最先卡住的是什么。METAL 查证的 Anthropic 官方 X 帖子将瓶颈原因概括为无法承受智能体规模而非人类规模的开发基础设施，该帖发布半天内浏览量就超过 140 万次。

Anthropic 没有公布对外发布 Scion 的计划。公司写道：“Scion 绝不适合作为 git 的通用替代品。”并表示它只对拥有数万名工程师或成群编写代码的智能体的超大型单体仓库才有意义。公司还指出，采用它需要迁移包括代码审查、代码搜索和 CI 在内的整个开发生命周期。公司预计同类问题将在未来 6 到 12 个月内变得普遍，因此表示将与 GitHub、GitLab 和开源社区合作，推动 git 服务器像 Scion 一样提供全面的服务器端远程调用，并改进协商协议和稀疏功能。在智能体每天推送 3 万次变更的时代，决定生产力上限的不再是写代码的速度，而是承载和传输代码的基础设施如何设计。