7 个人、5 个月，Anthropic 造出了 Git 替代品
Git 用了 20 年才坐稳程序员世界的"水电煤"，Anthropic 只用了 5 个月就把它换掉了。
完成这件事的，不是几百人的基建团队，而是 7 名工程师，加上一个深度参与开发的 Claude。
2026 年 5 月，Anthropic 平均每天合并约 2500 次代码变更。到了 9 月，这个数字突破了 3 万次。4 个月，12 倍增长。代码合并的潜在需求几乎没有上限，每解决一个瓶颈，产出量就再涨一截。
撑不住的不是 AI，是 Git。于是 Anthropic 从零写出了内部版本控制系统 Scion、配套代码审查工具 Antique，以及代码搜索、权限管理、大规模合并机制等一系列系统，并在 5 个月内把整个单体代码仓库从 Git 整体迁移到了 Scion。
消息一出，硅谷有人感叹"RIP GIT"。但真正值得追问的不是"AI 写代码有多快"，而是另一件事：一套为人类离线工作设计的工具，正在被一群永远在线的 Agent 逼到墙角。
当 Git 遇上"无限合并"
要理解 Anthropic 为什么必须自己动手，先看它的工作负载有多特殊。
Anthropic 使用 Claude 编写软件的程度，远超绝大多数公司。它的单体仓库主分支历史已经接近 100GB，一个压缩后的工作副本超过 25GB。CI 系统每天要执行约 2500 万次代码检出，这还没算开发环境、Agent 沙箱和研究任务。如果每次都直接从 Git 拉取所需数据，每天产生的数据传输量将超过 600PB。
600PB 是什么概念？这不是"优化一下就能扛过去"的量级，而是架构层面的天花板。
Git 当然不是没有应对大仓库的手段：浅克隆、稀疏检出、Promisor Remote，以及业界通行的内部 Git 镜像、对象存储快照。Anthropic 全都用过，负载最高时甚至运行着几百台内部 Git 镜像服务器。这些办法确实撑了一段时间，但随着合并量持续上涨，维护成本越来越高。两次快照刷新之间，快照与主分支最新版本的差距越拉越大。而要让部分克隆的仓库正常执行 diff、blame 这些依赖历史的操作，又要投入越来越多的工程精力。
Anthropic 回头看，发现了一个关键问题：和大多数公司一样，它实际上一直把 Git 当作集中式系统在用，所有开发围绕一份权威仓库展开，客户端几乎全是 Agent 和自动化任务，本来就始终在线。Git 为分布式、离线开发精心设计的那些特性，在仓库不断膨胀时，反而成了扩展的枷锁。
于是问题变成了：如果从一开始就按"Agent 始终在线"这个事实来设计源代码控制系统，它应该长什么样？
Git 的"离线优先"，撞上了 Agent 的"永远在线"
Git 能成为行业标准，靠的是一套优雅的前提假设：每个克隆都是一份完整、独立的仓库，即使完全离线，开发者也能计算差异、查看历史、追踪某行代码的修改、检出任意版本。这套设计对"人类开发者加上中小型仓库"的组合近乎完美。
但 Anthropic 的客户端不是人类。它们是一群 24 小时在线、高并发、批量干活的 Agent 和 CI 任务。
Scion 的设计原则几乎每一条都冲着 Git 的前提来。
Git 假设客户端会离线，所以必须在本地留一份完整仓库。Scion 反其道而行，客户端需要什么，就从始终可达的服务器取什么，因为它的客户端几乎全是 Agent 和任务，天生在线。
在 Git 里，每个客户端都能当一台完整服务器。Scion 则把重活，比如查询历史、blame、创建提交、合并、变基，全交给服务器。客户端只维护一个有上限的本地对象缓存，把文件写到磁盘，监控文件系统变化。它几乎不用做复杂计算，本地数据自然少得多。
在 Git 里，CI 任务想查"某行代码最后谁改的"，要么自己维护一份本地仓库，要么指望厂商 API 恰好能回答。Scion 把客户端用到的所有查询能力都开放成 API，很多任务根本不需要本地仓库。Anthropic 内部的自动二分定位和代码回滚流水线，没有这种低成本、可编程的访问能力，在当下规模下根本跑不起来。
过去 Anthropic 最多跑过几百台 Git 镜像，占掉大量计算资源，而且一旦仓库超过单台镜像的磁盘或内存，就再也扩不动。Scion 把数据分布式存储，每个组件独立扩展，整个系统里没有任何一份完整实体化的代码仓库，连服务器上都没有，也因此省掉了 Git packfile 那套繁重的仓库维护操作。
Git 是本地提交再 push 共享，Scion 的提交、变基、合并全在服务器端完成，不需要 push。创建提交和更新数据结构的成本，必须只和本次变更的大小成正比，不能随着整个仓库膨胀而上涨。Scion 还尽量减少 ref 的使用，因为分支和标签这类需要所有服务器保持一致的全局数据，天然是扩展瓶颈。
Anthropic 的单体仓库非常庞大，CI 每天又要做数千万次检出，能省则省。Scion 的协议围绕稀疏检出和虚拟化检出设计，稀疏检出只包含客户端明确需要的目录，虚拟化检出则等到真正读取时才把文件加载出来。
这套架构带来的结果是量级的。据外部观察者引用 Anthropic 披露的数据，Scion 的基础设施占用比旧 Git 镜像方案少了约 200 倍，检出速度从分钟级降到秒级。
7 个人 5 个月，背后是"AI 写代码"和"AI 写系统"的双重循环
7 名工程师、5 个月，从零造出一套版本控制系统并完成全量迁移，这个速度放在几年前不可想象。但真正让这件事成立的，是两层循环的同时存在。
一层循环，是 Claude 写业务代码的速度，把 Git 逼到了墙角。没有 AI 编程带来的合并量暴涨，Anthropic 根本不会有动力去碰版本控制这个"基础设施里的基础设施"。
另一层循环，是 Claude 反过来参与 Scion 本身的建造。Anthropic 在博客里披露了一个细节：年初时，团队基本靠手写完成了 git-to-Scion 数据摄入流水线的第一个原型，当时觉得"已经不错了"。直到他们拿到早期内部版本的 Claude Mythos Preview，让对方重写整个流水线，没有任何额外指令，模型交出的版本内存占用只有原来的 1/20，速度快了 4 倍，还完整保留了摄入顺序和数据结构周围那些隐式的不变量。
这是一个很微妙的信号。手写原型的人类工程师，和接手优化的模型，面对的是同一套需求。模型之所以能交出更好的答案，不是因为它更懂版本控制，而是因为它能在更大的代码上下文里看见人类容易忽略的整体约束。Anthropic 在博客里也承认："拥有这些模型的内部优势，怎么强调都不为过。"
这也是 Scion 项目最容易被误读的地方。人们看到"7 个人 5 个月"，容易得出"AI 让造轮子变便宜了"的结论。但更准确的读法是：AI 既制造了问题，也提供了工具，而真正稀缺的，是对问题本身的重新定义，是意识到 Git 的离线优先假设已经不再成立，是意识到应该按"客户端永远在线"来重画架构。这种判断，目前仍然在人类手里。
Scion 不会取代 Git，但它会逼着 Git 进化
Anthropic 说得很直白：Scion 绝不适合作为 Git 的通用替代品。它的设计思路主要适用于真正庞大的单体仓库，要么有数万名工程师共同使用，要么有大量 Agent 持续生成代码。
而且 Anthropic 有一个别人很难复制的条件：它愿意为内部任务消耗的 Token 数量，远超任何一家正常公司在现实中愿意承担的规模。这样做既是为了满足自身开发需求，也是为了测试 Claude 的能力边界。
把 Scion 做成一套能被广泛采用的产品，也非常困难。它与 Git 差异太大，其他公司想迁移，就得把开发流程的各个环节整个搬过去，还要配套自己的代码审查、代码搜索和 CI 系统。Anthropic 内部的这些组件都是高度定制的，外人很难直接拿来用。他们也担心，如果硬要做一个满足所有人需求的公开版本，最后做出来的东西反而没什么用。
但这不意味着 Scion 的故事与普通人无关。Anthropic 预计，未来 6 到 12 个月，这类问题会变得越来越普遍。如果每一家用 Git 的公司都要各自为战，显然是巨大的工程资源浪费。
所以他们选择了一条更务实的路：不卖产品，而是把设计思路公开，让其他团队能把 Scion 里行之有效的部分应用到 Git 上，而无须完全抛弃 Git 现有的整体模式。比如，Git 服务器不一定非要用和客户端一样的工作方式，新的服务器架构已经能显著提升扩展能力。Git 托管平台可以像 Scion 一样提供完整的服务器端 RPC 接口，甚至在不同平台之间标准化，让 Git 客户端直接调用。现有的稀疏检出、浅克隆等功能，也可以改进得更容易组合使用。
博客最后，Anthropic 特意感谢了 Git 社区近 20 年来为百万级开发者所做的扩展工作，并把自己的贡献定义得很克制："分享我们对 agentic 软件开发如何与这些系统交互的早期观察，以便与 GitHub、GitLab 和开源社区合作，支持开发者不断变化的需求。"
这句话的潜台词是：真正的战场不在"换掉 Git"，而在"让 Git 学会和 Agent 共存"。
被推倒的不只是 Git
Scion 的故事，表面看是一次基础设施迁移，底层是一次开发范式的切换。
过去 20 年，整个软件工程工具链都是围着"人类在打字"这个前提搭起来的：编辑器等你的手指，版本控制等你的提交，CI 等你的推送，代码审查等你的空闲时间。Git 只是其中最显眼的一个。
当 Agent 开始以人类无法企及的速度生产代码，这条链子上每一个"等人"的环节都会依次失效。Anthropic 撞到的第一堵墙是源代码控制，下一堵墙可能已经在排队。Anthropic 在分享中提到，在 Agent 大规模编程的场景下，传统的合并队列可能已经不太合理，因为当一组测试还在运行时，可能有几百甚至几千次代码变更被合并进仓库。这时候 CI 该怎么工作？他们把更多精力投向了合并后的自动化测试和部署前的自动化测试，因为 Claude 通常能在人类工程师发现冲突之前就把问题修好。
甚至连运维方式都在变。Anthropic 大量使用 Claude Tag 来监控系统组件，专门建了一些 Slack 频道，让 Claude 持续盯着某个组件的运行状况。这些被称作"Superfans"（超级粉丝）的 Claude，能访问系统遥测和日志，像经验丰富又有大把时间的工程师一样不断刷新监控图表，捕捉传统告警发现不了的细微异常。目前团队已经有负责 scion-daemon 的 Superfan、负责 scion-cache 的 Superfan，还有专门关注 Antique 合并队列的 Superfan。
这才是"7 个人 5 个月"背后真正的冲击：当 AI 不仅能写业务代码，还能参与基础设施建造、还能 24 小时值守运维时，软件工程的组织方式、工具形态、人力配置，都会被重新定义。
Git 会不会死？短期内不会。但对越来越多公司来说，真正的问题已经不是"要不要换掉 Git"，而是"我的开发基础设施，还能撑住多久的 AI 编程速度"。
墙已经在那儿了。区别只是，谁先撞上。
快报