深度 | 代码不再是瓶颈，管代码才是：Anthropic 7 人 5 个月重造版本控制
10 月 13 日，Anthropic 在一篇工程博客里，讲了一件很少有公司愿意公开承认的事：Claude 写代码的速度，已经快到了让 Git 这个用了二十年的工具扛不住。他们自己给出的数字是，日均合并代码改动从今年 5 月的约 2500 条，涨到 9 月的 3 万条以上，四个月翻了 12 倍。
真正让人意外的是他们接下来的动作。Anthropic 没有继续给 Git 打补丁，而是用 7 个人、5 个月，把整个 monorepo 从 Git 迁到了一套自研的集中式版本控制系统 Scion 上。shallow clone、sparse checkout、几百台内部镜像，这些 Git 的常规救火手段他们全用过，最后得出的结论是：Git 生错了时代。
上图：Anthropic 官网工程博客报道页原图（每日合并代码改动图表），2026-10-13，来源：anthropic.com
Git 生错了时代
要理解这件事，得先看 Git 的出身。Git 是个分布式系统，每个 clone 都是一份完整的仓库，能离线算 diff、读历史、看 blame。这套设计对绝大多数仓库是对的，也是它能称王的原因。但放到 Anthropic 的场景里就全反了：主分支历史接近 100GB，压缩后的工作副本超过 25GB，光给 CI 每天就要做约 2500 万次检出，按最朴素的方式 fetch，一天就是 600PB 以上的流量。
Anthropic 自己的复盘点破了一层窗户纸：大多数公司早就把 Git 当成了「一台权威副本加一堆客户端」在用，而他们几乎所有的客户端，都是永远在线的 Agent 和自动化任务。Git 那些为「分布式、离线工作」设计的长处，在仓库变大之后反而成了拖累。于是他们换了个问法：如果从一开始就假设写代码的几乎全是永远在线的 Agent，版本控制该长什么样？
上图：Git 的分布式离线设计，在 Agent 大规模产出代码后失效的传导链。
这里有个容易被忽略的分层：为人类规模设计的工具链，接不住 Agent 的产出规模。人一天写几十行、提交几次，Agent 一天产出几千个改动，两者对底层工具的要求根本不是一个数量级。
Scion 把重活交给了服务器
Scion 的思路一句话讲清：把重活全交给服务器，客户端只留一个有界的本地缓存。它借鉴了 Google Piper 和 Meta Sapling 这两套大仓方案，但触发原因完全不同。Piper 和 Sapling 是为几万名人类工程师建的，Scion 是为海量 Agent 的产出速度建的。
数据结构的单位从快照换成了变更集。Git 的 commit 存指向树的指针；Scion 的变更集只记「相对第一个父提交改了哪些文件」，加上指向 blob 存储的内容寻址指针。变更集在服务端创建、立刻全局可用，没有 packfile 要接收、没有锁和跨服务器协调，commit 的成本随改动大小而不是仓库大小走。
存储全内容寻址、不可变，任何服务器都能缓存任何数据而不用协商，整套服务可以水平扩展。检出架构是三层缓存：节点上的 scion-daemon，区域的 scion-cache 直接从内存流式供给，权威的 scion-server 背靠 Spanner 和云存储，每一层命中率都超过 99%。官方给出的成效很硬：基础设施 CPU 和内存足迹比旧镜像集群小 200 倍，检出快了两个数量级，仅 CI 一项就省出 25% 的 CPU。
上图：Scion 的三层缓存架构，客户端、节点、区域、权威四层各司其职。
还有一个中文报道普遍略过的细节：Scion 本身就是 Claude 参与建的。一个早期的 Claude Mythos Preview 内部快照，把团队手写的 git 到 Scion 迁移管道整个重写了一遍，内存省 20 倍、快 4 倍。Anthropic 的工程师现在普遍承认 Claude 写代码比他们强，工程师的角色退成了做高层设计、以及在 Claude 越界时对它说不。一个能把 AI 顶爆的工具，和一个由 AI 帮着建出来的工具，其实是同一枚硬币的两面。
这跟普通开发者有关系
如果你觉得这只是 Anthropic 自己用 Claude 用得太狠，那看平台侧的数据。
GitHub 的量级在 2026 年被 AI 编码工具推上了新台阶：9 月单月 73.8 亿次 commit，是去年同期的 5 倍以上；push 同比增长 4.9 倍；GitHub Actions 9 月跑了 32.6 亿次。有报道直接点出，GitHub 正在重建它的 Spokes 存储系统，把权威数据迁到 Azure Blob，内部基准显示写入吞吐最高提升 35 倍。对照更直观：有分析说 Stripe 每天合并约 200 个 Agent 写的 PR，Anthropic 跑在这个量的 150 倍上下。
但真正容易被忽略的，是瓶颈的下一站。版本控制能用「服务端集中加内容寻址」去解，解完之后压力不会消失，只会往下传导，落点就是代码评审。哈佛大学 Chen 与 Stratton 2026 年 8 月的工作论文，分析了约 3 亿个事件、718 家公司，结论很刺眼：AI 让代码行数加了三成、commit 加了两成，但「完成的软件」没有统计学上的显著提升，评审和合并时间反而拖长了一半，从约 7 天到 10.5 天。GitClear 的独立研究给出同一个方向：AI 生成的代码平均每个 PR 有 10.83 个问题，人类写的是 6.45 个。AI 把「写」这一环压到接近零，「验证」这一环却在膨胀。
上图：瓶颈沿写、管、验链条向下传导，评审是当前最细的一环。
开源社区的反应也比想象中快。Scion 博客发布没几天，GitHub 上就出现了一个叫 OpenScion 的项目，自称是「基于 Anthropic Scion 设计的开源版本控制系统，面向以 AI Agent 和 CI 为主要客户端的大型 monorepo」，用 BLAKE3 做内容寻址，目前还在设计阶段。它未必能成，但它的出现本身，说明「为 Agent 重造版本控制」这个命题已经有人动手了。
中文社区这边，报道不少，角度也整齐。36氪写「7个人、5个月，Anthropic造出了Git替代品」，InfoQ 中文写「Claude写代码太快，Git扛不住了」，智东西写「连Git都要重做」。但多数报道停在技术新闻层面，「为什么这会成为普遍问题」「国内托管平台怎么办」这两个问题基本没人往下挖。Gitee、GitCode、阿里云效、腾讯云效这几家，检索里看不到任何面向 AI Agent 大仓方向的公开动作。国内现在还在「Agent 在写代码，但量级没到顶爆工具」的阶段，加上有 GitHub 这个上游可以等，主动重造的动力确实不足。
下一波窗口是「管代码」的基础设施
我判断，「agent-scale 的开发基础设施」会继 agent 结构之后，成为下一波明确的创业和投入窗口，Scion 是它的第一个标志性事件。瓶颈迁移是结构性的，AI 写代码的速度只会继续加速，工具错配只会越来越大。GitHub 的重建和哈佛论文的数据表明，压力已经扩散到了全行业。Anthropic 自己预判这类问题未来半年到一年会更普遍，并且表态要跟 GitHub、GitLab 和开源社区合作。
我预判两个方向最值得盯。一个是「Git 服务端 Scion 化」这条线，GitHub 和 GitLab 会不会推出面向大仓和 Agent 工作负载的服务端能力，这比任何开源替代品都更能定义市场。另一个是「评审自动化」，版本控制的瓶颈解掉之后，压力会压到人类评审上，谁先做出可信的自动评审加语义级审批约束，谁就拿到了下一个堵点的钥匙。
不过，Scion 能在多大程度上复制，要打个问号。Anthropic 自己承认，它愿意为内部使用花的 token 远超任何企业，而 Scion 高度绑定它自研的评审、搜索和 CI，别的公司迁不过去。所以它更像先行者的内部答案，行业的标准答案，大概率以「Git 服务端进化加托管平台能力加开源再实现」的组合形式出现。
代码不再是瓶颈，管代码才是。这句话在 10 月 13 日之前还只是工程师的调侃，现在，Anthropic 用 7 个人、5 个月和一整个迁移，把它变成了一个行业必须正面回答的问题。
参考来源
Anthropic 官方工程博客 — Redesigning source control at Anthropic
Simon Willison — Redesigning source control at Anthropic
DevOps.com — Coding Agents Broke Git’s Scaling Math. GitHub Is Rebuilding to Keep Up
36氪 — 7个人、5个月，Anthropic造出了Git替代品
InfoQ 中文 — Claude写代码太快，Git扛不住了
GitHub — tinyhumansai/openscion
LWN — Google Piper 技术分享
The Block Beats — 终端猜 Agent 状态的时代要结束了（OSC 7501）
每日更新。
