2005 年，Linus Torvalds 开始开发 Git。谁也没想到，这个最初由他启动的项目，后来会成为几乎所有开发者都离不开的版本控制工具，一用就是 20 多年。
但如今 AI 写代码的速度越来越快，Git 也开始面临新的挑战。代码可以由 AI 在短时间内大量生成，可这些代码如何存储、合并和管理版本，背后的基础设施同样需要跟上。对于代码变更量快速增长的 Anthropic 来说，现有的 Git 架构已经难以满足内部开发需求。
于是，Anthropic 决定自己动手。
近日，Anthropic 首次在官方工程博客中介绍了内部开发的版本控制系统 Scion，详细讲述了团队如何在五个月内，将公司的大型代码仓库从 Git 迁移到 Scion。
更让人意外的是，整个项目只有 7 名工程师参与。开发过程中，他们还借助 Claude 重写核心架构、排查漏洞。一个只有 7 人的团队，究竟是怎么在五个月内完成这项大规模迁移的？
不是 Git 不够好，而是跟不上 AI 生成代码的速度
Anthropic 在博客中首先解释了一个问题：为什么已经足够成熟的 Git，会成为公司软件开发流程中的瓶颈？
这并不是因为 Git 本身出了什么问题。
Git 的设计优势之一，是分布式版本控制。每个开发者都可以拥有一份完整的代码仓库副本，在本地查看历史记录、比较代码差异、切换版本，即使处于离线状态，也能继续开展工作。对于绝大多数软件项目来说，这种设计仍然非常合适，也是 Git 能够成为行业标准的重要原因。
但 Anthropic 的情况比较特殊。
其公司内部大量使用 Claude 编写代码，开发活动的规模和速度都在快速增长。
2026 年 5 月，Anthropic 每天平均合并约 2500 处代码变更。到了 9 月，这个数字已经超过 30000 处，短短几个月增长了 12 倍。
此外，其主代码分支的历史记录已经接近 100GB，经过压缩的工作副本也超过了 25 GB。
更大的压力来自持续集成（CI）。
Anthropic 每天需要执行约 2500 万次代码检出操作，还没有计算开发环境、AI Agent 沙箱和研究任务产生的需求。如果每次都按照传统方式获取代码仓库，理论上每天产生的 Git 数据传输量将超过 600 PB。
为了应对这一问题，Anthropic 此前已经尝试了 Git 提供的浅克隆、稀疏检出等功能，也搭建了内部 Git 镜像和存放在对象存储中的仓库快照。高峰时期，公司运行着数百个内部 Git 镜像。
这些措施确实缓解了压力，但随着每天合并的代码越来越多，维护镜像和快照也变得更加困难。快照可能逐渐落后于主分支，而在不完整的代码副本上执行代码差异比较、追踪某一行代码的修改历史等操作，也需要额外处理。
Anthropic 团队随后意识到，问题可能不在于如何继续扩展现有的 Git 部署，而在于这套架构本身是否适合当前的工作负载。
Git 的设计考虑了开发者离线工作的需求，每个客户端都可以独立完成大量操作。但 Anthropic 的使用场景已经发生变化：大部分客户端不再是需要随时离线工作的开发者，而是始终联网的 AI Agent 和自动化任务。
既然这些客户端可以随时访问服务器，是否还有必要让每个客户端都持有完整的代码仓库，并独立完成所有版本控制操作？
Scion 就是围绕这个问题开发出来的。
Scion 与 Git 有什么不同？
Scion 并不是简单地给 Git 加上一个更快的服务器，而是重新设计了版本控制系统的工作方式。
在 Git 中，客户端可以独立完成提交、查看历史记录等操作，再通过推送与其他副本交换数据。
Scion 则采用了更明确的客户端与服务器分工：提交、合并、变基，以及代码历史查询等操作，都可以交由服务器处理。客户端主要负责维护有限的本地缓存、管理磁盘上的工作文件，以及监控文件系统变化。需要什么数据，再向服务器请求。
这种设计带来了几个明显的区别：
首先，不再要求每个客户端都持有完整的代码仓库。
在传统 Git 工作流中，CI 任务如果需要比较两个提交、查询某行代码的修改者，通常需要先获取仓库，或者依赖代码托管平台提供的特定接口。
Scion 将这些版本控制操作通过 API 暴露出来。对于只需要查询代码历史、计算差异等信息的任务，可以直接向服务器发起请求，不必先检出整个仓库。
对于每天要执行数千万次代码检出的 Anthropic 来说，这意味着大量不必要的数据传输和本地存储工作可以省去。
其次，Scion 只获取真正需要的代码。
Scion 支持稀疏检出和虚拟化检出。前者只获取客户端指定目录中的文件，后者则按需加载文件内容。即使某个任务需要在磁盘上操作代码，也不必一次性获取整个仓库。
例如，某个 CI 任务只需要检查一个目录中的代码，就没有必要为了执行这项工作，把整个大型代码仓库都下载下来。如果任务只需要查询两个提交之间的差异，甚至可以直接调用服务器 API 完成，不必创建本地工作副本。
第三，Scion 的各个组件可以独立扩展。
Anthropic 表示，巅峰时期其运行数百个 Git 镜像，不仅极大消耗资源，一旦仓库超出镜像磁盘、内存上限，就再也无法扩容。
Scion 的数据是分布式存储，各个组件可以独立扩缩容；即便是服务端，也不存在一份完整落地的仓库副本。没有 Git 打包对象包（packfile）这类概念，因此也不需要仓库维护工作。
它是如何运作的？
基于以上的设计原则，Anthropic 详解了 Scion 的完整运作方式。
数据结构：变更记录与辅助索引分开处理
在 Scion 中，最基本的工作单元叫作变更集（Changeset），可以将其理解为 Git 提交的另一种实现方式。
不同的是，Git 提交会保存一个指向文件树的引用，而 Scion 的变更集直接记录相对于第一个父变更集发生变化的文件列表，并通过内容寻址的方式，保存指向压缩文件内容的引用。
这种设计减少了服务器接收代码变更时需要处理的工作。Scion 不需要接收 Git 的 packfile，也不需要通过锁定或跨服务器协调来创建变更集。变更集创建完成后，就可以在整个系统中使用。
不过，仅靠变更集并不能高效回答所有问题。例如，想知道某一行代码最后由谁修改，或者一个文件经历过哪些提交，还需要额外的数据结构。
因此，Scion 会根据变更集生成相应的辅助数据，包括用于代码归属追踪（Blame）、文件路径历史查询的索引，以及用于加速提交关系查询的跳表。这些数据被统称为派生数据（Derived Data），可以根据变更集及其父变更集递归计算。
这种设计还有一个好处：Scion 可以根据需要增加新的索引，并自行决定何时计算和存储这些数据，而不必修改客户端。随着系统发展，团队已经为文件复制检测和按路径搜索等功能增加了新的索引。
代码检出：客户端需要什么，就获取什么
对于需要获取文件内容的场景，Scion 开发了自己的客户端 scn。与 Git 的获取协议不同，scn 不会让服务器先判断客户端已经拥有多少数据，而是由客户端主动请求自己缺少的文件树和文件内容。
具体来说，客户端先从根文件树开始，逐层检查本地存储中缺少哪些文件树，再获取相应的文件内容。
由于 Scion 的数据对象采用内容寻址方式存储，写入后不会改变，服务器可以直接返回缓存中的对象，不必每次都重新计算客户端缺少哪些数据。
这种方式也不需要依赖一个可能达到数 GB 的大型 packfile。文件树和文件内容可以分开获取，即使检出过程被中断，也能够继续请求尚未获取的对象。对于稀疏检出和虚拟化检出，客户端只需跳过不需要的文件树，就能减少数据获取量，无须额外设计特殊的支持机制。
分层缓存：减少重复下载和服务器负担
Scion 还采用了三层缓存架构，让不同任务能够复用已经获取的数据。
第一层是运行在计算节点上的守护进程 scion-daemon，负责存储和管理节点上的文件对象。同一台机器上的多个任务往往会访问相同的代码，因此可以共享这些对象，避免重复下载。
第二层是区域缓存服务器 scion-cache，主要为所在区域的节点提供文件树和文件内容。缓存命中时，服务器可以直接从内存中读取数据，并以客户端能够直接使用的格式传输，不必重新计算客户端缺少哪些对象，也不需要进行 Delta 压缩。
如果区域缓存中没有所需数据，请求才会转发到负责提供权威数据的 scion-server，由后者根据需要从 Spanner 或云存储中读取数据。
这三层使用相同的 RPC 接口，客户端不需要了解背后的缓存结构。不过，Scion 会限制不同层级之间的访问关系，避免某一层发生故障后，大量请求直接涌向上游服务器，影响整个系统。
据 Scion 团队介绍，各层缓存的命中率均超过 99%，而且不需要维护复杂的长期状态，因此可以根据需求扩容。
整体而言，根据 Scion 团队公布的数据，与此前的 Git 镜像基础设施相比，Scion 对 CPU 和内存的需求减少到了原来的约 1/200。CI 和研究任务的代码检出速度也提升了两个数量级，原本需要几分钟的操作，现在可以在几秒钟内完成。其中，仅持续集成（CI）任务就节省了相当于 25% CPU 容量的资源。
此外，由于客户端和缓存服务器不再需要执行传统仓库的维护工作，相关任务的管理也变得更加简单。
7 个人用 Claude 开发
Scion 的开发过程，还有一个值得关注的地方：Anthropic 不仅使用 AI 编写代码来解决开发效率问题，还借助 AI 加快了这套基础设施本身的开发。
按照 Anthropic 的介绍，一支只有 7 名成员的工程师团队，在五个月内完成了 Scion、代码审查工具 Antique，以及其他相关系统的开发和部署，并将公司的大型代码仓库完整迁移到新系统。
这项工作是在每天合并的代码量增长 10 倍的情况下完成的。
Anthropic 表示，如果放在过去，开发并部署这样一套版本控制系统，可能需要更多工程师和数年的迭代迁移工作。Claude 的代码生成能力，则让团队能够在更短的时间内完成大量开发和优化任务。
官方博文中还提到了一个具体案例。
在开发早期，团队曾经手工编写了一个用于将 Git 数据导入 Scion 的原型程序。当他们拿到内部版本的 Claude Mythos Preview 后，便让模型重写了整个程序。
Anthropic 称，在没有额外指令的情况下，模型生成的新版本将内存消耗降低了 20 倍，运行速度提高了 4 倍，同时保留了原有程序在数据导入顺序和数据结构方面的隐含约束。
这并不意味着工程师可以完全退出开发过程。
恰恰相反，Anthropic 特别提到，工程师仍然需要把控系统设计、跨组件协作和技术取舍。AI Agent 有时会为了完成眼前的任务，采用违反系统约束的实现方式；有时也会针对假设性的风险加入过多验证逻辑，反而增加系统的复杂度。
Anthropic 还表示，团队成员现在仍然会审查每一项变更请求，但关注点已经有所变化。相比逐行阅读所有代码，他们会更加关注修改的意图，以及这项修改是否符合系统设计。
与此同时，Claude 也让团队能够投入更多精力进行测试和优化。Anthropic 称，即使项目时间紧张，团队仍然为复杂的基础设施交互构建了隔离模拟环境，并加入模糊测试和更精细的速率限制机制。
Anthropic：Scion 不会取代 Git，也没有打算让所有人迁移
看到这里，可能有人会问：既然 Scion 的效率这么高，为什么不直接将它推广出去，替代 Git？
Anthropic 在博客中明确表示，Scion 并不适合作为 Git 的通用替代品。
原因很现实：
Scion 面向的是规模极大的单体代码仓库，主要适用于拥有数万名工程师，或者存在大量 AI Agent 持续生成代码的开发环境。
对于绝大多数团队来说，Git 依然是合适的选择。它支持分布式开发，允许开发者在本地完成大量操作，也已经形成了成熟的工具链和开发生态。
Scion 则在架构上与 Git 存在较大差异。企业如果希望采用这套系统，不仅需要迁移代码仓库，还需要调整代码审查、代码搜索和持续集成等配套系统。Anthropic 内部使用的相关工具高度定制化，也很难直接复制到其他公司的开发环境中。
此外，Anthropic 能够为内部开发投入大量计算资源，这种条件并不是所有企业都愿意承担的。
因此，Anthropic 选择分享 Scion 的设计思路，而不是将其包装成一套适用于所有团队的通用方案。
与此同时，Anthropic 还提到，未来 6 到 12 个月内，随着更多企业使用 AI 编程工具，类似的基础设施压力可能会逐渐出现。与其让每家公司都独立解决这些问题，不如把已经验证过的部分经验分享出来。
说到底，Anthropic 开发 Scion，并不是因为 Git 已经过时，而是因为当 AI 开始以远超人类的速度生成代码时，原本围绕人类开发节奏设计的工具链，也需要重新审视。
本文来自微信公众号“CSDN”，整理：屠敏 ，36氪经授权发布。