Claude 给自己写了套源码管理：Graft 让代码合并从 2500 跳到 3 万+ 之后才需要的干活工具
先交代个背景。Anthropic 前阵子公开讲过，他们的代码合并规模从每天 2,500 次一路涨到 30,000 多，最后被逼着自建了一套内部的版本控制系统。今天有人在 Hacker News 上把这个思路开源了，项目叫 Graft，作者说就是用 Claude 写出来的开源平替版本，Apache-2.0 协议，直连 GitHub。
这东西要解决的不是普通开发者的痛点，而是「Agent 规模」的 monorepo——也就是仓库大到几万、几十万文件，同时跑大量 AI agent 并发提交、并发合并，原来的 Git 到这一步就开始明显拖后腿。作者给了一组在 100k 文件 monorepo 上的对比数据，看着挺扎眼：sparse checkout 比 git 快 12 倍，并发落地（land）的吞吐高了 82 倍，grep 不用 clone 就能搜，速度快 29 倍，整体存储占用比 git gc --aggressive 之后还小。
这几个数字里我比较在意的其实是「grep 不需要 clone」这件事。真跑过超大仓库的人都懂，每次要搜个符号、看个调用链，往往得先等 checkout 铺开，或者本地维护一份完整镜像，硬盘和内存都被吃得很疼。如果检索能直接打远端索引，很多日常动作的体感会完全不一样，这是比「快几倍」更实际的结构性变化。
当然，得说清楚这还只是个 2 points、1 条评论的 Show HN 新项目。数据是作者自报的 benchmark，不是第三方验证，也没有公开的跨平台测评。Agent 生态里宣称自己解决了 Git 规模问题的工具不少，最后能活下来的不多。但这个事情的信号反而值得留意：当一个头部模型公司被 merge 规模逼到自建版本控制，说明「AGI 时代的仓库管理」已经从概念变成了真实约束条件。
开源之后意味着什么？你不一定非得等巨头把内部基建开源，可以自己评估这套设计合不合用，看看它是真重做了对象存储和索引层，还是只是在 Git 外面套了层并发的壳。这个我暂时还没法从公开信息里完全确认，得看代码结构。
如果手头有几十万文件的仓库，或者跑着一堆 agent 在并行改代码，可以点进 GitHub 看看它的设计文档和 benchmark 细节。3 天前的痛苦是真真切切的，能有个开源的干法可以试，总比干等着强。
相关链接：
- Graft 项目主页：https://github.com/VishiATChoudhary/graft
- Hacker News 讨论：https://news.ycombinator.com/item?id=50085180