2026年10月13日，Anthropic 发布工程博客宣布已用自研源码控制系统 Scion 完成单体仓库从 Git 的迁移，由 7 人团队在 5 个月内交付。触发这次重构的是代码产量：日均合并变更从 5 月约 2500 次增至 9 月超过 3 万次，四个月增长 12 倍。迁移后 Scion 的 CPU 与内存占用降至原 Git 镜像方案的 1/200，代码检出从几分钟缩短到几秒，CI 单独释放 25% 的 CPU 容量。Anthropic 明确表示不会开源 Scion。
一次被代码产量逼出来的重构
Anthropic 在 10 月 13 日的工程博客中给出的核心事实很直接：源码控制已经成为其最大的研发瓶颈。2026 年 5 月，公司日均合并约 2500 处代码变更；到 9 月，这个数字超过 3 万，四个月增长 12 倍。团队在文中表示，每当消除一个瓶颈，代码产量就会立刻再上一个台阶。
除 Scion 外，该团队还交付了代码审查平台 Antique、代码搜索与源码控制身份访问管理系统。Anthropic 明确表示不会开源 Scion，理由是组件高度依赖自身环境，难以做成通用 Git 替代品。
Git 为什么扛不住：2500 万次检出与 600PB 日流量
Anthropic 主分支历史接近 100GB，压缩后工作副本超过 25GB；仅 CI 一项每天就要约 2500 万次检出，还不包括开发者环境、智能体沙箱与研究任务。朴素 Git 拉取日流量会超过 600PB。峰值时期公司运行数百个内部 Git 镜像吸收负载，直到仓库体积超出镜像的磁盘与内存，这套权宜之计才失效。
更本质的错配在模型假设：Git 为离线、分布式协作而设计，而 Anthropic 的客户端绝大多数是天然在线的智能体与 CI 作业。
Scion 的三个设计取舍
第一，把提交、合并与变基放到服务端执行，放弃 Git 的分布式模型；工作单位变成写前日志中的“变更集”，只记录变更文件与指向 blob 存储的内容寻址指针。第二，把 blame、路径历史与提交图结构当作派生数据按需计算，而非随仓库分发。第三，默认稀疏或虚拟化检出，树与对象通过三层缓存按需拉取，从每节点守护进程直到由 Spanner 与云存储支撑的服务端。
团队还放弃工业标准的全局仓库锁与合并队列，转而投入合并后、部署前的自动化测试；代价是并发变更可能冲突，而 Anthropic 的说法是 Claude 修冲突通常比人类识别更快。
效率账：1/200 占用、秒级检出、25% CI 容量
结果层面有三组数字最有说服力：Scion 基础设施的 CPU 与内存占用为原 Git 镜像方案的 1/200；CI 与研究作业检出代码的速度提升约两个数量级，从几分钟缩短到几秒；仅 CI 一项就释放 25% 的 CPU 容量。每层缓存命中率都在 99% 以上，也不需要长期状态。
这套系统本身也是智能体协作的产物：Claude 参与编写了仿真、模糊测试与限流代码，并用预览版重写 Git 到 Scion 的导入管道，内存降至二十分之一、速度提升 4 倍。工程师的角色随之转向系统级取舍，以及在智能体过度工程时说“不”。
对软件外包与交付体系的启示
Scion 不会对外发布，但它的诊断逻辑对任何引入编码智能体的团队都成立：当代码产量在几个月内涨一个数量级，最先崩的不是写代码环节，而是版本控制、构建与 CI 这类为人工节奏设计的基础设施。Anthropic 预计这类扩展问题在未来 6 到 12 个月会更加普遍。
对以软件外包方式交付项目的团队，可迁移的经验有三条：检出与构建改成按需拉取而非全量复制；用合并后自动化测试替代全局锁；提前为智能体准备独立身份与权限体系。这三条都不依赖 Scion 的代码，只依赖对瓶颈位置的判断。
常见问题（FAQ）
因为代码产量超出了 Git 的承载区间。其日均合并变更从 2026 年 5 月约 2500 次增至 9 月超过 3 万次，主分支历史近 100GB，仅 CI 每天就要约 2500 万次检出，朴素 Git 日流量会超过 600PB。Scion 由 7 人团队 5 个月建成，CPU 与内存占用降至原 Git 镜像方案的 1/200。
不会。Anthropic 表示 Scion 不适合作为通用 Git 替代品，其代码审查、代码搜索与 CI 都需按公司情况高度定制，因此只公开设计思路，供 GitHub、GitLab 与开源社区借鉴。普通团队可迁移的是思路本身：服务端执行提交与合并、按需拉取树与对象、用合并后测试取代全局锁。
瓶颈往往不在写代码环节，而在版本控制、构建与 CI 等为人工节奏设计的基础设施。建议提前做好三件事：检出与构建改为按需拉取、用合并后自动化测试替代全局合并锁、为智能体配置独立身份与权限。否则代码产量一旦放大一个数量级，交付流水线会先于模型能力出问题。