Anthropic Scion 深度解析：Claude Code 时代的版本控制架构、Git 性能瓶颈与 CI/CD 优化

一、当 AI 写代码越来越快，Git 为什么成了瓶颈？

软件开发过去有一个普遍的工作节奏。

开发者理解需求、修改代码、执行测试、提交 Git，然后等待代码审查与合并。

对于多数团队来说，代码编写往往是比较耗时的环节。

但当 AI Coding Agent 开始承担大量开发任务时，这个节奏正在改变。

2026 年 10 月 13 日，Anthropic 发布了一篇非常值得工程团队研究的技术文章：

《Redesigning source control at Anthropic》。

文章揭示了一个令人关注的变化。

换句话说，短短几个月，代码合并量增长超过十倍。

推动这一变化的重要因素，就是 Claude 在内部软件开发和研究系统中的广泛应用。

Claude 可以自主探索代码、优化程序、修复问题，甚至参与构建新的基础设施。

但是，当代码生成速度不断提高，Git、构建系统和 CI/CD 却开始无法跟上。

Anthropic 最终选择自研一套版本控制系统：

Scion。

团队用五个月完成了核心系统建设，并将内部 Monorepo 从 Git 迁移到 Scion。

同时还构建了新的代码审查系统 Antique。

这并不意味着 Git 已经落后，也不意味着普通开发团队应该立即放弃 Git。

真正值得研究的是：

当软件开发的主要生产者从人类逐渐扩展到大规模 AI Agent，原有基础设施应该如何改变？

二、Anthropic 的代码规模究竟有多大？

先看官方公布的几项关键数据。

这已经远远超出普通软件团队的开发规模。

如果将 2,500 万次代码检出都粗略理解为下载一次超过 25GB 的仓库内容，那么理论上的日流量可能达到数百 PB。

当然，真实 Git 系统通常会使用缓存、浅克隆、稀疏检出和镜像服务，因此并不真的需要每次传输完整仓库。

但这个估算可以说明 Anthropic 面临的压力。

即使已经使用了大量优化措施，海量 Agent 和 CI 任务仍然会不断消耗磁盘、CPU、内存和网络资源。

Anthropic 披露，在迁移之前，公司一度运行数百个内部 Git 镜像。

随着代码变更频率提高，这些镜像本身又逐渐成为新的维护负担。

三、Git 为什么不适合 Anthropic 的极端工作负载？

要理解 Scion，首先需要理解 Git 的设计优势。

Git 是一个分布式版本控制系统。

开发者克隆仓库以后，通常可以在本地完成大量操作。

例如：

查看历史、比较文件差异、创建提交、切换分支，以及在没有网络连接的情况下工作。

这套设计对人类开发者非常有效。

但在 Anthropic 的场景中，有两个条件已经改变。

第一，绝大多数代码操作来自在线 Agent 和自动化任务。

这些任务本来就运行在联网服务器上。

它们并不需要像人类开发者那样，长时间离线操作完整仓库。

第二，许多任务只需要仓库的一小部分信息。

例如，某个 CI 任务只想知道两个提交之间哪些文件发生了变化。

如果为了回答这个问题，还需要维护一个庞大的本地 Git 仓库，就会产生不必要的资源消耗。

因此，Anthropic 开始重新思考：

如果代码客户端始终在线，而且绝大多数操作都可以通过服务器提供的接口完成，是否还需要沿用完整的分布式 Git 工作模式？

Scion 就是按照这一思路设计的。

四、Scion 是什么？

Scion 是 Anthropic 内部使用的版本控制系统。

与 Git 不同，它更加接近以服务器为中心的代码管理架构。

其核心思想包括：

• 客户端默认在线；
• 历史和提交操作主要由服务器完成；
• 客户端只按需获取文件与数据；
• 仓库数据使用内容寻址存储；
• 代码检出尽量保持稀疏；
• 元数据查询直接通过 API 完成；
• 不同服务组件可以独立扩容。

对于人类开发者来说，Git 的优势是本地自主性。

而 Scion 的优势，则是服务端统一处理海量并发操作的效率。

需要注意，Scion 是 Anthropic 针对自身业务开发的内部系统。

当前并没有证据表明普通开发者已经可以像安装 Git 一样直接安装完整 Scion 服务。

五、Scion 的第一个核心设计：在线客户端

传统 Git 客户端通常拥有比较丰富的本地功能。

而 Scion 把更多操作交给服务器。

例如：

创建提交、执行合并、计算 Merge Base、查询历史和 Blame 信息。

客户端主要负责本地工作目录、文件变化监测，以及维护有限大小的对象缓存。

这样做有一个直接好处：

不需要每个自动化任务都拥有一份完整仓库。

例如一个测试任务只需要：

backend/payment/
shared/types/
tests/payment/

那么客户端就可以尽量只获取相关文件。

它不必把整个公司内部 Monorepo 下载到本地。

这对需要不断创建和销毁执行环境的 Coding Agent 尤其重要。

六、第二个核心设计：Changeset 替代传统提交存储方式

在 Git 中，提交对象会关联树对象以及父提交等信息。

Scion 则采用一种基于 Changeset 的设计。

Changeset 可以理解为一次代码变更记录。

Anthropic 将其组织到 Write-Ahead Log（预写日志）结构中。

每个 Changeset 重点记录：

相对于首个父版本修改了哪些文件，以及这些文件内容对应的存储引用。

文件内容采用内容寻址方式保存在对象存储中。

例如：

Changeset
├── Parent
├── Changed Files
│   ├── api/server.go
│   └── api/router.go
└── Content References

这样的结构有助于让提交成本更多取决于实际修改量，而不是整个仓库的规模。

同时，Scion 尽量避免大量客户端共同争抢全局引用更新造成的协调压力。

需要注意，Scion 并不是简单地把 Git Commit 换了一个名字。

它连提交创建、数据存储、历史查询和服务端协调方式都进行了重新设计。

七、第三个核心设计：内容寻址与分层缓存

Scion 的重要优化来自内容寻址。

简单来说，一个文件对象由其内容对应的标识来引用。

只要内容不发生变化，对应对象就可以作为不可变数据被缓存。

这非常适合分层缓存架构。

Anthropic 介绍了三个重要组件：

scion-daemon

运行在计算节点上的对象缓存服务。

同一个节点上的多个 Agent 和 CI 任务可以共享已经获取的对象。

scion-cache

区域级缓存。

负责向节点提供需要的对象内容，减少频繁访问权威服务。

scion-server

权威服务层。

负责相关版本控制 API，并根据需要从 Spanner 或云存储中获取数据。

整个访问流程可以简化为：

客户端 → 节点缓存 → 区域缓存 → 权威服务 → 底层存储。

如果文件已经存在于近端缓存，就不需要继续访问更远的存储层。

Anthropic 披露，各级缓存的命中率均超过 99%。

这对于每天需要执行数千万次代码检出的系统非常重要。

八、Scion 如何让检出速度从分钟级缩短到秒级？

关键并不是使用了某个更快的 Git Clone 命令。

而是改变了任务获取代码的方式。

传统流程中，任务可能先准备一个仓库，再从中读取相关文件。

Scion 则允许许多任务直接查询元数据、差异或特定对象。

即使需要建立工作目录，也可以使用稀疏检出或虚拟化检出。

例如：

一个测试任务只需要某个子目录。

那么系统仅获取这个目录相关的数据。

一个历史分析任务只需要文件修改信息。

那么系统可能直接查询版本控制 API，而不必创建完整工作副本。

Anthropic 披露，Scion 使 CI 和研究任务的代码检出速度提升了约两个数量级。

以实际体验来说，部分任务由原来的分钟级缩短到秒级。

但这属于 Anthropic 在其内部规模和配置下得到的结果。

不能理解为普通开发者将 Git 替换成任何服务端版本控制工具后，也必然能获得同样速度。

九、Scion 带来了多少资源节省？

Anthropic 官方披露，Scion 相比此前的 Git 镜像基础设施，CPU 与内存资源占用规模缩小了约 200 倍。

同时，CI 系统获得约 25% 的 CPU 容量收益。

这两个数据衡量的不是同一件事。

200 倍主要针对源码管理基础设施的资源占用。

25%则是 Anthropic 观察到的 CI 计算资源容量改善。

因此，不能把两者相加，也不能表述成整个 Anthropic 的软件开发成本下降了 200 倍。

更合理的理解是：

当源码管理不再频繁占用大量计算资源时，CI 和 Agent 可以将更多资源投入真正的开发与测试任务。

十、Antique：与 Scion 配套的代码审查系统

Anthropic 同时开发了 Antique。

这是与新版本控制体系配套的代码审查界面。

当每天有数万次代码变更需要处理时，传统逐行审查方式就可能无法满足全部需求。

Anthropic 表示，团队开始更加关注代码修改的意图、系统约束和风险等级。

例如：

简单的注释修改与身份验证逻辑修改，不应该采用完全相同的审查优先级。

Scion 与 Antique 的权限系统能够为不同代码路径和变更类型设置更细致的控制。

这对于拥有大量 Agent 的企业尤其重要。

因为一个 Agent 即使能够编写正确代码，也不应该自动获得修改所有敏感模块的权限。

例如：

支付逻辑、权限系统、密钥管理和生产部署配置，应采用更严格的审核要求。

十一、Claude 在 Scion 开发中承担了什么角色？

Anthropic 介绍，开发 Scion 和 Antique 的核心团队只有七人。

这支团队在五个月内完成了多个核心组件建设和迁移。

Claude 在其中承担了大量代码编写、测试和优化工作。

一个值得关注的案例是：

Anthropic 曾让早期内部版本的 Claude Mythos Preview 重写 Git 到 Scion 的数据导入管线。

官方称，新的实现相比旧版本内存占用降低约 20 倍，执行速度提升约 4 倍。

但 Anthropic 同时强调：

工程师的重要工作并没有消失。

人类仍然负责架构设计、系统约束、关键取舍和代码审查。

很多时候，工程师需要阻止 Agent 选择某些看似合理、但违反系统设计原则的方案。

例如，Agent 可能试图通过扫描全部提交日志解决一个查询问题。

但架构上更合适的方式，可能是利用已有的索引或代码审查 API。

这说明，AI Coding 时代的软件工程能力，不再只是写代码的速度。

还包括判断什么代码根本不应该被写出来。

十二、普通开发团队现在应该放弃 Git 吗？

答案通常是否定的。

Anthropic 已经明确说明，Scion 不适合成为普通 Git 用户的通用替代品。

绝大多数项目并不需要每天处理数千万次代码检出。

对于个人项目、小型创业团队和常规企业应用，Git 仍然是一套成熟、稳定且生态丰富的版本控制系统。

更合理的做法，是先优化现有 Git 和 CI 工作流。

例如：

减少重复 Clone。

使用工作区缓存。

为大型仓库应用稀疏检出。

通过文件变更范围决定运行哪些测试。

增加代码审查与自动化测试。

这些方式不需要自研一套新的版本控制系统。

十三、普通团队可以借鉴哪些优化方法？

1. 使用部分克隆与稀疏检出

对于支持相应 Git 功能的仓库，可以尝试：

git clone --filter=blob:none --sparse \
  https://github.com/example/large-project.git

然后进入仓库：

cd large-project

仅检出需要的目录：

git sparse-checkout set backend shared

这样可以减少不必要的文件获取和工作目录内容。

不过，这不是让 Git 具备 Scion 全部能力。

实际优化效果还取决于服务器是否支持部分克隆、仓库历史结构和 CI 的访问模式。

2. 对 CI 进行路径级触发

例如前端文件发生变化时，优先运行相关前端测试。

后端文件发生变化时，运行对应后端测试。

同时保留必要的全局验证任务，避免因过度缩小测试范围而遗漏跨模块问题。

3. 复用缓存

对依赖包、构建产物和适当的仓库对象设置缓存。

但缓存需要有明确的有效性判断，不能为了速度无条件复用旧结果。

4. 为 Agent 分配隔离工作区

多个 Agent 同时修改同一个目录，容易产生覆盖和冲突。

可以为每个 Agent 使用独立分支或 Git Worktree。

例如：

git worktree add ../agent-task-a -b agent/task-a

这样可以让不同 Agent 在隔离工作目录中执行任务。

最后仍然需要审查和合并。

5. 加强合并前验证

对于 AI 生成的代码，应执行静态检查、单元测试和关键业务回归测试。

不要因为 AI 可以在几秒钟内修复冲突，就放弃代码质量门禁。

十四、AI Agent 时代，CI/CD 会发生哪些变化？

当代码生成速度不断提高，CI/CD 将面临几个新的挑战。

第一，测试任务数量增长。

第二，多个代码变更可能同时修改相关模块。

第三，传统合并队列等待时间可能增加。

第四，部分测试完成时，主分支已经发生多次新变化。

Anthropic 在文章中指出，他们正在重新思考全局合并锁和传统合并队列的设计。

团队增加了合并后和部署前的自动化测试。

不过，对于大多数企业来说，不能据此直接取消现有的合并前测试。

更合理的做法是：

根据团队规模、代码风险和 Agent 并发程度，逐步调整验证策略。

对于重要生产服务，应把未经验证的修改限制在测试环境内。

十五、Scion 对 AI API Gateway 和企业平台有什么启示？

对于构建 AI API Gateway、Agent 平台或者云端 Coding 服务的开发者，Scion 提供了几个思考方向。

首先，Agent 的运行环境应该尽可能轻量。

如果每创建一个开发 Agent，都要复制完整仓库和依赖环境，资源成本可能很快增长。

其次，尽量将常用能力服务化。

例如：

代码搜索、文件差异、任务状态和权限检查，可以通过统一的服务接口提供。

再次，将任务成本视为整体指标。

不仅统计模型 Token，还应包括：

代码检出、容器启动、测试执行、文件存储和人工审查成本。

最后，权限控制必须与自动化能力同步发展。

当 Agent 的代码修改量大幅增长时，系统需要更严格地区分普通修改与高风险操作。

十六、常见问题

Scion 是开源项目吗？

截至本次官方公告，Scion 是 Anthropic 的内部版本控制系统。文章没有宣布面向普通用户发布可直接部署的完整开源版本。

Scion 是 Claude 的新编程模型吗？

不是。Scion 是源码管理基础设施，不是大语言模型。

Anthropic 已经完全停止使用 Git 吗？

官方表示其内部 Monorepo 已完成迁移，但不能由此推断 Anthropic 所有代码仓库和外部项目都彻底停止使用 Git。

200 倍性能提升具体指什么？

官方指的是相关源码管理基础设施在 CPU 与内存占用方面的规模变化，不是所有 Git 操作都提速 200 倍。

普通开发者需要自研版本控制系统吗？

通常不需要。多数团队更应该先优化现有 Git、CI 缓存、代码审查和 Agent 工作区管理。

十七、总结：AI 正在改变软件开发基础设施

Anthropic Scion 的真正意义，不只是“Claude 帮助公司开发了一套新 Git”。

更深层的变化在于：

当 AI Agent 生成代码的能力大幅提高，软件工程的瓶颈可能从代码编写转移到代码审查、构建、测试和交付。

Scion 通过在线客户端、服务端提交、稀疏检出、内容寻址缓存和高度服务化的接口，尝试解决这一问题。

对于普通开发者，现在还没有必要放弃 Git。

但值得提前思考：

当一个项目同时运行几十甚至上百个 Coding Agent 时，现有代码管理和 CI/CD 是否仍然足够高效、安全、可控？

这可能是下一阶段 AI 编程平台竞争的重要方向。

官方参考资料

Anthropic Engineering：Redesigning source control at Anthropic https://www.anthropic.com/engineering/redesigning-source-control

Git 官方文档：Partial Clone https://git-scm.com/docs/partial-clone

Git 官方文档：Sparse Checkout https://git-scm.com/docs/git-sparse-checkout

Git 官方文档：Worktree https://git-scm.com/docs/git-worktree