Anthropic 重新设计源码控制
来自 Anthropic Engineering · 期号 2026-10-13
摘要
Anthropic 的代码合并量从 5 月的日均 2500 次涨到 9 月的 30000 次，Git 成了瓶颈。 他们用五个月自建了版本控制系统 Scion，核心思路是：客户端永远在线，不需要本地完整仓库；服务器负责所有计算（diff、blame、合并），客户端只维护本地缓存和文件布局。 Scion 的提交单位是“changeset”，只记录变更文件，不产生 packfile，因此无需锁或跨服务器协调。所有数据内容寻址，服务器可以水平扩展。CI 任务甚至不需要检出代码，直接通过 API 获取 diff。 主分支历史已接近 100 GB，压缩工作副本超 25 GB，日均约 2500 万次代码检出。Scion 的稀疏检出和虚拟化检出机制让客户端只为实际读取的文件付费。 原文是工程复盘，详细介绍了数据结构和扩展策略。
深读
导读 当 AI 代理每天合并三万次代码变更时，Git 成了瓶颈。Anthropic 用五个月自建了版本控制系统 Scion，核心思路是放弃 Git 的离线假设，让客户端永远在线、服务器负责所有计算。这篇工程复盘展示了为代理规模重新设计基础设施时，哪些取舍是关键的。 关键信息 - 2026 年 5 月到 9 月，Anthropic 的日均代码合并量从约 2500 次增长到超过 30000 次，增长了 10 倍以上。 - 主分支历史接近 100 GB，压缩工作副本超过 25 GB，日均约 2500 万次代码检出。 - 七人团队在五个月内同时完成了 Scion 和代码审查工具 Antique 的构建与迁移。 - Scion 基础设施的 CPU 和内存需求仅为之前 Git 镜像基础设施的 1/200。 - CI 和科研任务的代码检出速度提升了两个数量级（从分钟级降至秒级），仅 CI 就释放了 25% 的 CPU 容量。 逐节讲解 瓶颈从编码转向基础设施 Anthropic 发现，Claude 自主编写代码的速度已经远超人类，瓶颈不再是编码本身，而是为人类规模设计的开发者基础设施：版本控制、构建和 CI。Git 的分布式设计假设每个克隆都是完整的离线仓库，但当仓库膨胀到主分支历史 100 GB、日均 2500 万次检出时，Git 的离线优势变成了负担。他们曾用数百个内部 Git 镜像和快照来缓解压力，但随着合并率上升，这些方案越来越难维护。 为代理设计的五项原则 Scion 的设计围绕五个核心原则展开，与 Git 有根本差异： 1. 客户端永远在线：不再假设客户端需要离线工作，数据按需获取。 2. 客户端-服务器不对称：服务器负责 diff、blame、合并等所有计算，客户端只维护本地缓存和文件布局，本地数据需求大大降低。 3. 全面的 API 化：所有源控制查询都通过 API 暴露，CI 任务甚至不需要本地仓库就能获取 diff 或执行二分查找。 4. 一切水平可扩展：仓库数据是分布式的，没有完全物化的副本，没有 packfile，无需仓库维护。 5. 提交廉价、增量、无锁：每次提交、变基或合并都在服务器上完成，成本与变更大小成正比，与仓库总大小无关。工作副本是可选的，默认稀疏检出。 Scion 的数据结构与扩展策略 Scion 的提交单位是 "changeset"，一个预写日志中的条目。与 Git 的 commit 不同，changeset 只存储相对于其第一个父节点变更的文件列表，以及指向 blob 存储中压缩文件内容的内容寻址指针。这种结构使得提交无需锁、无需跨服务器协调，吞吐量极高。 为了回答 "谁最后编辑了这行" 等问题，Scion 从 changeset 中构建了额外的派生数据结构（如文件 blame、路径历史、提交图跳表）。这些派生数据是递归定义的，可…