Anthropic Scion：为智能体规模重新设计源代码控制

转向智能体规模的源代码控制

Anthropic 已将其整个单体仓库从 Git 迁移到名为 Scion 的自定义源代码控制系统。这一举措是由于 AI 驱动的代码生成激增所必需的，公司每日代码合并数量从 2026 年 5 月的 2,500 次增长到 2026 年 9 月的 30,000 次以上。随着 AI 智能体日益处理研究循环、微优化和服务创建，传统的开发者基础设施——特别是 Git——因其去中心化、客户端重型架构而成为关键瓶颈。

为什么 Git 在 Anthropic 的规模下失败了

Git 是为分布式、离线工作设计的，要求客户端维护完整、自包含的仓库副本。在 Anthropic 的规模下，这种模式崩溃了。仅主分支历史就达到近 100 GB，压缩后的工作副本超过 25 GB。由于每天发生数千万次 CI 检出，一个朴素的 Git 实现将需要每天超过 600 PB 的流量。虽然团队之前使用了数百个内部 Git 镜像和仓库快照，但随着合并率的加速，这些变通方法变得越来越难以维护。

Scion 的核心原则

Scion 建立在客户端始终在线的假设之上，允许与 Git 的去中心化设计从根本上分道扬镳。该系统基于几个关键原则运行：

客户端-服务器不对称： 与 Git 中每个客户端都是潜在服务器不同，Scion 集中了逻辑。服务器处理历史记录、指责、合并和变基，而客户端仅维护有限的本机缓存和虚拟化工作副本。
API 优先访问： 由于 Scion 通过 API 暴露所有源代码控制查询，许多 CI 作业和内部工具不再需要本地仓库克隆，从而大幅减少资源消耗。
水平可扩展性： Scion 消除了对包文件和仓库维护的需求。数据是分布式且内容寻址的，这意味着集群中的任何服务器都可以缓存和提供数据，而无需跨服务器协调。
廉价、增量的提交： 提交、合并和变基在服务器端进行。这些操作的成本随变更的大小扩展，而不是随仓库的总大小扩展。
稀疏和虚拟化检出： 客户端仅获取和物化他们需要的特定目录和文件，避免完整仓库检出的开销。

实现与性能

Scion 使用存储在预写日志中的“变更集”作为其主要工作单元。这些变更集记录相对于父级的更改，利用内容寻址存储文件块。为了保持性能，Scion 从这些变更集递归计算“派生数据”（如指责或路径历史），从而允许系统优化索引而不影响客户端。

通过实现分层缓存架构——包括 scion-daemon、区域 scion-cache 服务器和权威 scion-servers——Anthropic 实现了 99% 的缓存命中率。该基础设施在 CPU 和内存方面的效率是其之前 Git 镜像设置的 200 倍，CI 作业现在在几秒钟内完成，而不是几分钟。

AI 在基础设施开发中的作用

Anthropic 将 Scion 的快速开发归功于 Claude——由七人团队在短短五个月内完成。在一个显著案例中，Claude 重写了原型摄取管道，使其速度快 4 倍，同时内存消耗减少 20 倍。

然而，团队强调人工监督仍然至关重要。虽然 Claude 擅长编写代码，但工程师对于定义高级系统约束和引导 AI 避免过度工程或违反架构不变量至关重要。团队现在根据变更的意图审查代码，而不是逐行阅读。

社区观点与行业影响

开发者社区中的讨论褒贬不一。虽然许多人认可令人印象深刻的工程壮举，但一些观察者质疑这种高代码变更率的可持续性。

“合并代码的潜在需求实际上是无限的，我们每消除一个瓶颈，立即导致我们生成的代码量进一步增加。”

批评者提出了对缺乏开源可用性的担忧，有些人将 Scion 与 Subversion 或 Perforce 等遗留系统进行比较。其他人指出，虽然 Anthropic 的规模是独特的，但构建自定义基础设施以支持 AI 智能体的趋势可能成为其他组织的共同挑战。Anthropic 表示，Scion 不是 Git 的通用替代品，但他们希望分享其设计原则将鼓励行业发展 Git 的服务器端能力，以更好地支持智能体工作流。

SUMMARY: Anthropic 已用名为 Scion 的自定义服务器端源代码控制系统取代了 Git，以支持其内部 AI 智能体产生的大规模代码生成量。

TITLE: Anthropic Scion：为智能体规模重新设计源代码控制