瓶颈搬了家，才动基建
机器量上来后，交付瓶颈从编码移到版本管理、构建与 CI。先量它有没有搬，再决定动不动这层。
写代码的环节被 agent 压短之后，最先显形的往往是那些按人类节奏设计的工程基建：版本管理、构建、CI。Anthropic 把它们重做了一遍——从 git 迁到自研的 Scion，五个月完成迁移。动因不是 git 不好，是它的设计假设和现在的负载对不上了。
读完你能回答：
- 凭什么判断瓶颈已经从编码搬到了基建？
- git 的哪些假设在 agent 规模下反过来成了负担？
- 哪些做法可以先回移到现有工具，哪些不值得照搬？
编码不再是瓶颈，基建才是
Anthropic 给出的一组自报数据：2026 年 5 月，每天约 2500 次代码合并；到 9 月，每天超过 3 万次。主分支历史接近 100GB，压缩后的工作副本也超过 25GB；仅 CI 每天就要检出 2500 万次——不做任何优化，就是每天 600PB 的传输量。为顶住负载，他们一度同时运行几百个内部 git 镜像 anthropic-source-control。
这些数字说的是同一件事：当编码从慢环节变成快环节，压力不会消失，只会移到下一段。测试选择服务先被压垮（见 让验证速度追上生成速度），接着是版本管理本身。Anthropic 的结论是，瓶颈是「所有为人类规模设计的开发基建」，而不只是某一个工具。
口径要先说清：这是 Anthropic 自己的内部负载，也是孤例规模。一般团队短期内遇不到这个量级——这一点后面单独讲。
旧基建的假设反过来成了负担
Git 是去中心化设计：每个克隆都是一份完整、自包含的仓库，离线也能算 diff、读历史、查 blame、检出任意版本。对绝大多数仓库，这是对的，也是它成为标准的原因。但 Anthropic 发现自己其实是把 git 当中心化系统用——权威副本只有一份，而几乎所有客户端都是按定义始终在线的 agent 和 CI 任务。于是 git 最优秀的那些性质开始反过来拖后腿：
- 「客户端离线、需要完整副本」：客户端始终在线，本可以按需取用，不必每处都存一整份。
- 「每个客户端都能当服务器」（客户端-服务端对称）：真正需要回答历史、blame、合并、rebase 的是服务端，客户端没必要具备同等能力。
- 「本地提交、再 push 分享」：大量 agent 持续产出时，共享的 refs 与 packfile 维护成了全局协调点，成本随仓库大小增长，而不是随改动大小增长。
判断的形状很朴素：当一条假设已经和实际用法相反，继续在它上面打补丁，补丁的续命时间会越来越短。这正是 个体提效不等于组织提效 里说的「瓶颈换了位置」——只不过这次换到的不是某个团队，而是版本管理这一层。
反过来设计：始终在线、稀疏检出、提交便宜
Scion 是照着「客户端始终在线」这个前提重新设计的，几条原则互相咬合：
- 客户端-服务端不对称。 服务端回答历史与 blame、创建提交、执行合并与 rebase；客户端只保留一个有界的本地对象缓存、把工作副本铺到磁盘、监听文件变化。它自己算得很少，换来的是本地要存的数据少得多。
- 一切都要能水平扩展。 仓库数据是分布的，任何地方都没有一份完全物化的副本，服务端也没有；没有 packfile，于是没有仓库维护。缓存分三层——节点上的 daemon、区域的 cache、权威 server——每层命中率都在 99% 以上，且不依赖长生命周期状态。
- 提交要便宜、增量、无锁。 单位是一个「changeset」，本质是预写日志里的一条记录：它只存相对第一父的改变文件，加上内容寻址的指针，所以创建提交的开销随改动大小增长，而不是随仓库大小。
- 工作副本可选，且天生稀疏。 CI 要一个 diff 和它的 merge base，直接问服务端即可，不必检出；真的要落盘时，只取它实际读到的那部分。
对大多数团队，这些原则不必照抄，但有一条可以直接借：服务端不必和客户端同构。一个 git server 完全可以提供更全的服务端查询、把协商改成按对象进行、让 sparse 与 shallow 更好地组合。这些是可以只做加法、不动整体模型的改进。
代价与边界：先量再动
Anthropic 自己划了边界：Scion 不是通用 git 替代品。它只在「超大单体仓库 + 大量 agent 持续产出」时成立；迁过去意味着整条开发生命周期都要换（评审、搜索、CI），而他们这些内部组件高度定制、外部难以采用。加上自认的 token 预算远超一般公司，这套做法的可复制性有限。任何「某家重做了一层」的案例，都要放回它成立的条件里读。
所以真正的动作不是「照着重建」，而是先量：
- 端到端交付时间卡在哪一段？ 如果等待集中在评审、联调，重建版本管理不会让交付更快；只有当版本管理本身成为明确限制，重建这一层才有充分理由。
- 这部分能只做加法吗？ 先上服务端查询、稀疏与虚拟化检出、按需拉取，够用就别推倒重来。
- 改完之后，谁来证明它做对了？完成标准要能被核对，而不是「迁移完成了」这句话。
组织面也跟着变。Anthropic 的工程师说，agent 写代码已经比他们更好，但他们仍提供系统级取舍的判断——很多时候工作是说「不」，阻止 agent 为了满足某个模式去破坏核心约束。评审也从「读每一行」转向「看这次改动的意图」。他们还承认，agent 规模下「合并队列加全局仓库锁」这套惯例已经不好复现，于是把重心转向合并后与部署前的自动化测试。
基建值不值得动，不取决于它旧不旧，取决于瓶颈是不是真的搬到了这里、以及改动能不能被核对。先把这两点量清楚，再决定动不动这层。