发布日期：2026-10-15

Anthropic 于 2026 年 10 月 13 日披露，已将内部单体仓库从 Git 迁移到自研版本控制系统 Scion。AI 编程提速后，公司日均合并量从 5 月约 2500 次增至 9 月超过 3 万次，代码获取、审查和测试随之承压。7 人团队用 5 个月完成 Scion、审查工具 Antique 等系统的建设与迁移，通过服务端查询、共享缓存和按需取文件支撑这类负载。此次变化发生在 Anthropic 的内部大仓库，展示了开发工具如何适应智能体并行工作，为其他团队提供了参考。

代码生成快起来之后，等待可能出现在另一端：拉取工作副本、查询历史、排队测试，以及让变更进入主分支。Anthropic 的内部工具，已经开始围绕这种节奏重新设计。

一天超 3 万次合并，原来的 Git 体系吃紧

Anthropic 此次迁出 Git 的对象，是把多个项目集中管理的内部单体仓库；与它一起调整的，还有代码审查、搜索和权限管理。

Git 负责记录文件变化、保存提交历史，让开发者能够协作和回溯。当越来越多智能体并行工作，这套后台系统也要持续支撑取文件、查历史、提交与合并，写代码提速带来的压力由此传到基础设施。

据 Anthropic 10 月 13 日的工程文章，2026 年 5 月，公司日均合并约 2500 次代码变更；到 9 月，这个数字已超过 3 万次。合并量的增长，让版本控制、构建和持续集成（CI）都承受了新的压力。

仅按 3 万次的日均量折算，就相当于平均约每 3 秒合并一次。这是平均节奏，不表示所有变更都以固定间隔发生，却足以说明工具面对的吞吐量。

更大的数字在取代码这一侧：仅 CI 每天就要执行约 2500 万次 checkout，还没算开发环境、智能体沙箱与研究任务。这里统计的是任务获取代码工作副本的操作。

同一篇文章披露，其主分支历史接近 100 GB，压缩后的工作副本仍超过 25 GB。若每次都按朴素方式拉取，估算每天将产生超过 600 PB 的 Git 流量。这是假设未经优化时的数据量，实际系统已经采用了多种优化方案。

Anthropic 已经用过浅克隆、稀疏检出、内部镜像和预制快照等办法，高峰时维护数百个 Git 镜像。这些方案争取了时间，但随着合并频率上涨，快照刷新、历史查询与镜像维护越来越难协调。

围绕在线智能体，Anthropic 重做了版本控制

Scion 围绕“客户端始终在线”的前提设计，把大量版本控制计算放在服务端，客户端只保留有限缓存和实际需要的文件。

传统 Git 的分布式设计，让完整克隆的本地仓库可以离线查询历史、比较修改。对 Anthropic 而言，大量客户端是天然在线的智能体与 CI 任务，公司因此选择重新划分本地与服务端的职责。

在这套系统里，查询文件历史、查看某行由谁修改、创建提交、合并与变基，都可以由服务端处理。只想查询差异的 CI 任务，可以直接请求 API，不必为了得到一个答案先准备完整本地仓库。

需要真实文件时，Scion 支持两种方式：稀疏 checkout 只获取指定目录，虚拟化 checkout 在文件被实际访问时按需落盘。客户端通过请求所需的目录树与文件内容对象，逐步取得任务需要的数据。

读取路径也做了重构：同一节点上的任务共享 scion-daemon 对象缓存，再逐级访问区域缓存与权威服务。许多任务反复需要相同的文件对象，节点内复用减少了重复获取与处理。

提交也在服务端创建，其处理成本被设计为随改动规模增长。减少无关数据的搬运与重复计算，是这次重构贯穿始终的思路。

重构之后，取代码从分钟级缩短到秒级

Anthropic 披露的性能收益，分别对应版本控制基础设施、代码获取耗时和 CI 的 CPU 容量。

据其 2026 年 10 月工程文章，Scion 的 CPU 与内存资源需求约为此前 Git 镜像基础设施的 1/200。比较对象限定为公司原先用来支撑代码获取的那套镜像基础设施。

文章还称，各级缓存命中率超过 99%，CI 与研究任务获取代码的速度提升约两个数量级，从分钟级缩短到秒级；仅 CI 就获得了 25% 的 CPU 容量收益。更短的代码准备时间，让计算资源可以投入后续任务。

这些数字来自 Anthropic 自身的运行环境，本文没有进行独立压测。这个案例的启示是，当海量任务反复获取相同代码时，改善数据供给路径也能释放可观的计算资源。

造新工具的也是 AI，7 人团队完成了迁移

Scion 项目的另一项进展，是小团队在合并量快速增长期间，完成了多套基础设施的建设和迁移。

官方原文给出的范围，比单独写一个版本控制工具更大：7 人团队在 5 个月内建成 Scion、Antique 及多套相关系统，并完成迁移。因此，“7 人、5 个月”包含这些系统的共同建设与落地。

Claude 也参与了开发。Anthropic 举例称，团队曾让早期内部模型重写 Git 到 Scion 的数据导入管道，结果内存占用降至原来的 1/20，速度达到原来的 4 倍。这是特定管道的改写结果，不代表整个 Scion 的统一提升幅度。

人的工作依然存在。原文明确说，团队成员仍审核系统的每个变更请求，但更关注变更意图、系统约束和设计取舍，不再把逐行阅读作为唯一的审核方式。

让人类介入的典型时刻，是智能体为解决局部问题破坏了整体约束，或在对抗式审查后加入过多校验与复杂度。工程师要判断问题是否值得解决、实现是否越界，以及哪些复杂设计应当删掉。

从 Git 到审查和测试，工具链都要适应新速度

Anthropic 对工具链的调整，已经延伸到代码如何审查、测试和进入部署流程。

官方文章提出了一个问题：如果一次测试还在运行，主分支已经合入了数百甚至数千项变更，原来的全局合并排队方式要如何继续工作？公司为此投入合并后、部署前的自动化测试，并承认并发变更仍可能产生冲突。

这让“AI 编程提效”有了更完整的观察范围：除了生成一段代码有多快，还要看它多久能经过验证、进入部署，以及出现问题后能否迅速定位和修复。

Anthropic 在结尾明确表示，Scion 不适合作为 Git 的通用替代。它针对的是超大型单体仓库与高强度智能体工作负载，而且迁移还牵涉代码审查、搜索和 CI，远超替换一个命令行工具的范围。

已经大量使用 AI 编程的团队，可以先统计流水线中代码获取、依赖安装、测试和等待合并各自耗时多少，再检查重复拉取与验证排队。Scion 提供的是一种重构思路，是否需要替换现有工具，要由实际负载决定。

截至 2026 年 10 月检索，Git 官方文档仍提供浅克隆、部分克隆和稀疏 checkout 等机制；git worktree 也支持在同一仓库下管理多个工作树。是否采用这些能力，应结合历史查询需求与任务隔离方式验证。

Anthropic 预计，这类扩展压力会在未来 6 至 12 个月变得更常见，并希望与 GitHub、GitLab 和开源社区分享经验。这个预测仍需时间验证，但内部大仓库的迁移已经发生：AI 编程带来的变化，正从代码编辑延伸到开发工具链。

本文依据 Anthropic 工程博客与 Git 官方文档整理，资料截至 2026 年 10 月 15 日。案例中的性能数字为 Anthropic 自报，适用范围以原文说明为准。

参考资料