AI 写代码后，Git 不够用了？Anthropic 把答案藏在 3 万次合并里

2026 年 5 月，Anthropic 的单体仓库每天大约合并 2,500 个代码变更。到 9 月，这个数超过了 30,000。

数字涨了十二倍，最先扛不住的不是模型，也不是工程师的键盘，是 Git 周围那圈默认存在的基础设施，包括克隆、检出、历史查询、合并队列，还有 CI 里一堆以为自己只是在「拉个代码」的作业。

Anthropic 给出的动作很猛，五个月，七人团队，自建 Scion，把主单体仓库从 Git 迁过去，同时补齐评审、搜索、权限和落地系统。新闻标题很容易写成「Anthropic 放弃 Git」。但官方文章其实把边界讲得很清楚，Scion 不是给一般团队准备的 Git 替代品。

真正值得拿回来用的，是另一个问题，当编码智能体开始稳定地给你的仓库加速时，哪些工作流应该先从「每个任务各带一份仓库」改成「向一个源代码服务提问」？

按 Anthropic 官方公布的 2,500 次与 30,401 次数据重绘；并非小岛AI独立实测。

不是 Git 突然不行了，是工作负载换人了

先把一个常见误会放下。Git 的离线、完整副本和分布式协作，对绝大多数团队仍然很合适。笔记本断网了还能看历史、切分支、做 diff，这些不是过时能力。

Anthropic 卡住，是因为它的客户端已经不太像「一个开发者的一台电脑」。官方披露，主分支历史接近 100 GB，压缩后的工作副本超过 25 GB；只算 CI，每天就有大约 2,500 万次检出。若每次都按完整仓库的思路取数据，日流量会超过 600 PB。

很多团队暂时不会遇到这个量级。但把一个编码智能体接进 CI 以后，变化路径是相似的。以前只有人会在本地拉仓库、查 blame、跑测试。现在 PR 检查、修复任务、评审机器人、临时沙箱和研究作业都想要一份代码，还都希望马上得到答案。

一开始，大家会先加浅克隆、稀疏检出、镜像和快照。这些办法本身没问题。Anthropic 也都用过，高峰期还维护过数百个内部 Git 镜像。可合并速度继续上涨时，快照会越来越落后，镜像越来越难养，依赖历史的 diff 和 blame 在局部副本上也更容易变成麻烦。

所以，判断要不要动基础设施，别从「我们每天写了多少行代码」开始。更实用的三个信号是，CI 的时间主要花在检出还是执行；有多少任务只是为了问 merge base、diff 或 blame 却不得不拉仓库；当镜像或缓存慢半拍时，队列会不会一起堵住。

如果答案里已经有两个「会」，问题通常不在模型写得够不够快，而在源代码访问方式还停在人类规模。

还有一个容易被忽略的差别。代码行数变多，不一定马上带来基础设施危机；会把系统拖住的，是同一份状态被多少个并发执行者反复复制、重新计算和争抢。一个 Agent 修一个小 Bug，可能只改十行，但它也会开沙箱、读依赖、跑测试、请求差异、等待评审。把这条链路乘上几十个并发任务，最贵的往往不是那十行代码，而是每个任务都从头准备环境。

这也是为什么要把观测点放在作业链路上，而不是只盯着每日提交数。看一看流水线里从开始到真正执行测试前花了多久；再看命中缓存的任务和冷启动任务差了多少；也看失败重试会不会把同一份仓库拉取放大成一轮流量尖峰。前两个数字不健康，继续加 Agent 通常只会让排队更热闹。

Scion 改的不是命令，而是默认前提

Anthropic 的第一处改动很朴素，把绝大多数客户端默认成在线的智能体或作业。

Git 默认每个客户端都能成为一个完整仓库。Scion 则让服务端处理历史、blame、commit、merge 和 rebase，客户端只保留有界的对象缓存、工作副本和文件监听。客户端不再先问「我能否把整个仓库带走」，而是只取现在需要的树和文件对象。

这不是把 Git 命令换个皮肤。它把源代码管理从一个本地文件分发问题，变成了一个可查询、可缓存、可横向扩展的服务。

Scion 的内部数据模型也服务于这件事。它的基本单元不是一份完整快照，而是记录相对父提交变化文件的 changeset。历史、路径和 blame 这类读操作所需的索引，被当作可以按需或提前计算的派生数据。客户端看不见这些内部实现，服务端就能在不改变客户端行为的前提下继续换索引、加缓存、补优化。

这层分离很值得记住。很多自建研发平台会把「命令行能做什么」和「平台能回答什么」绑在一起。结果是每加一个自动化任务，就多一份脆弱的本地环境假设。更稳的方向是把真正需要的能力提炼出来，包括给定两个提交后返回差异，给定一行代码后返回可审计的来源，给定变更后返回能否进入下一阶段的证据。具体底层仍可继续使用 Git。

按 Anthropic 官方架构重绘。关键不是照搬组件名称，而是把检出拆成可缓存、可隔离的层。

这里有四个对普通团队也有用的判断。

第一，**历史和元数据要能直接问服务端。**一个作业只需要知道某行是谁改的、两个提交的共同祖先在哪里，没必要为了问这句话先准备几十 GB 工作副本。你未必需要造 Scion，但可以检查 Git 托管平台、内部索引或 API 是否已覆盖这些高频查询。

第二，**检出应该按需，而不是按习惯。**稀疏检出、部分克隆和构建缓存常常已经在团队里，只是没有被当成 Agent 的默认路径。对只跑一个目录测试的任务，让它先拉全仓库，和每次打开网页都把整站下载到本地差不多。

第三，**缓存更适合围绕不可变对象建。**Scion 的树和 blob 一旦写入就不再改变，缓存不需要反复协调。这种思路也适用于构建产物、依赖和测试输入。真正容易把缓存拖垮的，往往不是容量，而是大家都在猜同一个可变状态有没有更新。

第四，**别把全局锁当作唯一秩序。**当成百上千个变更在测试尚未结束时继续进入系统，传统合并队列很难靠一个总闸门维持吞吐。Anthropic 转而增加合并后与部署前自动化验证，接受并发冲突存在，再把发现和修复速度拉高。

这一步很容易被误读成「把代码交给 Agent 随便合」。并不是。官方仍强调每个变更请求都有人审，只是人更关注意图、系统影响和不该被破坏的约束，而不是试图靠逐行阅读吞掉所有模型生成的实现细节。

安全边界也跟着前移。Scion 支持仓库级和目录级权限，Antique 的审批规则能区分注释修改与敏感逻辑修改。对人类为主的仓库，这听起来像熟悉的权限管理。可一旦自动化任务能批量修改文件，目录边界、审批语义和可回滚证据就不再是治理附属品，它们决定了你能把执行权交到哪里。

Anthropic 还给每个组件配了持续看遥测和日志的内部 Agent。它们不是替代传统告警，而是专门捕捉「指标还没越线，但形状开始不对」的异常。这里也不必照搬工具。对普通团队，先确保每个自动化任务都有任务 ID、输入提交、权限范围、执行日志、产物和回滚点，已经比给一个大而全的 Agent 管理员权限有用得多。

速度上来以后，评审要换一层看

Anthropic 有个细节很有意思。官方说，团队让早期内部模型重写 Git 到 Scion 的导入管线，结果内存消耗降到原来的二十分之一，速度提高四倍，还保住了原有的顺序与数据结构约束。

这类结果很诱人，但它也把评审的难题照得更亮。模型很会把局部程序写快，却不天然知道哪条约束属于系统底线。官方文章里举了两个典型偏航，有系统用线性扫描提交历史来查变更何时进入主分支；也有评审过度防御某个内部服务，让模型加了太多验证和复杂度。

这不是「模型不可靠」这么简单。它提醒我们，智能体越能完成局部任务，团队越要把不可破坏的规则显式化。

对正在接入编码智能体的团队，我更愿意把评审拆成两张单子。

• 变更意图单，它要解决什么问题，允许动哪些目录和接口，哪几条业务或安全规则绝不能被碰。
• 交付证据单，跑了哪些测试，性能和成本与基线相比怎样，失败时会如何降级，是否留下可追溯的提交、日志和回滚点。

前一张单子帮人和模型对齐边界，后一张单子避免「看起来跑通了」提前变成「可以合并」。这两张单子不需要等到 3 万次合并才补。代码量小的时候补上，成本反而低得多。

按 Anthropic 官方性能图中的三项加速倍数重绘。其内部基础设施、算力与工作负载高度特殊，不能直接换算为一般团队收益。

不要迁出 Git，先做一次四格体检

Anthropic 自己说得很诚实，Scion 依赖专门的评审、搜索和 CI，内部算力预算也不是一般公司会接受的水平。直接模仿迁移，十有八九会把一个扩展问题换成一个平台重写项目。

但它给了一个很实用的体检框架。下次你要给 CI 或 Agent 增加并发时，可以先把这四格填出来。

1. 检出，一次任务到底读了多少代码，又下载了多少不相关内容。
2. 查询，diff、blame、merge base 这些信息，哪些必须靠本地完整仓库才能拿到。
3. 状态，哪些全局分支、队列或锁，正迫使本来独立的任务互相等待。
4. 证据，一个变更合入前后，谁审了意图，什么测试和遥测能证明它没有把系统推过边界。

前两格决定吞吐，后两格决定你敢不敢把吞吐真的打开。很多团队只盯着「Agent 一次能改多少文件」，其实更早出现的瓶颈，往往藏在检出和验收这两个看上去很传统的角落。

这份体检做完，动作顺序也会清楚很多。检出慢，就先做路径收窄和缓存命中率，不要急着重写版本控制。元数据查询慢，就先给常用的 diff、历史和归因补服务接口。合并争抢严重，就把验证拆成合并前、合并后和部署前，再为失败设计明确的停留点。只有当这些轻量动作都被系统规模压穿，才值得讨论更大的迁移。

还有一条反过来的经验，不要因为 Agent 很快就缩减验证。Anthropic 自己的做法恰好相反，除了人审，还建设了对复杂基础设施交互的封闭仿真、模糊测试和限流。模型把产码速度推高后，测试与观测不是跟着变少，而是要跟上新的并发密度。少了它们，所谓吞吐只是把故障更快地送到主分支。

也别把所有指标都压成一个「成功率」。对这类链路，更有判断力的是分层看，包括检出是否成功、测试是否通过、合并后是否出现回归、部署前的约束有没有被触发。四层指标能帮你分清问题是数据没拿到、代码没跑过、并发带来了交互错误，还是权限与发布门槛没有设好。把这些失败归因记下来，下一次 Agent 接入新任务时，才不必从头猜。

Anthropic 预计，类似压力会在未来 6 到 12 个月更常见。这个判断未必适用于每个仓库，但我认同它指向的一件事，当代码生产变得便宜，管理代码状态、验证代码后果和限制代码权限，会变成更贵的部分。

Git 不需要马上退场。只是别等到 CI 队列像早高峰一样站满以后，才发现我们给 Agent 装了发动机，却还让它们共用一条单车道。

你们团队现在最慢的环节，是生成代码、检出代码，还是证明代码真的能合？

原始技术材料见 Anthropic《Redesigning source control at Anthropic》。文中所有性能数字与架构图均来自该公开文章，未做独立复现。