核心结论：Anthropic 在 2026 年 10 月 13 日公布内部源码管理系统 Scion 的设计。随着其单体仓库日均合并量从 2026 年 5 月约 2500 次增长到 9 月逾 3 万次，Git 镜像、检出和历史查询成为开发基础设施瓶颈。Anthropic 称，团队用五个月完成向 Scion 的迁移。这是一项针对超大仓库与高频智能体开发负载的内部工程实践，不是面向普通团队发布的 Git 替代产品。
为何原有源码管理方式遇到瓶颈？
Anthropic 披露，其主分支历史接近 100 GB，压缩后的工作副本超过 25 GB；仅 CI 每天约有 2500 万次代码检出。若按完整 Git 数据直接获取，理论流量会非常高。团队曾使用浅克隆、稀疏检出、数百个内部 Git 镜像及仓库快照，但随着合并频率上升，这些措施的维护成本与历史查询难度继续增加。
这组数字是 Anthropic 对自身环境的披露，不能外推为一般企业的仓库规模。文章也承认，Git 的离线与分布式特性仍适合绝大多数仓库。
Scion 的核心设计是什么？
把历史计算放到服务端
Scion 假定大多数客户端是始终在线的智能体与任务进程。服务端负责创建提交、合并、变基及回答差异、历史和归属查询；客户端保留有限本地缓存与所需文件。这样 CI 和工具可直接调用源码管理 API，无须各自维护完整仓库。
只获取实际需要的代码
Scion 以稀疏检出和按需实体化文件为中心。其 changeset 记录相对父提交发生变化的文件及指向压缩内容的内容寻址引用，历史归属等查询由派生数据结构支持。客户端按需请求树与文件对象，节点守护进程和区域缓存复用不可变对象，避免每个任务反复传输整库数据。
减少全局协调
Anthropic 的设计尽量减少对分支等全局引用的依赖，使提交创建成本与变更规模相关，而不是随整库规模增长；存储与查询组件可横向扩展。这些取舍依赖持续在线的服务器和配套代码评审、搜索、权限及 CI 体系。
效果数据应如何理解？
据 Anthropic 的内部运行数据，Scion 的缓存层命中率均超过 99%；相较此前 Git 镜像设施，源码管理基础设施的 CPU 与内存占用缩小约 200 倍；CI 和研究任务的代码检出从分钟级降至秒级，CI 获得约 25% 的 CPU 容量收益。这些是其特定负载下的厂商自述，并非独立基准测试，也不代表其他组织可复制相同比例。
Anthropic 还介绍，七人团队同时构建 Scion 和代码评审工具 Antique，并在五个月内完成迁移。Claude 帮助加快实现与优化，但工程师仍负责系统边界、架构取舍及每次变更的审查。文中所述智能体开发规模与内部模型使用条件也具有特殊性。
企业研发团队能借鉴什么？
中蓝科创观察：多数团队应先测量克隆、检出、构建、测试与合并队列的真实耗时，再决定优化顺序。若瓶颈集中于重复拉取和检出，可优先评估现有 Git 的稀疏检出、浅克隆、缓存、镜像和按需 API；若瓶颈是代码质量与审批，则应加强变更分级、自动测试和敏感目录权限。只有在仓库规模和智能体并发量确实达到类似量级、且能够承担整套工具链迁移时，重构源码管理服务才可能合理。
Anthropic 明确表示 Scion 不适合作为通用 Git 替代品，也难以把这套高度定制的内部系统直接开放给其他组织。该案例更普遍的启示是：AI 编码吞吐量提高后，源码管理、评审和 CI 必须一起衡量，不能只看代码生成速度。
资料来源：Anthropic Engineering《Redesigning source control at Anthropic》，发布于 2026 年 10 月 13 日。性能与规模数据均为 Anthropic 披露；企业应用建议为中蓝科创分析。
