2026 年 9 月，Anthropic 的代码仓库平均每天合并超过 3 万笔变更。按一天 86400 秒摊开，不到 3 秒就有一笔新代码并进主线，昼夜不停。
就在四个月前，这个数字还是约 2500 笔。四个月涨了 12 倍，一套全世界通用了二十年的工具，就这样被挤爆了。
这套工具叫 Git。它是程序员的「总账本」：谁在什么时候改了哪一行、为什么改，都记在里面；改坏了可以翻回旧账，几个人同时改也能把各自的改动对齐、拼回一本。今天几乎所有软件公司都用它管代码，Linux 操作系统的内核也靠它维护。
Anthropic 换掉的正是这本账。挤爆 Git 的不是代码太多，而是取代码、改代码的「人」变了：Anthropic 的仓库里，最主要的用户是永远在线、成千上万并发的智能体。AI 写代码的瓶颈从来不在「写」，而在写完之后的取、审、合、测；当智能体让一家员工以千计的公司长出谷歌级别的代码流量，它只能走谷歌十年前走过的那条路——集中到服务器，用到哪个文件才取哪个文件。
Git 是为一个会断网的人设计的
Git 诞生于 2005 年，最初就是为了管理 Linux 内核的开发。那是一群分散在世界各地、各自在自己电脑上干活的志愿者，网络不总是可靠，也没有谁愿意把命门交给一台中央服务器。
于是 Git 选了「去中心化」：每个人电脑上都存一份完整的仓库，连同从第一天起的全部历史。断了网照样能查旧账、能提交、能开新分支（分支就是从主线复制出一条岔路，在上面改，改好再并回去）。服务器只是大家约定碰头交换改动的地方。
这个设计好用到了家。它撑住了 Linux，撑住了几乎所有公司，二十年里没人觉得需要换。它的每一条默认假设，都站在「一个人、一台电脑、时不时断网」这个画面上。
四个月，12 倍：一本量级账
Anthropic 把全公司的代码放在一个大仓库里，业内叫单体仓库（monorepo）。2026 年 10 月 13 日，它的工程博客公开了这个仓库这几个月的数字：
| 项目 | 数字 | 大白话 |
|---|---|---|
| 日均合并的变更 | 5 月约 2500 笔 → 9 月超 3 万笔 | 四个月约 12 倍 |
| 主分支历史 | 近 100GB | 从头到尾的全部旧账 |
| 一份工作副本（压缩后） | 超过 25GB | 干活时要拿到手的那份代码 |
| CI 每天检出次数 | 约 2500 万次 | CI 是自动构建和测试的流水线；检出就是把代码取出来 |
| 若都按 Git 方式整份拉取 | 每天超过 600PB | 1PB＝1000TB |
| 内部 Git 镜像 | 高峰期几百个 | 为分担读取压力而复制的副本服务器 |
2500 万次检出只算 CI，还没算开发环境、智能体的沙箱（隔离起来让智能体试跑代码的小环境）和研究作业。2500 万次乘以每次 25GB，约 625PB，和博客说的「超过 600PB」对得上。
拿谷歌作参照。2016 年，谷歌两位工程师在《ACM 通讯》上披露：谷歌的单体仓库约 86TB、20 亿行代码、900 万个源文件；约 2.5 万名开发者每个工作日提交约 1.6 万笔改动，自动化系统再提交约 2.4 万笔。
两边口径不完全一样——一边是日均合并，一边是工作日提交。但量级已经站到了一起：Anthropic 9 月的日均合并量，约是当年谷歌每个工作日人机合计 4 万笔的四分之三，接近谷歌当年人工提交量的两倍。
谜底：不是仓库太大，是取代码的人变了
奇怪的地方在这里。Anthropic 的全部历史近 100GB，谷歌当年是 86TB，差了近千倍。论体积，Anthropic 的仓库远没大到压垮 Git。
压垮 Git 的是「取」。Git 的逻辑是每个用户各拿一份完整副本，用户一多，就得多架镜像分流。Anthropic 高峰期维护了几百个内部 Git 镜像，可一旦仓库超出单台镜像的磁盘或内存，加机器也救不回来。合并越频繁，镜像的快照离最新的主线就越远；在只拉一部分数据的「部分克隆」（partial clone）上，查改动差异（diff）、查某行代码是谁写的（blame）也越来越难。
600PB 是什么分量？相当于每天把谷歌 2016 年披露的整个仓库搬运近 7000 遍。
问题的根子在 Git 默认的那个用户画像。Anthropic 的博客把话说得很直：Git 假设客户端离线、各持完整副本，而这里几乎所有客户端都是永远在线的智能体和自动任务，「Git 的设计在跟扩容作对」。Simon Willison 转述过一位 Scion 工程师的解释：没优先做离线支持，是因为最重的用户是 Claude，而 Claude 从不下线。
| Git 的默认假设 | Anthropic 仓库里的现实 |
|---|---|
| 用户会断网，所以每人带一份完整副本 | 用户几乎全是永远在线的智能体和自动任务 |
| 整份拉下来再干活 | 历史近 100GB、工作副本超 25GB，整份拉不动 |
| 提交、合并、查历史都在自己电脑上做 | 这些活最好放到服务器上集中做 |
| 分支随手开，各管各的 | 每一个分支都是需要全局同步的状态，本身就是扩容难题 |
| 一个人一天提交几次 | 日均超 3 万笔合并 |
集中、按需、服务端：Scion 怎么取代 Git
谷歌比 Anthropic 早撞上这堵墙。它自建的系统叫 Piper，数据分布在全球 10 个数据中心，用 Paxos 协议（一种让多台服务器对同一件事达成一致的算法）保持同步。工程师日常干活用的 CitC 则走「按需」路线：代码看上去全在，实际只有改动过的文件存在本地，平均一份工作区不到 10 个文件。
Anthropic 的 Scion 走的是同一个方向，只是更彻底。它定下六条原则：
- 客户端始终在线：不预先囤数据，要用才取。
- 客户端和服务器分工不对称：查历史、查 blame、提交、合并、变基（把一串改动挪到最新主线后面重放）都在服务器上做。
- 完整的源码控制接口：不用在本地放仓库，就能程序化地做自动二分排查（bisect，逐步对半缩小范围找出是哪次改动引入了故障）和自动回滚。
- 一切都能横向加机器：任何地方都没有完整的仓库副本，也没有 packfile（Git 把大量对象打成的压缩包）需要维护。
- 提交便宜、增量、无锁：全在服务端完成，不用 push；除了主分支和发布分支，不鼓励开分支，因为全局状态本身就是扩容难题。
- 工作副本可有可无、只取局部：检出是虚拟的，读到哪个文件才真正写到硬盘上。
拆开看，Scion 里一次改动叫 changeset（变更集），就是一本只追加、不改写的流水账里的一行，只记相对上一个版本改了哪些文件，外加指向文件内容的指针。把主分支往前挪一步，等于在谷歌云的分布式数据库 Spanner 里对一行数据做一次「比较再交换」：确认它还是刚才看到的值，才换成新值，几笔合并同时到达也不会互相覆盖。
取代码的路径分四级：机器上的命令行客户端 scn，先问同一台机器上的 scion-daemon，再问所在区域的 scion-cache，最后才问权威的 scion-server，后者从 Spanner 或云存储里读数据。
结果是每一级缓存命中率都超过 99%，基础设施的 CPU 和内存占用约为旧 Git 镜像的 1/200；CI 和研究作业取代码从几分钟降到几秒，快了两个数量级；仅 CI 一项就省出 25% 的 CPU 容量。
Simon Willison 的评价是，这是集中式版本控制的一次回归，有点像 Git 之前流行过的 Subversion。钟摆摆了二十年，摆回了起点；推它回来的，是一群从不下线的用户。
写代码已经是最便宜的一环
Scion 本身就是这套新工作方式的样品。7 个人，5 个月，造出 Scion、代码审查工具 Antique 和另外约六个相关系统（代码搜索、源码控制的权限系统等），还完成了整个仓库的迁移。大部分代码是 Claude 写的，一些优化也是它找到的，比如绕开一个缺失的索引、修正查祖先版本的算法。
早期测试里还有一幕：内部的 Claude Mythos Preview 快照在没有额外指令的情况下，重写了把 Git 历史导入 Scion 的管道，内存降到原来的 1/20，速度快了 4 倍。
代码写得这么快，卡点就挪到了下游。把一次变更从写到上线的链条摊开：
| 环节 | 为人设计的老办法 | Anthropic 现在的做法 | 卡点 |
|---|---|---|---|
| 写 | 工程师敲代码 | 大部分由 Claude 写 | 已不是瓶颈 |
| 取代码 | 每人本地一份完整副本 | 按需取文件，CI 一天检出约 2500 万次 | Git 镜像扩不动，整份拉取每天超 600PB |
| 审 | 人逐行读 | 人看意图；Antique 区分「只改注释」和「动了敏感逻辑」等审批语义；大量用 AI 做对抗式审查 | 人的注意力；对抗式审查容易短视、过度设防 |
| 合 | 合并队列加全局锁，一笔一笔排队 | 不设全局锁，冲突交给 Claude 修 | 并发冲突，但 Claude 修冲突通常比人发现冲突还快 |
| 测 | 合并前把关 | 加大合并后、部署前的自动测试 | 测试吞吐 |
| 盯运行 | 值班工程师 | Claude 当「铁杆粉丝」盯 scion-daemon、scion-cache、合并队列等组件 | — |
人在这条链上的位置变了。每一个变更请求仍有人审，但审的重点从「这一行写得对不对」变成「这次改动想干什么、该不该干」。工程师最要紧的活，是在 Claude 越界时说「不」：有个系统本该去问代码审查工具，Claude 却让它逐条扫描整本提交日志；对抗式审查过度防御，加了太多多余的校验——这些都要人拦下来。
这把钥匙只配一把锁
Anthropic 自己划了边界。Scion 不是 Git 的通用替代品，只对超大单体仓库有意义；而且 Anthropic 内部的 token 预算异常充裕，能让 Claude 这样大手大脚地写、审、修。这些工具都是定制的，不打算对外发布，只分享思路：建议 Git 托管平台增加服务端的调用接口，让 Git 已有的稀疏检出（sparse，只取部分目录）和浅克隆（shallow，只取最近的历史）能更好地搭配使用。
大多数公司离日均 3 万笔合并还很远，Git 对它们依然够用。
为人设计的那一半工具链
真正在变的，是那一半为人设计的东西。代码托管、代码审查、CI 平台，过去二十年的产品逻辑都建立在「一个工程师、一次提交、一次人工审阅」的节奏上。Anthropic 的这次改造说明，当主要用户换成智能体，这些环节的设计假设都要重新过一遍：数据是本地囤还是现取，审批是逐行看还是看意图，合并是排队还是并发。
这股流量也不只在 Anthropic 内部。Claude Code 在 2026 年 2 月的年化收入已超过 25 亿美元，过半来自企业客户；Anthropic 的托管智能体平台 10 月上线的「动态工作流」，单次最多可并行跑 1000 个智能体。外面的公司迟早也会碰到同一个问题，只是早晚和轻重不同。对关注这条产业链的人，值得盯的方向是：代码托管和 CI 平台会不会补上服务端接口、按需检出这些能力，以及谁先把「给智能体用的版本控制」做成产品。
二十年前，Git 押注每个程序员都该带着一整本账去流浪。如今在 Anthropic，翻账最勤的那位从不出门，它只需要服务器一直亮着。