深度 | 代码不再是瓶颈管代码才是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.comGit 生错了时代要理解这件事得先看 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 写的 PRAnthropic 跑在这个量的 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 AnthropicSimon Willison — Redesigning source control at AnthropicDevOps.com — Coding Agents Broke Git’s Scaling Math. GitHub Is Rebuilding to Keep Up36氪 — 7个人、5个月Anthropic造出了Git替代品InfoQ 中文 — Claude写代码太快Git扛不住了GitHub — tinyhumansai/openscionLWN — Google Piper 技术分享The Block Beats — 终端猜 Agent 状态的时代要结束了OSC 7501每日更新。