Git 撑不住 AI 智能体了：Anthropic 用 7 人 5 个月自研 Scion 替代，基础设施缩小 200 倍

2026 年 10 月，Anthropic 发布了一份工程复盘，揭开了 AI 时代最被低估的一个瓶颈：当 Claude 让代码产出不再稀缺时，Git 成了新的天花板。 他们的应对是——7 人团队用 5 个月自研了一套全新的版本控制系统 Scion，彻底替换 Git。结果是基础设施缩小 200 倍、代码检出提速 100 倍、CI 节省 25% CPU。

一、Git 到底哪里撑不住了？看数字

Anthropic 的困境可以用一组数据说清楚：

一句话：代码合并量 5 个月翻了 10 倍，Git 的所有工具都用尽了。

Anthropic 其实早就把 Git 能用的招全用了——浅克隆、稀疏检出、promisor remotes、内部镜像、blob storage 里的仓库快照。但合并率一飙升，这些补丁全部失效：快照在刷新间隔里越来越落后于 main 的最新提交，依赖历史的操作（diff、blame）在部分克隆上的维护成本越来越高。

而真正点破问题的一句话是：

“我们把 Git 当作只有一个权威副本的集中式系统用，但客户端几乎全是智能体和在线作业。Git 为分布式、离线工作设计的特性，恰恰在主动破坏我们随仓库增长而扩展的能力。”

换句话说——Git 是为人设计的，不是为 AI 智能体设计的。

二、Scion 的六个设计原则，每条都在反 Git

Scion 不是 Git 的改良，是从根上重新设计。六个原则，条条针对 Git 的软肋：

mindmap
  root((Scion 六大设计原则))
    客户端始终在线
      不做完整副本
      按需取数
    客户端-服务器不对称
      服务器算 blame/合并
      客户端只做缓存+布局
    源码控制即服务
      所有查询走 API
      作业无需本地仓库
    水平可扩展
      任何地方无完整副本
      无需 packfile 维护
    提交廉价无锁
      服务器端创建
      成本随变更大小而非仓库大小
    工作副本可选
      默认稀疏
      大量写入可纯 API 完成

核心数据结构的变化最能说明思路的转变：

Git 的 commit 存的是"指向 tree 的指针"；Scion 的 changeset 存的是"相对父提交变化的文件列表" + 内容寻址指针。

这个差异带来一个关键好处：提交在服务器端创建，即刻全局可用。没有 packfile 要接收、没有锁要协调、没有 ref 要移动。移动 ref 是 Spanner 单行上的 compare-and-swap，和创建 changeset 分开发生。

三、性能数据：为什么这套架构能快 100 倍

Scion 的扩展架构是一套分层缓存拓扑：

flowchart TD
    Client["🖥️ scn client<br/>客户端"] -->|"socket"| Daemon["🔧 scion-daemon<br/>节点级对象缓存"]
    Daemon -->|"RPC"| Cache["📦 scion-cache<br/>区域级树/blob 缓存"]
    Cache -->|"RPC"| Server["🏛️ scion-server<br/>权威服务器（Spanner/云存储）"]

    style Client fill:#f38ba8,color:#1e1e2e,stroke:none
    style Daemon fill:#f9e2af,color:#1e1e2e,stroke:none
    style Cache fill:#89b4fa,color:#1e1e2e,stroke:none
    style Server fill:#a6e3a1,color:#1e1e2e,stroke:none

三层对同一个 RPC 协议响应完全相同的接口，客户端无需知道缓存拓扑。数据全部内容寻址、一旦存储永不改变，任何服务器都能缓存而无需互相确认。

实测数据非常硬：

最精妙的设计是协商协议：Scion 不告诉服务器"我已有啥"，而是只基于客户端想要的 trees/blobs 递归请求。没有单个数 GB 的 packfile 响应，每个请求针对永不改变的特定对象，任何缓存都能应答——既高效又可恢复。

四、7 人、5 个月：Claude 是怎么参与"造自己的工具"的

这件事最耐人寻味的地方，是造这套系统的人，正在用它自己放大的需求来倒逼自己。

• 团队规模：7 人
• 迁移时间：5 个月
• 同期还构建了：代码评审工具 Antique、代码搜索、源码控制 IAM、六个相关系统

而 Claude 在这过程中的作用，用两个具体案例最有说服力：

1. 摄取管道重写：团队手写的 Git→Scion 摄取管道原型，交给 Claude Mythos Preview 重写（无进一步指令），产出了内存消耗降低 20 倍、速度提升 4 倍的版本，还保留了所有隐式不变量。

2. 算法优化：Claude 发现了一个祖先查询的算法优化（此前团队错过了一个索引），Anthropic 的评价是——“这本来需要专家几天甚至几周的分析和调优，然后它第二天又做了一遍。”

更关键的是工程师角色的变化，这句话值得每个开发者记住：

“所有工程师都认为 Claude 在写代码上比他们更强。工程师的新价值变成了：理解高层系统间组件关系、做设计级权衡、以及告诉 Claude「不」。”

评审方式也变了：工程师仍然评审每个变更，但检查的是变更的「意图」，而不是逐行读代码。

五、但 Scion 不开源，为什么？

这是很多人的第一反应——这么牛的东西，开源吧？Anthropic 明确说不，理由也很实在：

1. 高度定制化：它和 Git 差异巨大，公司需要迁移开发生命周期的每一部分，还需要配套的代码评审、代码搜索、CI，公开版很难对其他组织有用。
2. 适用场景极窄：只对"数万名工程师或成群智能体大量写代码"的巨型 monorepo 有意义。

但他们选择分享思路，并给出了三条给 Git 生态的具体建议：

• Git 服务器不必与 Git 客户端工作方式相同，新颖的服务器架构能提供显著的扩展改进；
• Git 平台可以提供类似 Scion 的服务端 RPC，甚至可能在各 forge 之间标准化；
• 协商协议不必保持现状，Git 的稀疏和浅层特性可以组合得更好。

Anthropic 还主动表示希望与 GitHub、GitLab 和 OSS 社区合作。

六、这件事对普通开发者的意义

别急着"我也要自研版本控制系统"。Anthropic 自己都说了，Scion 的适用场景非常窄。但对普通开发者，这件事有三点真正的启发：

1. 工具链正在成为 AI 时代的新瓶颈。 过去瓶颈是"写代码的人不够"，现在是"代码产出太快，基础设施跟不上了"。谁先解决"智能体规模下的开发基础设施"，谁就拿到了下一阶段的先手。

2. "为谁设计"决定了工具的上限。 Git 为"离线、分布式、人类协作"设计，这些假设在智能体时代全部失效。重新审视你的工具链里有哪些"为旧假设设计"的部分，可能就是你的机会。

3. 工程师的护城河在转移。 从"写代码"转向"理解系统关系、做设计权衡、说「不」"。Anthropic 工程师的这句自述，比任何职业焦虑文章都更接近真相。

Anthropic 还预判了一件事，值得记住：这类问题将在未来 6-12 个月变得更加普遍。 也就是说，你所在的公司，可能很快也会撞上"Git 撑不住 AI 智能体"这堵墙。