先看证据
变化不只是提交变多
Anthropic 在 2026 年 10 月 13 日介绍了 Scion：一套内部源代码管理系统，用来替代公司大型 monorepo 中的 Git，并服务于 CI、开发环境和研究任务。Anthropic 给出的直接背景是代码变更量迅速上升，原有的仓库获取与维护方式开始拖慢整个开发流程。
这次重构值得技术负责人读，不是因为它证明了 Git 对所有团队都不够用，而是因为它暴露了瓶颈位置的变化。代码生成变快之后，获取代码、查询历史、运行 CI 这些原本不显眼的环节，可能开始消耗更多基础设施资源。源控因此不再只是开发者本机上的工具选择，也成为智能体工作流能否扩展的一部分。
检出规模改变了成本结构
Anthropic 报告称，日均合入的代码变更从 2026 年 5 月约 2,500 次，升至 9 月超过 30,000 次。主分支历史接近 100 GB，压缩后的工作副本超过 25 GB，而 CI 每天约检出代码 2,500 万次。这里的“代码变更”不应直接等同于 Git commit 数，但这些数字共同说明，仓库访问频率和单次获取体量都已成为系统设计的重要变量。
Anthropic 还估算，如果每次 CI 检出都朴素地获取 Git 数据，流量会超过每天 600 PB。这个数字是特定假设下的推算，并非实测网络流量；它的价值在于说明重复获取的放大效应，而不是证明公司真的传输了这么多数据。高峰期运行数百个内部 Git 镜像，也显示团队此前需要用大量副本应对不同任务的访问需求。
Scion 把完整克隆换成按需访问
Scion 采用客户端—服务器架构。服务器负责提交、合并、变基，以及历史和 blame 查询，客户端只保留有上限的对象缓存、工作副本和文件变更监控。CI 或内部工具可以通过 API 查询信息，而不必为每项任务先准备一份完整仓库。
一次变更以 changeset 表示，记录相对于首个父提交发生变化的文件，并用内容寻址指针引用压缩后的文件内容。客户端需要文件时，再按需请求目录树和对象，而不是先接收大型 packfile；稀疏检出只取指定目录，虚拟检出则按需物化文件。缓存可以在不同层级转发对象请求，Anthropic 称各层缓存命中率都超过 99%，并设置层级隔离，以免区域缓存故障直接压垮上游服务。
因此，Scion 的关键不是单纯把 Git 的某个操作做快，而是重新选择数据应放在哪里、何时传输。Git 的分布式设计让本地完整克隆可以离线操作；Scion 则把更多历史操作和数据服务放到服务器端，换取对在线 CI 和智能体任务更精细的按需分发。两种设计优化的是不同工作条件。
性能数字说明了什么，又没说明什么
Anthropic 报告称，Scion 基础设施的 CPU 和内存需求规模比旧 Git 镜像设施小 200 倍，CI 和研究任务的检出速度快两个数量级，从分钟级降到秒级，CI 单项则获得 25% 的 CPU 容量收益。公司还称 Scion 各层缓存命中率超过 99%。这些结果与“减少完整副本、避免重复传输”的设计目标相吻合，但都是 Anthropic 发布的内部数据。
公开材料没有给出足以独立复现这些数字的完整基准方法、工作负载范围和成本口径。因此，200 倍应理解为 CPU 与内存需求规模的对比，不能改写成总成本下降 200 倍；检出速度提升也不能直接推导出所有构建任务都会同幅提速。对准备借鉴的团队来说，重要的不是照搬这些结果，而是先分别测量镜像资源、检出耗时、缓存命中和 CI 机器占用。
迁移的边界比架构图更重要
Anthropic 称，七人团队在五个月内构建 Scion、代码评审工具 Antique 及相关系统，并完成 Git 迁移；同期日合入代码变更增长约十倍。这个时间线展示了快速重构的可能性，却不能证明增长由 Scion 带来，也不能说明迁移只涉及版本控制。代码评审、搜索和 CI 都需要与新系统配套，工程投入显然不止替换一个客户端。
Anthropic 明确表示 Scion 不适合一般用途，也没有称它已作为通用产品公开提供。集中式服务减少了每个任务维护完整仓库副本的负担，但也使客户端更依赖服务端和网络可用性，放弃了一部分完整克隆离线工作的便利。对于超大型 monorepo，值得先核算重复克隆和镜像是否已成为可测量的瓶颈，再评估按需检出与配套系统迁移的收益；如果问题尚未出现，重造源控本身很可能只是把复杂度换了一个位置。