Anthropic 正在用一套自研的版本控制系统，替换支撑软件开发二十多年的 Git。据雷峰网报道，为了让 Claude 持续生成的代码顺利进入开发流程，Anthropic 的 7 名工程师耗时 5 个月开发出版本控制系统 Scion，并将核心代码仓库迁移过去。这一动作的直接诱因，是 AI 生成代码带来的仓库操作压力急剧上升。
从数据上看，压力增长相当惊人。今年 5 月，Anthropic 每天平均合并约 2500 项代码变更，到 9 月已超过 3 万项，四个月间增长逾十倍。仅 CI 系统每天就要执行约 2500 万次代码检出。Anthropic 主分支历史接近 100 GB，压缩工作副本超过 25 GB，若每天 2500 万次检出分别获取完整副本，理论流量会超过 600 PB。写代码的速度上来了，准备仓库、同步对象和查询历史却越来越费机器。
问题根源在于 Git 的分布式设计。Git 让工程师克隆仓库后即使断网也能提交、合并、查看历史，但 Anthropic 大量读取代码的任务是始终联网的 CI 作业和 Agent 沙箱，运行几分钟便销毁，可能只需要几个文件、一份 diff，或确认两个提交的祖先关系。为这些操作准备本地仓库，重复成本越来越高。公司虽用浅克隆、稀疏检出、快照和数百台 Git 镜像缓解，但镜像仍要同步、快照会过期，历史查询还需补齐对象，仓库越活跃维护成本越高。
Scion 的思路是把客户端缩成轻量入口。提交创建、合并、变基与历史查询放到中心服务，本地仅监测文件变化、维护少量缓存，需要工作目录时按需展开。CI 若只想计算 diff，可以直接调用 API，无须完整检出。这牺牲了离线自治，却减少了重复初始化。提交格式也随之改变：Git commit 指向描述仓库状态的目录树，Scion 的 changeset 则以预写日志条目记录相对首个父提交修改过的文件，通过内容寻址指针引用数据。创建 changeset 无须生成 Git packfile，也不用立即移动共享分支，只有 main 等引用更新时，系统才对 Spanner 中的单行记录执行 compare-and-swap，Agent 并发生成变更的竞争被集中到分支引用移动时。
历史查询仍是难题：增量记录无法直接回答某行是谁改的、文件经历过什么。Scion 为 blame、路径历史与提交图跳表维护 derived data，按父提交关系预计算，或等查询发生后再生成。同期，GitHub 用微调后的 ModernBERT 替换密钥扫描中的通用大模型判断，哥伦比亚大学与 Google DeepMind 等机构则通过 BTTF 把芯片仿真波形转换成 SQLite，让 Agent 用 SQL 排查异常。这些案例指向同一趋势：围绕人类开发节奏设计的系统，开始承受 Agent 带来的另一种负载。
