10 月 13 日，Anthropic 在自己的工程博客上披露了一件事：他们内部那个集中管理多个项目的大仓库，已经从用了十几年的 Git 上搬走了，换成自研的版本控制系统 Scion。完成这件事的不是几百人的基建团队，而是 7 名工程师，5 个月。
这件事值得写，不是因为它「造了个 Git 替代品」，而是因为它把一个正在发生的转折摆到了台面上：当初按人的节奏设计的研发基础设施，已经接不住按 Agent 节奏产生的代码量了。以下内容基于 Anthropic 工程博客及智东西、IT之家等公开报道整理。
一、事件梳理：发生了什么
- Anthropic 将内部单体仓库从 Git 迁移到自研版本控制系统 Scion，同期还上线了代码审查平台 Antique、代码搜索、源代码管理权限体系，以及一套托管和落地大量已审查代码的新机制。
- 触发原因是合并量暴涨：2026 年 5 月日均约 2500 次代码变更，到 9 月超过 30000 次，四个月涨了约 12 倍。
- Scion 把提交、合并、变基、历史查询等操作放到服务端执行；客户端只负责跟踪本地修改、管理文件、维护有限缓存。
- 官方给出的效果：各层缓存命中率超过 99%、不需要长期状态；CPU 和内存占用约为原 Git 镜像体系的 1/200；CI 与研究任务的代码检出从分钟级缩到秒级，仅 CI 一项就释放了约 25% 的 CPU 容量。
- 官方特别说明：Scion 不是 Git 的通用替代品，只适用真正庞大的单体仓库，不会推出通用版本，只公开设计思路。
二、三个量级：为什么 Git 撑不住
与其讨论「Git 好不好」，不如看三个具体数字：
- 合并频率：日均 3 万次，折算下来平均约每 3 秒就合并一次。
- 检出次数：仅 CI 每天就要执行约 2500 万次代码检出，还没算开发环境、Agent 沙箱和研究任务。
- 数据体量：主分支历史接近 100 GB，压缩后的工作副本仍超过 25 GB；若每次都朴素拉取，估算每天将产生超过 600 PB 的 Git 流量。
Anthropic 也承认，浅克隆、稀疏检出、内部镜像、预制快照这些手段他们早就用上了，高峰期维护着数百个 Git 镜像。但这些只是争取时间——随着合并频率继续上涨，快照刷新、历史查询和镜像维护越来越难协调。600 PB 不是「再优化一下就过去了」的量级，而是架构层面的天花板。
三、Scion 做对了什么：把操作搬到服务端
Scion 的关键取舍只有一句话：放弃离线优先，把权威状态集中到服务端。
Git 的很多设计假设，是「开发者带着笔记本，可能断网，所以每个人要有一份完整的仓库副本」。但 Anthropic 说得很直白：他们的大部分客户端是始终在线的智能体，离线支持对它们并没有什么价值。既然不需要离线，就没有必要在每个客户端重复保存整份仓库数据——操作集中到服务端，本地存储需求和同步开销同时下降，缓存命中率高、又不需要长期状态，也就顺理成章。
这个判断对做 Agent 的团队其实是个提醒：你的工具链里，还有多少设计假设是「以人为中心、可能离线」的？
四、为什么别人抄不了
看到「7 个人 5 个月」，很容易产生「我们也来一个」的冲动。三个现实要摆在前面：
- 迁走的不是一套工具，而是一整条链路。Anthropic 自己说其他公司难以采用，是因为它需要配套定制的代码审查、代码搜索和 CI。Scion 只是那个被看见的零件。
- 只有极端负载才划算。官方给的适用条件是：要么有数万名工程师，要么有大量 Agent 在高效地写代码。普通团队搬过去，收益远不抵维护成本。
- 前置手段先要用满。浅克隆、稀疏检出、镜像、快照这些 Git 原生方案，对绝大多数仓库仍然够用。
五、影响分析
- 对重度用 Agent 写代码的团队：瓶颈的位置变了。以前卡在「模型能不能写对」，现在可能卡在「代码能不能顺畅地流转」。建议把日均合并次数、日均检出次数、仓库历史大小这三个数先量出来，再判断要不要动基建。代码质量侧的门槛也要同步补——合并越频繁，AI Agent 自动生成单元测试 和 AI Agent 输出不稳定怎么治 这类”先拦住”的机制就越重要。
- 对 Agent 工具与平台：Git 生态要学会与 Agent 共存。OpenClaw 接 GitHub 自动提 PR 那条线，在 Agent 数量上来之后会被放大成吞吐问题；这也意味着 Agent 控制平面 类工具的价值会继续上升，因为要让成千上万次自动提交可管、可查、可回滚。
- 对普通团队：短期内不用自研，但「代码流转」这一段该进可观测性了。当 Agent 开始批量操作仓库，代码库检索与索引、把 Agent 部署到服务器、成本怎么算怎么省 这几件事的优先级都会往上走。
六、三盆冷水
- 工作负载极端特殊：Anthropic 在用自家模型写软件这件事上是所有公司里最激进的，它最早撞墙不奇怪，这也是官方自己承认的前提。
- 数据均为厂商口径：1/200、25%、99% 这些数字来自 Anthropic 自己的工程文章，尚无独立复核，作为方向参考可以，作为采购依据不行。
- 长期维护成本未知：7 个人 5 个月是「建成」的成本，不是「养着」的成本。一套自研 SCM 的十年维护账，Anthropic 没有公开，也没有打算让别人抄。
七、老达点评
这件事的真实价值，不在「Git 会不会被取代」——不会，Git 在通用场景里的地位没变。它的价值在于把 Agent 规模化的副作用，从「模型层」挪到了「工程基建层」。
过去两年我们讨论 Agent，焦点一直在模型的智能、上下文、工具调用上。但当一个团队真的让 Agent 大量参与写代码，最先报警的往往不是模型，而是那些为人类协作设计了几十年的老工具。Scion 是这个现象的第一个响亮案例，但绝不会是最后一个。
给做 Agent 落地的团队三点实在建议：第一，先量三个数（日均合并、日均检出、仓库历史大小），没有数据就别谈基建改造；第二，别急着自研，先把 Git 原生的浅克隆、稀疏检出、镜像、快照用满，多数团队到不了需要自研的规模；第三，把「代码流转」这一段当成绩效指标追起来——Agent 交付速度的上限，很可能就卡在这里。
八、总结
Anthropic 用 7 个人 5 个月，把主仓库从 Git 迁到自研的 Scion，触发原因是 Agent 让日均合并量四个月涨了约 12 倍，CI 每天要跑 2500 万次检出。它给出的不是一套可以照搬的方案，而是一个清晰的信号：当 Agent 真正开始规模化干活，下一个瓶颈很可能不在模型，而在你脚下那套为人类设计的开发工具链。
