Theo 解读 Scion：Anthropic 面向智能体规模的源代码管理系统

我在开始写代码之前就已经使用 Git，但我的开发方式已经改变。Git 和 GitHub 的发展围绕的是成本高昂的人类代码修改与人工审查。当许多智能体并行工作时，我开始发现托管平台和底层源代码管理流程都存在摩擦。

Anthropic 描述了另一种应对方式：自研源代码管理系统 Scion。该公司表示，每日合并的改动从 5 月约 2500 个增长到 9 月超过 3 万个，并在五个月内完成了单体仓库迁移。这是一个针对特殊工作负载重新思考基础设施的案例。

Anthropic 认为，编码本身已不再是主要瓶颈；源代码管理、构建和 CI 越来越成为瓶颈。我把相关目标称为降低合并按钮的风险：改动进入前进行验证，之后限制影响范围，用较小用户群测试版本，并让回滚变得可行。

在自己的 T3 Code 项目中，我最近一次工作就合并了 50 多个 PR，并使用 nightly 版本在更广泛发布前测试结果。这是我在自己项目中的经验，不是适用于所有团队的标准。周围的验证措施和撤销错误版本的能力，是我能够这样工作的关键。

大型组织自建源代码管理系统并非史无前例。Meta 围绕 Mercurial 和堆叠变更构建了系统；Graphite 等工具又把其中一些工作流带到 GitHub。大型仓库和特殊流程可能使不同于行业默认的选择变得合理。

Anthropic 表示，它在构建 Scion 的同时，还开发了代码审查服务 Antique、代码搜索、访问控制和其他基础设施。文章重点介绍 Scion。公司承认，其大量依赖智能体的工作负载比较特殊，但预计随着更多组织使用编程智能体，类似压力会逐渐出现。

普通的 Git 克隆是自包含的：可以离线读取历史、计算差异并工作。Anthropic 表示，其主分支历史接近 100 GB，压缩后的工作副本超过 25 GB，CI 每天大约执行 2500 万次检出。如果简单地每次都拉取全部数据，每天会产生超过 600 PB 的流量。

浅克隆、稀疏检出、镜像和仓库快照都曾有所帮助，但 Anthropic 说，最终它需要运营数百个镜像，而且随着合并频率上升，运营变得困难。快照逐渐落后于主分支最新状态，部分克隆上依赖历史的操作也需要更多维护。公司实际上是在把分布式系统当成集中式系统使用。

它的客户端主要是本来就需要网络连接的智能体和作业。因此 Anthropic 提问：如果明确假设服务器始终可访问，源代码管理会是什么样？这个假设适合其工作负载，却放弃了 Git 对许多其他仓库很有价值的特性：本地离线工作。

Scion 的客户端和服务器职责不对称。服务器回答历史与 blame 查询、创建提交，并执行合并和 rebase；客户端维护有大小限制的本地对象缓存、在磁盘上布置文件并监控工作副本。客户端能独立完成的计算更少，但本地需要保存的数据也少得多。

同样的源代码管理操作也通过 API 暴露。需要合并基点或差异的 CI 作业，有时可以直接询问服务器，不必维护自己的仓库。Anthropic 表示，这让自动二分查找和回滚管道等内部工具能够在其规模下实际运行。

Scion 将仓库数据分布存储，使各组件可以独立扩展。该设计避免在每台服务器上物化完整仓库，也不使用 Git 式的 pack 文件。Anthropic 希望创建提交和处理后续数据的成本随改动大小增长，而不是随整个仓库大小增长。

提交、rebase 和合并都在服务器执行，因此本地提交之后不需要再单独 push。工作流不鼓励使用除 main 或发布分支以外的大多数 ref，以减少共享可变状态。目标是让创建变更既廉价又增量化，而不必让大量并行智能体等待同一把锁。

工作副本不是必需的。作业可以只请求差异，或通过 API 完成某些写入。稀疏检出只请求选定目录；虚拟化检出则按需物化文件。每天检出数百万次时，避免获取不需要的文件可以产生很大差异。

工作单元是 changeset，即预写日志中的一条记录。Git 提交通常指向完整的树；Scion 的 changeset 则列出相对于第一父节点发生变化的文件，并通过内容寻址指针指向对象存储中压缩后的文件内容。服务器负责创建 changeset。

这种方式让系统无需重新打包仓库，也不必让每台服务器围绕 ref 移动进行协调，就能接收变更。changeset 记录了哪些内容改变，但它本身不能高效回答所有历史查询。Scion 因此另建数据结构，用于 blame、路径历史和提交图遍历。

Anthropic 将这些结构称为派生数据。每一种类型都根据 changeset 父节点的值递归计算。系统可以添加新类型、选择预先计算或按需计算，并在不改变客户端的情况下优化实现。Anthropic 表示，它已添加复制检测和按路径搜索文件等索引。

API 边界在这里很重要。拥有完整本地 Git 仓库的客户端可以直接查看数据；使用服务器 API 时，服务端则可以在接口后面优化查询和索引。代价是客户端依赖服务，以及服务选择暴露哪些操作。

一小组 Scion 服务器回答 changeset、差异和合并基点等查询。数据按内容寻址且不可变：一个对象存储之后，缓存可以复用它，无需互相协调来检查内容是否改变。服务器可以计算派生数据，并将结果写回 Spanner。

针对文件内容和工作副本，Scion 使用自己的获取协议。客户端不是向服务器说明自己已经拥有的全部内容，而是请求缺失且确实需要的树，然后请求 blob。每个对象都能独立寻址，因此请求可缓存、可恢复，不需要一次返回巨大的 pack 文件。

在计算集群中，一个守护进程在同一节点的作业之间共享对象缓存，并从定期刷新的快照启动。区域缓存服务器按守护进程使用的格式流式传输对象。缺失对象时，请求可以到达权威 Scion 服务器，再由后者访问 Spanner 和云存储。

守护进程、区域缓存和服务器使用相同的 RPC，但系统有意采用分层拓扑来隔离故障。Anthropic 希望区域缓存故障不会压垮权威服务。开发者机器使用区域缓存；CI 和集群作业则可以受益于节点本地守护进程。

Anthropic 报告说，每一层的缓存命中率都超过 99%。在其环境中，Scion 的 CPU 和内存占用比旧的 Git 镜像基础设施小 200 倍；CI 和研究作业的检出时间从分钟缩短到秒，CI 的 CPU 容量提升了 25%。这些是公司针对自身工作负载报告的结果，不是适用于所有 Git 仓库的基准。

这是针对特定约束构建系统的例子。我自己的 Lust 实验希望让 Rust 的一个子集更快地编译，以满足 TypeScript 重写项目的需要。它并不打算适用于大多数 Rust 项目。定制方案之所以有用，恰恰可能是因为它不需要解决所有情况。

Anthropic 表示，它早期主要手写了 Git 到 Scion 的数据导入原型，后来请内部 Claude 模型重写。公司报告称，重写版本在保留必要不变量的同时，内存消耗减少 20 倍、速度提高 4 倍。这是内部比较，并不能证明每次重写都会获得同样提升。

该公司说，七位工程师在五个月内构建了 Scion 和 Antique，并迁移了多个相关系统。我把它看作切换成本降低的例子：过去更换供应商或自建定制方案可能消耗过多工程时间，现在某些情况下变得可行。

例如，我构建了一个管道，将分析数据镜像到自己管理的 ClickHouse 和 R2 中；我说对于自己的需求，它便宜了十倍以上。我自己的 CI 分析还估计，等待 Git 检出花费了近 1000 小时，CPU 租用费用约为 350 到 600 美元。这些数字只适用于我的测量和假设。

Anthropic 强调，即使 Claude 编写了大量代码，工程师仍然有价值。工程师需要作出系统层面的决策，有时还必须对模型说“不”。文章提到，智能体可能违反约束，或在有合适服务可以回答问题时尝试进行昂贵的线性扫描。

对抗式模型审查可以发现问题，也可能带来范围膨胀或不必要的防御性复杂度。Anthropic 说，其团队仍审查每一项变更请求，但重点看改动意图，而不是逐行阅读所有代码。Theo 认为，人类仍需要判断实现和审查意见是否合理。

该公司介绍了大量测试，包括隔离的模拟、模糊测试和限流，并表示 Claude 发现了算法优化。我觉得让智能体构建模糊测试器并调查失败十分惊人，但这些实践仍依赖于选择有意义的不变量并评估结果。

Anthropic 展示了其单体仓库的命令耗时。图表报告，开发者环境中的拉取、检出、rebase 和 status 更快，智能体环境中新建 worktree 则快了 84 倍。不同操作和环境的提升倍数不同；这些数字描述的是此次特定迁移。

Scion 还支持仓库级和目录级权限，审查工具能够针对不同类型的改动表达审批约束。我对更细粒度的访问控制感到兴奋，但关于审查规则应该如何实现的批评只是我的看法。安全仍取决于权限是否得到正确配置和执行。

Anthropic 表示，它在传统告警之外，还使用能够访问遥测数据和日志的 Claude“超级粉丝”来观察各个组件。公司称，这些智能体能注意到细微或新出现的问题。这种监控是对传统运维实践的补充，而不是替代。

对我来说，更大的教训是重新审视那些在人类规模下合理的假设。工程师往往偏好熟悉的工具，因为过去迁移成本高，新系统也可能令人失望。了解旧设计为何有效很有用，也应帮助我们识别哪些不同的工作负载需要另一种设计。

Anthropic 表示，全局锁式合并队列无法满足其智能体规模的吞吐量，因此它投入了合并后、部署前的自动化测试。并发改动仍可能发生冲突。我主张在改动进入前进行适当验证的同时，也降低错误改动进入后的损害和恢复时间。

我想过，合并队列是否可以收集已批准的工作，再让智能体分组组合变更并解决冲突。这是我的设想，并不是说 Anthropic 已经这样实现。共同的问题是，如何让大量独立改动持续推进，同时不忽视失败的后果。

Anthropic 明确表示，Scion 不是通用的 Git 替代品。它的方案针对极其庞大的单体仓库和异常高的智能体吞吐量，而且该公司的内部推理预算也不典型。不同团队对可用性、离线工作、安全和迁移的要求各不相同。

Scion 还依赖定制的审查、搜索和 CI 系统，这使公开发布后的采用十分困难。Anthropic 表示，它分享的是设计思路，而不是一套开箱即用的产品。我对其内部产品讨论有所猜测，但公司给出的理由是集成和迁移负担。

该公司建议，Git 平台可以不放弃 Git，也吸收其中一些经验：采用不同的服务器架构、提供更丰富的服务端 API、改进协商协议，以及让稀疏和浅克隆功能更好地组合。它肯定了 Git 社区多年扩展平台的工作，并称自己的贡献范围更窄。

不久前，这样的项目对我来说还会显得不可思议。现在它展示了一个实际问题：工具中的哪些假设适合我们的真实工作负载，哪些值得重新审视？Scion 之所以值得深入研究，正是因为它让这些取舍清晰可见。