Claude 写代码的速度，先把 Anthropic 自己的代码仓库顶穿了。今年 5 月，他们每天平均合并约 2500 项变更，到 9 月这个数字超过 3 万；CI 每天要跑约 2500 万次代码检出，而主分支历史接近 100 GB。按 Anthropic 的估算，如果这些检出各自拉一份完整仓库，一天的流量会超过 600 PB——这个数是假设值，不是真实流量，但它足以说明问题：给「人」设计的 Git，正在被「Agent」的用法压到极限。解决办法，是 7 名工程师用 5 个月写出一套新的版本控制系统 Scion，并把核心代码仓库搬了过去。
先看压垮它的两个数字
第一个是合并量：从 5 月的日均约 2500 项，涨到 9 月的日均 3 万项以上。官方口径是「十倍以上」，按数字算约 12 倍，而且这统计的是合并进一个内部 monorepo 的变更数，不是行数也不是提交数。第二个是读取量：仅 CI 系统每天就要执行约 2500 万次代码检出，这还没算开发者环境、Agent 沙箱和研究任务。主分支历史接近 100 GB，压缩后的工作副本超过 25 GB——2500 万次检出哪怕只有一部分按老办法各取完整副本，重复开销就是天文数字。写代码的速度上来了，准备仓库、同步对象、查询历史这些「后勤」反而成了最大瓶颈。
问题不在 Git 慢，在它假设你手里有整个仓库
Git 的分布式设计，是让工程师克隆仓库后离线也能提交、合并、查历史。对绝大多数仓库，Anthropic 也承认这是正确设计，也是 Git 能成为标准的重要原因。但 Anthropic 的大量读取来自另一类负载：始终联网的 CI 作业和 Agent 沙箱，跑几分钟就销毁，可能只需要几个文件、一份 diff，或者确认两个提交的祖先关系。为这类操作准备一份本地仓库，重复成本随合并频率线性上涨。
常规手段他们先用遍了：浅克隆、稀疏检出、promisor remote、blob 存储里的仓库快照，峰值时内部跑着几百个 Git 镜像。但镜像本身要同步，快照在两次刷新之间会落后于主分支，部分克隆上的 diff 和 blame 也越来越难维护。仓库越活跃，这套补丁的维护成本越高——这是设计假设的问题，不是调参能解决的。
Scion 把提交搬到了服务器上
Scion 的设计原则里，分量最重的一条是客户端与服务端的不对称：提交、合并、变基、历史查询全部在服务端完成，客户端只负责监测文件变化、维护有限的缓存和一份可选的工作目录，传统工作流里的 push 就此消失。提交的成本取决于这次改了什么，而不是仓库有多大。
数据结构也换掉了。Git 的 commit 指向一棵描述仓库状态的目录树；Scion 的 changeset 则是预写日志里的一条记录，只列出相对第一个父提交修改过的文件，再用内容寻址指针指向 blob 存储里的压缩内容。仓库不在任何地方完整落盘——连服务端也没有——因此没有 Git 的 packfile，也就没有随之而来的仓库维护。分支和标签这类全局引用被刻意弱化，只有 main 与发布分支需要更新，而更新一次引用，是对 Spanner 里单行记录做一次 compare-and-swap：大量 Agent 并发生成变更的竞争，被收敛到极少数写点上。
CI 如果只想算 diff，直接调服务端 API，不必检出任何东西。代价同样明摆着：客户端必须在线，离线自治没有了。用 Scion 团队自己在社区里的说法，做离线提交等于要把服务端的全部逻辑搬进客户端，而且即便那样，历史、blame、merge base 这类全图问题依然答不上来。
查历史才是真正的难题
changeset 是增量记录，天生回答不了「这一行是谁改的」「这个文件经历过什么」。Scion 的办法是为 blame、路径历史与提交图跳表维护一套派生数据：要么按父提交关系预计算好，要么等查询发生时再生成。这部分工程量不见得比「把提交搬到服务端」小——把写路径集中起来容易，把读路径重新设计一遍才是苦活。
这套东西，Anthropic 不打算给你用
迁移那 5 个月里产出的不止 Scion：还有代码审查工具 Antique、一套代码搜索，以及源码权限系统。有意思的是，把 Git 历史导入 Scion 的管线最初是手写的，后来交给内部一个早期版本的 Claude 重写，官方说法是内存占用降到原来的二十分之一、速度提升 4 倍——这类自报数字没有公开的测试方法，当方向参考即可。
Scion 没有开源，没有公开仓库，也没有价格表。Anthropic 的原话是它「绝不是 Git 的通用替代品」，只对真正巨大的 monorepo 有意义。参照系是 Google 的 Piper、Meta 的 Sapling——为超大代码库重造版本控制，大厂早有先例；Anthropic 的特殊之处在于，一个规模远小于这两家工程组织的团队，因为 Agent 的产出速度提前撞上了同一堵墙。他们更想把架构经验推回 Git 生态：托管平台可以提供更完整的服务端接口，直接回答历史、blame、merge base 而不要求完整克隆。
同期还有两件事，指向同一个方向
GitHub 在密钥扫描里把通用大模型换掉了：先用规则挑出候选串，再用微调过的 ModernBERT 分类器判真伪。理由很实际——候选串越多，大模型的推理成本和延迟越高，pre-commit 的反馈就被拖慢；换成专用小分类器，判得更准，也更快更便宜。
另一件更远一些：哥伦比亚大学与 Google DeepMind 等机构的 BTTF，把芯片仿真的波形数据转成 SQLite，让 Agent 直接用 SQL 排查异常，而不是让模型读图、读报告。这三件事放在一起看，共同点不是「AI 有多强」，而是负载变了——围绕人类提交节奏设计的工具链，正在按 Agent 的吞吐量重新排列。
写在最后
这件事最容易被读成「Git 要完了」，方向恰恰相反：Anthropic 自己都说，Git 的离线设计对绝大多数仓库仍是正确答案，Scion 只解决「每天几千万次检出、几万次合并」这一种极端。真正值得带走的是三个思路——把历史查询和 diff 做成服务端接口、让工作副本可选且稀疏、别让每次提交都去动全局引用。对多数团队，现实动作仍是把浅克隆、稀疏检出和缓存用好；等你的 Agent 一天真的提交几千次合并，再考虑更重的方案也不迟。
事实与数字据 2026 年 10 月 20 日公开报道（含雷峰网报道与 Anthropic 架构说明的转述）整理；「十倍以上」「600 PB」等均为厂商口径，其中 600 PB 为假设值而非实际流量；Scion 未开源、无公开代码，本文不对其内部实现作独立验证。
