重构 Anthropic 的源代码管理：Claude 超越了 Git

在 Claude 的推动下，Anthropic 的单体仓库每日合并次数从 2026 年 5 月约 2,500 次增长至 9 月超过 30,000 次，随后该公司弃用了 Git。这一激增让 重构 Anthropic 的源代码管理 不再只是一次基础设施迁移的故事。它揭示了当 AI 生成代码的速度超过开发系统能够安全消化的速度时，会发生什么。

该公司构建了 Scion——一套内部源代码管理系统，围绕在线代理、服务端操作以及对超大型仓库的稀疏访问而设计。七名工程师还构建了 Antique，一套新的代码审查系统，以及若干相关服务。Anthropic 表示，该团队在五个月内完成了迁移。

关键冲突并不只是 Scion 与 Git 的较量，而是代理规模的代码生产与围绕人类注意力设计的开发实践之间的矛盾。Google 和 Meta 早已为超大型单体仓库构建专用系统。Anthropic 则在另一种压力下抵达了类似的目的地：成群的软件代理，它们从不需要离线工作。

重构 Anthropic 的源代码管理始于每日 30,000 次合并

Anthropic 放弃 Git，并非因为工程师不喜欢 Git，而是因为 Claude 改变了仓库流量的形态与规模。

根据 Anthropic 的工程团队说明，2026 年 5 月至 9 月间，每日合并次数增长了十倍以上。该公司将这一增长描述为持续性的需求，而非短暂的迁移高峰。

随之而来的工作负载远不止创建提交。Anthropic 的主分支历史接近 100 GB，而压缩后的工作副本超过 25 GB。在计入开发者环境、代理沙箱和研究任务之前，持续集成（CI）每天就执行约 2,500 万次代码检出。

Anthropic 计算称，若以朴素方式获取这些检出操作，每天将产生超过 600 PB 的 Git 流量。该公司通过浅克隆、稀疏检出、仓库快照以及数百个内部 Git 镜像来控制这项成本。

这些措施争取到了时间，但仓库变化的速度仍在加快。快照在刷新间隔内便会过时。部分克隆也让历史搜索、差异比较和 blame 等操作变得复杂；blame 用于识别最后修改某一行的人。

该公司的问题源于 Git 的优势与 Anthropic 主导型客户端之间的不匹配。Git 为每个克隆提供足够的信息，使其能够作为一个自包含仓库运行。这种设计支持离线开发、本地历史记录和去中心化协作。

Anthropic 的代理和自动化任务本已在线运行。它们不需要完整的本地历史，也不需要充当独立服务器。然而，基础设施仍反复分发和维护仓库数据，仿佛每个客户端都是一名使用笔记本电脑的人类开发者。

Scion 颠倒了这一假设。其服务器负责执行历史查询、创建提交、计算差异，以及处理合并或变基。轻量级客户端维护受限缓存，并仅实体化当前任务所需的文件。

当研究任务只需要一个目录而非整个单体仓库时，这一区别至关重要。当 CI 服务只需要一项差异或合并基计算时，同样如此。Scion 可以通过 API 响应这些请求，无需创建传统工作副本。

Anthropic 表示，新架构带来了显著的内部收益。据称，每个缓存层的命中率均高于 99%。该基础设施使用的 CPU 和内存仅为此前 Git 镜像集群的二百分之一。

Anthropic 还称，CI 和研究任务的检出时间已从数分钟降至数秒。这项变化将 25% 的 CI CPU 容量归还给更广泛的计算集群。

这些是该公司针对内部系统报告的测量结果。外部研究人员无法在没有访问 Anthropic 工作负载、仓库和基础设施的情况下复现它们。不过，这些数字解释了为何再进行一轮 Git 调优已不再显得足够。

该系统需要支持的不只是一个大型仓库，还需要支持一个主要写入者、读取者和自动化消费者均以机器速度运作的仓库。

Claude 让软件基础设施成为瓶颈

Scion 的真正意义在于，代码生成不再是 Anthropic 的稀缺资源。审查能力、基础设施和判断力成了制约因素。

早期 AI 编程助手能够融入熟悉的开发流程。用户请求一个函数，检查输出，运行测试，然后提交拉取请求。助手提高了单个开发者的输入速度，却没有改变周边系统。

Anthropic 描述了一种更先进的运行模式。据称，Claude 会通过研究循环不断迭代、优化复杂程序、创建服务、监控生产组件，并协助大型迁移。每项活动都可能产生新的改动，或需要新的仓库访问。

这种模式会形成乘数效应。当先前改动仍在测试流程中时，一个代理可以启动另一项任务。自动审查器可以要求修复，从而产生额外改动。随后，CI 系统会为每个候选变更创建检出，并调用更多仓库查询。

Simon Willison 强调的图表显示，2026 年期间出现了急剧增长。Willison 将这一加速与 Anthropic 较新的内部模型世代联系起来，同时谨慎区分内部可用时间与公开发布日期。

Anthropic 给出了更具体的关联。该公司称，Scion 的开发大约始于 Claude Mythos Preview 和 Claude Tag 在内部可用之时。这些模型据称一方面增加了对 Scion 的需求，另一方面也帮助团队构建了它。

一个例子涉及将数据从 Git 迁移至 Scion 的管道。Anthropic 的工程师最初手工编写了原型。随后，Claude Mythos Preview 的一个早期内部版本在几乎无需额外指导的情况下重写了这条管道。

据称，替代方案使用的内存减少了 20 倍，运行速度提升了四倍。Anthropic 表示，它保留了与导入顺序和数据结构有关的隐含要求。这一说法颇为引人注目，但仍是公司描述的结果，而非独立基准测试。

更广泛的反馈循环则更容易确立。更快的代码生成提升了仓库活动量。这种活动为新基础设施提供了正当性。随后，Claude 帮助构建基础设施，进而移除了代码生成的另一项限制。

这一循环给开发生命周期的每个环节都带来压力。当代理创建数千个并发任务时，原本处理人类节奏改动的构建服务可能变得成本高昂。如果测试套件运行期间仓库已经历数百项改动，审查队列的价值也会下降。

知识访问也成为限制条件的一部分。代理不仅需要源文件，还需要规范、架构决策、事故历史和所有权背景。构建类似工作流的团队，需要在加快代码基础设施的同时，配备可搜索的工程知识库。

Anthropic 表示，它目前为各个 Scion 组件使用称为“superfans”的持久 Claude 监控代理。这些代理通过专用 Slack 频道监视遥测数据和日志。传统告警机制仍然保留，而代理则负责寻找固定阈值可能遗漏的模式。

这种运营模式将工程工作推向更高层次。人类定义不变量、选择架构边界、解读故障，并决定哪些内容应进入生产环境。代理则在这些边界内生成实现并调查遥测数据。

这种转变并未消除工程师的作用。它将稀缺技能从编写代码转变为判断哪些代码值得存在。

Scion 以代理规模服务替代 Git 的离线模型

Scion 通过放弃 Git 最具代表性的对称性来获得吞吐量：客户端不再承载仓库的全部智能。

Git 提交包含指向完整目录树的指针。客户端交换称为 packfile 的压缩对象集合，使本地仓库能够保留历史并独立运行。这一模型仍适用于大多数软件项目。

Scion 使用 changeset，即写前日志中的一个条目，用于记录相对于父项发生变更的文件。文件内容经过压缩、内容寻址，并单独存储。内容寻址意味着存储键源自数据本身，因此不可变对象可以被安全缓存。

Changeset 在服务器端创建，并在整个系统中可用。它们不要求客户端构建并上传大型 packfile，也避免在每次提交操作中移动全局分支指针。

Scion 仍支持引用，即分支和标签等指针。不过，Anthropic 不鼓励保留主线和发布分支之外的大多数引用。随着提交速率上升，全局协调状态的成本会越来越高。

该系统将历史信息作为派生数据单独计算。它为文件历史、blame、复制以及提交图中的关系建立专用索引。这些索引可以立即生成，也可以推迟到消费者提出请求时再生成。

这种分离让 Anthropic 能够在不修改每个客户端的情况下更改索引，也让服务可以避免计算任何任务不需要的数据。

Scion 的检出协议遵循同一原则。客户端请求特定树和文件对象，而不是协商它们已拥有内容的完整图景。由于存储对象永不改变，区域缓存服务器可以满足大多数请求。

每个计算节点上的守护进程会在本地任务之间共享缓存对象。区域缓存服务位于这些守护进程与权威 Scion 服务器之间。Anthropic 强制执行这一层级结构，以防止区域缓存故障压垮中央服务。

稀疏检出仅请求选定目录。虚拟化检出会在进程读取时创建文件。某些任务则完全跳过文件系统，直接通过 API 请求差异、历史结果或合并基。

这一设计与此前应对单体仓库规模的方案相似。Google 曾将 Piper 描述为支撑其超大型集中式代码库的基础设施之一。其发布的单体仓库分析记录了共享代码、统一依赖关系和全组织范围变更的优势。

Meta 则通过 Sapling 采取了另一条路径：该系统在扩展至其内部仓库规模的同时，保留了熟悉的分布式源代码管理概念。Meta 表示，其服务器能够处理数千万个文件、提交和分支。公开的 Sapling 设计也支持 Git 仓库和本地开发者工作流。

Scion 借鉴了两种历史的经验，但其核心假设更为狭窄：主导客户端始终在线，通常由自动化系统驱动，并且不太可能需要整个代码仓库。这使服务器成为源代码控制数据库和计算服务，而非同步伙伴。

代价是依赖性。Scion 客户端无法复现 Git 完整的离线行为，因为它有意保留更少的数据，并在本地执行更少的操作。因此，网络或中央服务故障的影响也有所不同。

迁移成本同样不止于命令行客户端。Anthropic 必须构建代码搜索、身份与访问控制、CI 集成以及 Antique。采用相同设计的公司，需要替换其开发平台的大部分组件。

这也解释了为何 Scion 并不是面向普通团队的 Anthropic Git 替代方案。它是为一种特殊工作负载打造的垂直整合系统。

更快的合并让代码审查成为更棘手的问题

尚未解决的问题并非 Scion 能否接收 30,000 项变更，而是 Anthropic 能否在这一速度下保持问责机制。

Anthropic 表示，每一项 Scion 变更仍会接受人工审查。审查者如今聚焦于变更意图，而不是逐行阅读代码。这一选择源于规模，但也将信任更多地转向测试、代理说明和自动化分析。

意图审查关注的是拟议变更是否符合系统目标和架构规则。逐行审查则关注其实现是否能正确运行。强大的自动化检查可以连接这两个层面，但没有任何测试套件能够覆盖全部隐性要求。

Anthropic 承认，工程师经常需要对 Claude 说“不”。代理有时会选择局部看来合理、却违反全局约束的模式。一些生成的组件尝试线性扫描提交日志，而不是查询 Antique 获取权威的合并时间。

对抗式审查带来了另一种失效模式。Claude 可能会针对假设性的风险加入过多验证和复杂性。人类工程师必须判断，防御式编程何时不再提升系统质量。

这些例子让“更好的模型会直接产出更好的软件”这一简单说法变得复杂。代理既可能发现有价值的优化，也可能制造不必要的机制。高产出会同时放大这两种行为。

Anthropic 表示，其团队为 Scion 构建了模拟、模糊测试和速率限制。模糊测试通过提供意外输入来暴露缺陷，而封闭式模拟则在隔离环境中复现基础设施行为。这些控制措施提供的证据，比单纯的合并数量更有说服力。

不过，合并量并非质量指标。一项变更可能非常小、处于实验阶段、由自动生成、已被回滚，或与面向客户的进展无关。每天 30,000 项变更展示了非同寻常的活跃度，但并不能独立证明可靠性或商业价值。

公开开发者的反应集中在这一差别上。在 Hacker News 讨论中，一些读者质疑 Anthropic 是否应重新考虑其单体仓库。另一些人则认为，意图、溯源和持续验证比传统提交机制更重要。

一位在该讨论串中回应的 Anthropic 工程师为单体仓库一致的工具链和原子化变更进行了辩护。这位工程师还澄清，Scion 能阻止文本冲突，却无法消除并发变更之间的语义冲突。

语义冲突是指，两项各自都有效的编辑组合后产生错误行为。一项变更可能修改了某个函数并更新其调用方，而另一项变更同时增加了新的调用方。即便文件可以顺利合并，组合后的程序仍可能出错。

传统合并队列通过在接受下一批变更前测试拟议的仓库状态，来降低这一风险。Anthropic 表示，当数百或数千项变更在一次测试运行期间落地时，对全局仓库加锁会变得不切实际。

该公司已将投入转向合并后和部署前测试。这种方法让仓库吞吐量得以持续，同时由检查机制决定哪些变更可以安全进入生产环境。

这是 Anthropic 重构源代码控制体系的核心取舍。Scion 从源代码控制中移除了串行化，但某种形式的串行化仍存在于部署、数据迁移或人工决策环节。风险被转移，而非消失。

Anthropic 表示，Claude 解决并发冲突的速度快于人类识别冲突的速度。这一回应针对的是修复速度，而不是未被发现的交互所造成的成本。安全性取决于监控发现问题的速度，以及系统隔离或回滚问题的有效性。

目录级访问控制和语义审批规则有所帮助。Anthropic 称，Antique 能区分仅修改注释的变更与敏感逻辑变更。人工注意力因此可以集中于后果更严重的变更。

剩余的验证缺口仍然很大。Anthropic 尚未公布独立缺陷率、回滚频率、事故趋势，或由代理编写和审查的变更占比。没有这些指标，外部人士无法比较吞吐量收益与下游风险。

因此，其他团队最有价值的启示并不是追逐 Anthropic 的合并数量，而是衡量从规格到部署的完整路径。有用的指标包括逃逸缺陷、审查延迟、失败变更、回滚、重复工作，以及恢复上下文所花费的时间。

个人 AI workflow 可以帮助工程师在代理生成更多材料时保留决策和溯源信息。不过，只有团队将存储的上下文与可执行的测试、责任归属和审查政策相连，它才会发挥作用。

Anthropic 的源代码控制实验接下来将改变什么

下一阶段将检验：代理规模的开发能否成为可迁移的工程模式，还是仍然只是代价高昂的 Anthropic 特例。

第一个值得关注的信号，是 Anthropic 承诺对 Antique 进行的讨论。源代码控制解释了变更如何被存储和检索，但代码审查决定了意图、责任归属和审批如何在极端规模下得以保留。

如果 Antique 审查模型的细节展现出清晰的溯源能力和基于风险的人工干预，Anthropic 的论点将更有说服力。若审查主要依赖模型摘要而缺乏可衡量的验证，其论点则会被削弱。

第二个信号是长期的软件质量。如果 Anthropic 在公布合并吞吐量的同时，也发布回滚率、逃逸缺陷、服务事故或其他结果指标，其基础设施主张将更具分量。

稳定或不断提升的可靠性，将支持这样一种观点：代理可以增加变更量，而不会按比例增加风险。若回归问题或紧急修复有所上升，则表明 Scion 加速生产的速度超过了治理能力。

第三个信号是 Git 平台和大型工程组织如何回应。大多数公司不会替换 Git，但可以采用服务器端元数据 API、虚拟化工作空间、风险感知审查，以及对并行代理更好的支持。

Meta 的 Sapling 已展示了一条兼容熟悉工作流的路径。Microsoft 的 Scalar 及相关 Git 改进则展示了另一条路径：扩展 Git 以支持大型仓库，而不是替换其数据模型。

Anthropic 本身预计，这些压力将在未来六到十二个月内扩散。这一预测是公司的判断，而不是经过衡量的市场趋势。它是否相关，取决于其他组织能否在没有 Anthropic 内部 token 访问权限和 Claude 使用高度集中的特殊条件下，达到类似的极限。

Scion 还引入了一种竞争对手可能会避开的战略依赖。Anthropic 控制着模型、仓库服务、审查界面、可观测性代理和部署工作流。这种整合加快了迭代，但也使开发环境更难复现或替换。

对于大多数组织而言，Git 仍将是明智的默认选择。它拥有广泛的互操作性、成熟工具、可移植的历史记录和离线韧性。只有当仓库流量已经压倒这些优势时，Scion 的架构才会变得具有吸引力。

更直接的变化关乎管理。工程领导者必须停止将生成代码的数量视为目标。只有当团队能够安全地审查、测试、部署、观察并回滚代码时，更多产出才会创造价值。

开发者也应预期自己的工作会发生转变。Anthropic 的叙述更加重视系统设计、架构约束、评估和拒绝。工程师日益负责定义代理可以快速行动的边界。

因此，Anthropic 对源代码控制的重构，除了性能叙事外，也提供了一个警告。一旦代码变得廉价，每一项薄弱的规格、缺失的测试和不清晰的责任边界，都可能以机器速度被复制。

真正有用的问题并不是你的团队是否需要 Scion，而是如果代理在下个季度产出十倍的变更，你现有的审查、CI 和知识系统是否仍值得信赖。现在就衡量这种能力，找出第一个失效的控制环节，并在更高的合并量到来前加以强化。