Anthropic发布了一套名为Scion的源码控制系统，并已在内部单体仓库中用Scion取代了Git。这套系统由一个7人团队在5个月内构建完成，同期还搭建了代码审查平台Antique以及另外六个相关系统，并完成了全部迁移工作。

Anthropic做这件事的直接原因是内部代码产量的爆发式增长。2026年5月，其内部平均每天合并约2500处代码变更；到9月，日均合并量已突破3万笔，四个月暴涨12倍，且这一势头短期内没有放缓迹象。研究人员发现，每消除一个瓶颈，代码产量就会立即进一步增加，代码合并的潜在需求几乎无限。

问题的根源在于，Claude如今能够自主迭代研究流程、对复杂程序做精细化优化，甚至从零搭建全新服务，其执行速度与规模前所未有。真正的瓶颈不再是模型能力，而是原本面向人类开发者打造的基础设施——版本控制、构建流程与持续集成（CI）——正不堪重负。

Git长期以来是现代软件工程的事实标准，绝大多数团队用它管理代码、留存变更历史、多人协同。但Anthropic的单体仓库规模已远超其设计预期：仅主分支历史记录就接近100GB，压缩后的工作副本超过25GB。不包括开发环境、代理沙箱和研究任务，Anthropic每天仍需在CI环境中执行约2500万次代码检出，粗略估算每天Git流量超过600PB。为应对负载，其在峰值时期维护了几百个内部Git镜像，但运维压力随合并量上涨而持续加大。

Anthropic研究人员注意到一个关键矛盾：多数公司只是把Git当作集中式系统使用，只维护一个权威仓库，而绝大多数访问方其实是始终在线的智能体和自动化任务。Git那些为分布式离线工作设计的特性，反而成了仓库扩容的阻碍。于是他们开始设想：如果从头设计一套源码控制系统，原生就以智能体永远在线为前提，会是什么样？

Scion在几个核心原则上与Git截然不同。客户端始终在线，围绕一个始终可访问的服务器设计协议，而非默认离线工作并持有完整副本；客户端与服务器高度不对称，服务器负责回答文件历史与blame查询、创建提交、执行合并和变基，客户端只维护有界本地对象缓存；所有源代码控制查询通过API公开，许多作业根本不需要本地代码库；仓库数据分布式存储，每个组件可独立扩展，服务器上也没有仓库的完整实例；提交、变基或合并都在服务器端进行，成本与变更大小成正比而非与仓库整体大小成正比；工作副本可选，协议以稀疏检出和按需实例化文件的虚拟化检出为核心。

性能数据方面，Scion每一层都保持超过99%的缓存命中率，且不需要长期状态。就CPU和内存需求而言，Scion基础设施占用空间仅为Git镜像基础设施的1/200。CI和研究作业检出代码的速度提高了两个数量级，从几分钟缩短到几秒钟；仅CI一项就实现了25%的CPU容量提升。客户端和缓存都不需要执行代码库维护，作业生命周期管理得以简化。

Scion的工作单元是“变更集”（changeset），它是预写式日志中的一个条目，存储相对于第一个父级发生更改的文件列表及指向Blob存储的指针，在服务器端创建并可立即在任何位置访问。这种架构支持极高吞吐地接收变更集，无需处理打包文件、加锁或跨服务协同。变更集本身无法快速回答“谁最后编辑了某一行”之类的问题，Scion为此构建了额外的“派生数据”结构，递归定义、可即时或延迟计算，且客户端永远看不到内部细节，研究人员可在不更改客户端的情况下优化。

值得一提的是，在构建Scion过程中，Claude Mythos Preview的早期内部快照版本重写了Git到Scion的数据导入管道，在没有任何进一步指示的情况下，生成了一个内存占用减少至1/20、速度提升4倍的版本，同时保留了所有关于数据导入顺序和数据结构的隐式不变性。

Anthropic特别强调，Scion绝非Git的通用替代品。它只适用于真正庞大的单体仓库——要么有数万名工程师，要么有大量智能体在高效编写代码。由于很多组件需要根据公司情况高度定制，Anthropic不会推出通用的Scion版本，只是向业界提供一种思路。

从产业视角看，这条消息的意义超出一次内部工具替换。当编程主体从人类开发者变为7×24小时在线、高频批量迭代的AI智能体，版本控制只是第一个被重新设计的环节。构建系统、缓存调度、代码评审、测试沙箱、权限审计等环节，都可能需要适配AI的并发模式。Anthropic的做法借鉴了谷歌Piper和Meta Sapling等大型单体仓库的成熟技术，也说明超大规模代码库的工程经验正在从少数巨头向更广范围扩散。对关注AI产业链的读者而言，这提供了一个观察窗口：AI编程能力的提升，正在倒逼整个软件研发工具链重构，而这类基础设施的改造需求，可能成为下一阶段工程软件与云基础设施投入的一个方向。