Agent 每天合入三万次代码，git 为什么撑不住了？
一、一个反常的瓶颈
一家公司里，写代码这件事突然不再慢了。
五个月前，Anthropic 平均每天合入 2500 次代码变更。到九月，这个数字是 30000 次以上。增长超过十倍，而团队没有扩编十倍。
正常的故事到这里应该讲「产能爆炸」。但真正的故事从下一步开始：代码写完了，卡住的地方变成了把代码合进去。构建、CI、版本控制——这些过去二十年为人类规模设计的工具，开始一个接一个地冒烟。
Anthropic 的工程博客在 10 月 13 日发了长文，把整个过程摊开讲了：他们花了五个月，自研了一套版本控制系统 Scion，把一个单体仓库整体从 git 迁走。原文见 Redesigning source control at Anthropic。
这不是一条「git 已死」的新闻。恰恰相反，它更像一次压力测试：当代码的主要生产者从人变成 Agent，哪些默认假设会先碎。
二、先看数字
讨论架构之前，得先感受一下这套仓库到底有多大。
主干分支的历史单独就接近 100 GB，压缩后的工作副本超过 25 GB。为了 CI，他们每天要执行大约 2500 万次代码检出——这还没算开发环境、Agent 沙箱和研究任务。如果每次检出都天真地拉完整仓库，一天的 git 流量会超过 600 PB。
他们不是没试过常规解法。浅克隆、稀疏检出、promisor 远端，全部用过。仓库镜像和对象存储里的快照种子（seeds）也上了——峰值时他们维护着几百个内部 git 镜像，靠这套东西硬扛。
镜像确实买到了时间，但代价随合入量一起涨。种子刷新之间离主干越来越远，依赖历史的操作（diff、blame）在部分克隆上越来越难保持正确。维护几个镜像不难，维护几百个是另一回事。
三、碎裂的是设计前提
Anthropic 的复盘里有一句很关键的判断：他们把 git 当集中式系统用，因为只有一份权威副本；但几乎所有客户端都是 Agent 和任务，它们天然在线。
而 git 的核心设计是去中心化：每个克隆都是一个自包含的完整仓库，离线也能算 diff、读历史、看 blame、切换任意版本。对绝大多数仓库，这是正确的设计，也是 git 成为标准的原因。
问题在于，当我们给一个单体仓库挂上几百万次在线调用时，这套优点的成本被放大了：为了「离线也能工作」，每个客户端都要付出完整仓库的代价。这也是 packfile（git 压缩对象包）成为负担的原因——包越大，协商越贵，单次响应越大，缓存越难做。
参考坐标不是没有。Google 的 Piper 和 Meta 的 Sapling 都是这个方向的前例，只是它们没有公开到这个细节程度。
四、Scion 的五条原则
他们先把假设写下来，再动代码。
客户端始终在线。服务器永远可达，客户端按需取数据，不再假设离线自足。
客户端与服务端不对称。在 git 里，每个客户端都有能力当服务器。在 Scion 里，回答文件历史与 blame、创建提交、执行合并变基，全部由服务端做；客户端只维护一个有上限的本地对象缓存，负责把文件铺到磁盘、监听文件变化。客户端算得很少，因此本地需要的数据也少得多。
查询本身要能被程序调用。过去一个 CI 任务想问「这一行最后是谁改的」，得先养一个本地仓库。Scion 把客户端用的所有查询都开成 API，于是自动 bisect、自动 revert 这类流水线才真正跑得起来。
所有组件必须水平扩展。仓库数据是分布式的，服务端也没有完整物化副本，没有 packfile，也就不需要仓库维护窗口。
提交必须便宜、增量、无锁。每次提交、变基、合并都在服务端发生，所以没有 push 这一步；但代价是这些操作必须快——创建提交和更新下游数据结构的成本，要随变更大小增长，而不是随仓库大小增长。他们还刻意不用 ref（分支、标签这类全局指针），只保留主干和发布分支，因为「所有服务器必须达成一致的全局状态」就是下一个扩展瓶颈。
五、一层层缓存，把 git 镜像换成服务
落到实现上，Scion 的基本单位叫 changeset：写进预写日志的一条记录。git 提交存的是指向 tree 的指针，changeset 存的是「相对第一个父提交变了哪些文件」，加上内容寻址、指向对象存储里压缩内容的指针。changeset 由服务端创建，立刻全局可见。
因为只记录变化，changeset 自己答不出 blame 和历史问题。答案靠派生数据：文件 blame 结构、路径历史、提交图的跳表。每类派生数据按递归定义——某个 changeset 上的取值由它各父提交上的取值算出。好处有三条：加新索引很容易；可以选即时算还是延后算；客户端看不到内部结构，结构可以随便改。后来他们按需加了副本检测索引、路径搜索索引，客户端一行没动。
分层也很直白：
- 节点上的守护进程scion-daemon，为整台机器缓存对象，起点是周期性刷新的快照；
- 区域内的scion-cache，直接从内存里按客户端要的磁盘格式流式发送对象，不做差量压缩；
- 权威的scion-server，按需读 Spanner 或对象存储。
三层的 RPC 完全一致，客户端不需要知道缓存的拓扑。但分层被强制隔离——区域缓存挂了不能把上游拖下水。
结果是一串很干净的数字：每层缓存命中率 99% 以上；整套 Scion 的 CPU 和内存占用，是原来 git 镜像基础设施的 200 倍之小；CI 和研究任务检出代码快了两个数量级（秒级，而非分钟级）；光是 CI 就省下 25% 的 CPU 容量。
顺带一提，Scion 的取数协商和 git 的 fetch 完全不同：它不告诉服务器「我有什么」，而是直接基于 tree 和 blob 递归地要「我要什么」。每个请求针对的都是永不变更的对象，所以任何一层缓存都能答，结构上就是传统的多级缓存；也因为没有几 GB 的 packfile 响应，过程天然可续传。
六、七个人，五个月，和一句「不行」
这套系统——Scion、代码评审工具 Antique，外加半打相关系统，以及完整的仓库迁移——由一个七人小组完成，耗时五个月，期间每天合入的代码量还涨了十倍。
Claude 在里面扮演了很重的角色。有一个例子特别能说明问题：他们早先手写了一个 git 到 Scion 的摄取管道原型，自己觉得还行。拿到 Claude Mythos Preview 的内部快照后，他们让模型重写一遍——没有任何额外说明，新版内存占用少 20 倍、速度快 4 倍，同时保持了所有关于摄取顺序和数据结构的隐式约束。
但文章里更值得抄的一段，是工程师角色的变化。所有参与这套系统的工程师都承认，Claude 写代码比他们强。他们提供的是另一类东西：对系统之间高层组件的理解，以及设计层面的取舍。原话说，很多时候工程师的作用是对 Claude 说「不行」。
举的例子很具体。迁移期间，有多个系统试图用「线性读取提交日志」来查一个变更何时合入主干，而不是去问评审工具——这是一种为了满足某个本就不该存在的模式而违反核心约束的做法。另一个方向是过度防御：有一次对抗式评审过于不信任另一个内部服务，Claude 于是加了一堆多余的校验和复杂度。工程师仍然评审每一个变更申请，但看的是意图，而不是逐行读代码。
运维上也有一点新东西：他们给每个组件建了一个 Slack 频道，让 Claude 盯着单个组件的健康度，叫「superfans」。有 scion-daemon superfan、scion-cache superfan、Antique 合并队列 superfan。这些 Agent 能读到遥测和日志，去找那些传统告警看不见的细微异常。
七、争议也一样真实
Hacker News 上这条讨论有 750 多条评论（讨论帖），反对意见相当集中。
第一条是本地提交的自由。git 甚至更激进的 jj 的整个论点，是你能在本地堆出一串小提交，随便重排、合并、丢弃，最后再决定推什么。Scion 把提交、变基、合并全放到服务端，这部分空间就没有了。
第二条是对「没人看代码」的警觉。文章里的说法是团队评审每个变更的意图而非逐行，也承认 CI 会放行并发变更导致的冲突，靠 Claude 事后修。有评论直接问：这是不是意味着生产环境上线的是没有人工逐行审过的代码。
第三条是那个 600 PB 的数字本身。有评论质疑：真的每天有这么多代码需要改吗？另一条高赞回复则换个角度——如果模型真这么好用，那把 prompt 当源码提交、把生成的代码当成昂贵的构建产物放进仓库，是不是更合理的工作流。
Anthropic 自己也划了边界：Scion 不适合替代通用场景下的 git，这套思路只在「数万工程师或大群 Agent 疯狂写代码」的超大单体仓库里成立。他们甚至说，把它做成给所有人用的公共产品很难，所以更实际的做法是公开思路，让 git 生态自己吸收其中可用的部分——比如服务端不必照着客户端的样子做，git 平台可以提供更完整的服务端 RPC。
八、留给工程实践的三条
- 瓶颈会转移，而且往往转移到你最信任的那一层。这次是版本控制。下次可能是构建缓存、制品仓库、测试调度——判断标准很简单：这个工具的设计假设里，有没有「客户端是人、带宽稀缺、离线可用」这类前提。
- 镜像和缓存不是架构，是止疼药。从几十个镜像涨到几百个的时候，问题已经不是运维熟练度，而是数据模型选错了。Scion 最狠的一步是取消了「完整副本」这个概念本身。
- Agent 时代的工程能力，前半段是提出好问题，后半段是说「不行」。生成代码已经便宜到不再是约束，值钱的是系统边界、数据模型和「这个防御不该加」的判断。
原文：https://www.anthropic.com/engineering/redesigning-source-control
参考：Sapling、git 部分克隆文档、HN 讨论
