AI 编码瓶颈转移至基础设施：Anthropic 自研源控制系统 Scion
在 Anthropic，编程不再是构建系统或进行研究的瓶颈。Claude 能够自主执行研究循环并微优化复杂程序。当前的瓶颈已转移至开发人员的基础设施层面：源控制、构建和 CI。
2026 年 5 月，Anthropic 平均每天合并约 2,500 次代码变更；截至同年 9 月，这一数字已突破每天 30,000 次。预计这种增长速度短期内不会放缓，因为对代码合并的潜在需求几乎是无限的，每消除一个瓶颈都会立即带来代码产出量的进一步增加。
为了支持这种增长，Anthropic 构建了内部版本控制系统 Scion。在同一时间段内，还开发并部署了代码审查界面（称为 Antique）、代码搜索以及丰富的源控制 IAM 系统。Scion 是一个有趣的案例研究：Claude 编写代码的能力是进入该领域的原因，团队借此快速构建了高质量、可扩展的系统来处理海量并发。
Git 在超大规模 Monorepo 下的局限性
随着工作量激增，Anthropic 经常成为第一个看到为人类规模开发的工具开始受到压力的地方。虽然并非所有组织短期内都会遇到这些问题，但使用 AI 编码工具的组织可能会面临同样的压力点。
Git 是一个去中心化系统，每个克隆都是完整独立的存储库，支持离线计算 diffs、阅读历史和 blame。对于绝大多数存储库而言，这是正确的设计。然而，随着 Anthropic 单体仓库的发展，越来越多的工作负载不再适合这个设计空间。压缩后的工作副本容量超过 25GB。在执行代理沙箱和研究工作之前，每天需为 CI 执行大约 2500 万次代码检查，这相当于每天超过 600PB 的 Git 流量。
尽管 Git 提供了浅度克隆、稀疏检出等处理片段化工具，且存在内部镜像和 blob 存储快照等标准解决方案，但在高峰期，Anthropic 使用了数百个内部 Git 镜像来处理负载。随着合并率增加，这些镜像变得越来越难以操作，维持部分克隆上 diff 和 blame 等功能需要大量精力。
Anthropic 注意到，与大多数公司一样，他们实际上将 Git 用作集中式系统，仅有一个权威副本。既然客户端几乎总是在线，团队提出了一个问题：如果从一开始就假设代理始终在线，源控制系统应该是什么样子的？
代理级源控制的设计原则
在构建 Scion 时，Anthropic 借鉴了 Google Piper 和 Meta Sapling 的经验，并基于以下核心原则采用了与 Git 根本不同的方法：
- 客户端总是在线：鉴于几乎所有客户端都是代理和工作节点，Scion 的客户端和协议围绕一个始终可访问的服务器设计，摒弃了 Git 对完整本地副本的依赖。
- 客户端-服务器不对称：服务器负责回答文件历史、归咎问题，创建提交，执行合并和重置等。客户端仅保持有限的本地对象缓存，管理工作副本文件，监控文件系统更改，并提供与服务器交互的工程化方式。客户端自行计算极少，所需本地数据也大幅减少。
- 全面的源控制服务 API：Scion 将所有源控制查询通过 API 暴露。许多内部工具（如自动化切割和反转管道）无需维护本地存储库副本即可运行。
- 水平可扩展性：Scion 中存储库数据是分布式的，组件独立可扩展，没有完整的副本，也没有类似 Git 的包文件，因此不需要存储库维护。
- 廉价、增量且无锁的提交：每次提交、重定位或合并都发生在服务器上。成本与更改大小成正比，而非仓库整体大小。除了主要 ref 或发布分支外，不鼓励使用其他 refs，以避免全局状态同意带来的扩展问题。
- 可选且稀疏的工作副本：为避免每天数千万次的代码检查开销，CI 任务可直接向服务器请求差异。许多写入工作负载可跳过结账并通过 API 运行。协议以稀疏检出的目录为中心，虚拟化检出按需实现文件，客户端只为实际读取的内容付费。
Scion 的技术实现与架构
数据结构：变化集（Change Sets）
在 Scion 中，工作单位是“变化集”，即写入日志的条目。与 Git commit 存储指向树的指针不同，变化集存储相对于其第一个父提交的更改文件列表，以及在 blob 存储中对压缩文件内容的内容地址指针。服务器端创建的变化集可在任何地方立即使用。
这种结构允许接受高吞吐量的变化集，因为没有包文件接收、锁定或跨服务器协调。Scion 技术上支持 refs，但移动 ref 仅是 Spanner 行上的比较和交换，与创建变化集独立。
由于变化集只记录更改内容，无法直接回答“谁最后编辑了一行”等问题。Scion 通过递归定义的机制从变化集中构建额外的“衍生数据”，包括用于文件责怪和路径历史的专用结构以及提交图的跳过列表。这种机制使得添加新类型衍生数据变得容易，可选择急切或延迟计算，且不影响客户端接口。
Scion 的缩放架构
小型的 Scion 服务器机队提供源控制 API（获取变化集、计算差异、查找合并基础等）。所有数据均为内容寻址，一旦存储永不改变，任何服务器均可独立缓存。服务器本质上是大型缓存，可在飞行中计算衍生数据并写回 Spanner。
Scion 的 `scn` 客户端协议与 Git fetch 不同：客户端不告诉服务器它拥有什么，而是针对所需的树木和斑块进行操作。从根树开始，客户端检查本地缺失的对象并递归请求。每个请求针对特定不可变对象，任何缓存均可响应，且过程高效可恢复，避免了多千兆字节的包文件响应。
在舰队中，客户端通过 socket 与 `scion-daemon` 通信。同一节点上的任务复用相同的对象。每个 daemon 从定期更新的快照开始，仅与其区域的树和块缓存服务器（`scion-cache`）交谈。缓存服务器直接从内存传输对象，无需计算缺失对象或执行三角压缩。当缓存缺失对象时，询问权威的 `scion-server`，后者从 Spanner 或云存储读取。
`scion-daemon`、`scion-cache` 和 `scion-server` 响应相同的 RPC，客户端无需知道缓存拓扑。分层隔离故障域，防止区域缓存故障压垮上游服务器。每层保持超过 99% 的缓存命中率，无长期状态，易于扩展。
目前，Scion 基础设施的 CPU 和内存足迹比之前的 Git 镜像基础设施小 200 倍。CI 和研究工作的代码检查速度从几分钟缩短至几秒，释放了大量容量，仅 CI 就实现了 25% 的 CPU 容量增长。客户端和缓存均无需进行存储库维护。
开发经验与启示
Scion 的开发与 Claude Mythos 预览版和 Claude Tag 的内部上市同步进行，这两个版本同时扩大了对 Scion 的需求，并加快了构建速度。
例如，团队最初手写了 Git-to-Scion 摄入管道的原型。在使用 Claude Mythos 早期内部快照重写后，新版本消耗内存减少了 20 倍，速度快了 4 倍。
Anthropic 总结了以下几点经验：
- 小团队快速开发成为常态：七人团队创建了 Scion 和 Antique，而每日代码合并量增加了 10 倍。过去此类迁移通常需要多年时间。
- 工程师角色转变：工程师认为 Claude 更擅长编码，但其价值在于理解高层系统组件和设计权衡。工程师常需纠正 Claude 违反核心约束的行为，或引导其避免过度工程。审查重点从逐行阅读代码转向检查更改意图。
- 质量与优化提升：Claude 编写的代码量大且快，使 Scion 成为测试最充分、质量最高的代码库之一。即使时间表紧张，也能建立模拟每一个非微不足道基础设施互动的封闭模拟环境。Claude 还偶然发现了重要的算法优化。
- Monorepo 安全基础：Scion 支持丰富的访问控制和目录级权限保护，结合能表达复杂语义约束的代码审查工具，确保安全性与管理规模并重。
- 卓越运营新水平：利用 Claude Tag 监控每个组件，创建专注于单一组件健康的 Slack 频道（称为“超级粉丝”），如 scion-daemon 超级粉丝等。它们访问遥测和日志，能发现微妙的新问题。
- 重新考虑先例：传统的合并队列在代理级别意义不大。Anthropic 投资于合并后和部署前的自动化测试，接受同时发生的变化可能冲突，因为 Claude 解决冲突的速度通常快于人类。
对生态系统的贡献与展望
Anthropic 认为 Scion 只是解决 AI 机器人引发的扩展问题的一部分。Scion 并不适合作为通用 Git 替代品，其概念主要适用于真正庞大的单元数据库。由于与 Git 差异巨大，需要配套修改开发生命周期的每个部分（代码审查、搜索、CI），其他组织很难采用。
预计未来 6-12 个月内，此类问题将变得更加普遍。最有影响力的做法是分享理念，让开发者在不脱离整体模型的情况下，将 Scion 的成功部分应用到 Git 上。例如，Git 服务器不必像 Git 客户端那样运作，新的服务器架构可提供显著的扩展改进。Git 平台可以提供类似 Scion 的全面服务器端 RPC，甚至标准化谈判协议。
最后，Anthropic 承认 Git 社区近 20 年为数百万开发者扩展平台的努力。他们的贡献范围较窄，旨在分享关于代理软件开发如何与现有系统互动的早期见解。
