Anthropic用Scion换掉Git了？每天3万次合并，对普通团队意味着什么

Anthropic是不是把Git扔掉了？对内，是的。Anthropic在2026-10-13的工程博客里写：他们自研了版本控制系统Scion，用五个月把主monorepo从Git迁完；日合并量从2026年5月约2500次涨到9月超过3万次。对还在用GitHub、GitLab的团队来说，更该看清第二句：官方自己写「Scion绝不是适合一般用途的Git替代品」，也没有公开发布计划。

这篇只回答三件事：他们为什么被Git卡住、Scion改了什么假设、普通团队现在能抄哪几招。

先分清：已公布 vs 容易被标题带偏

说法	状态	依据
Anthropic主monorepo已迁到Scion	已公布	公司工程博客
日合并约2500→3万+（5月到9月）	公司自述	同文
7人团队五个月建成Scion与评审面Antique等	公司自述	同文
相对原Git镜像，CPU/内存约降200倍；CI检出从分钟级到秒级	公司自述，未独立复现	同文
「Git要死了」「大家快迁Scion」	演绎	官方明确反对把Scion当通用替代
开源或对外售卖Scion	未宣布	博客称难以提供对他人有用的公开发布形态

他们为什么被Git卡住

量级很直观：仅主分支历史接近100GB，压缩工作副本超过25GB；每天仅CI约2500万次检出。他们一度运维数百个内部Git镜像，再用对象存储种子缓解，但合并越快，种子离main越远，diff/blame也越难在部分克隆上做稳。

更关键的一句：他们其实在把Git当中心化系统用——权威副本一份，客户端几乎全是始终在线的Agent和CI。Git为「离线完整副本」设计的那套，反而成了负担。

Scion改了哪些假设

维度	Git常见假设	Scion做法（按博客）
客户端	可离线、自带完整能力	默认在线，按需向服务器取
提交	本地commit再push	commit/rebase/merge在服务端完成
数据单位	commit指向完整tree	changeset只记相对第一父提交的变更文件
检出	常需较大工作副本	稀疏/虚拟检出；很多查询纯API、可不落盘
扩展	镜像、浅克隆等补丁	水平扩展缓存层；无packfile式整库维护

权限可细到目录级；评审面叫Antique。这些都绑在内部工具链上，不是换个客户端命令就能搬。

普通团队：能学什么，别学什么

值得学。Agent写代码变多后，瓶颈会移到检出、CI、合并队列——先量自己的日合并、CI排队、克隆耗时。博客建议把经验回馈Git生态（更强服务端RPC、协商协议），而不是立刻自研VCS。工程师价值变成「定约束、说不、审意图」，这和日常用Claude Code、Cursor、Codex的方向一致。

别跟风。不到「巨型monorepo + 海量Agent/CI」量级，自研VCS通常得不偿失。继续用现有托管，看代码托管和AI编程与建站；选型对照Claude Code和Codex怎么选、AI编程入门。

基建负责人可先做的五步

1. 统计近30天：日均merge、CI job数、平均clone/fetch耗时、缓存命中率。
2. 把只要diff/blame/ancestry的任务从全量检出改为API或浅克隆。
3. 合并队列若被Agent打爆，评估更多post-merge检测，而不是一味加全局锁。
4. 敏感目录：真的要拆仓，还是目录级ACL就够。
5. 向GitHub/GitLab确认服务端RPC路线图。

常见问题

能不能下载Scion？

目前不能。官方称难以做成对广泛组织真正有用的公开发布形态。

是不是说明GitHub没用了？

不是。博客结尾明确要与GitHub、GitLab和开源社区合作。

Antique是什么？

Anthropic同期做的代码评审界面，和Scion配套，不是单独开源产品。

小团队日合并几十次也要换吗？

按官方口径不必。先把CI缓存、浅克隆和评审规则做好更划算。

迁移五个月里，他们还顺手做了什么

博客写得很满：同一时期不只搬仓库，还上线了代码评审面Antique、代码搜索、更细的源码IAM，以及「大批已审代码如何落地」的新办法。对读者的启示是——瓶颈一旦从「写代码」转到「合代码」，单换版本控制命令不够，评审与权限模型会一起被掀开。

他们也承认：Claude写代码的能力既制造了合并洪峰，也加速了Scion本身的建设。例如早期手写的git→Scion摄入管道，在内部Mythos预览模型重写后，自称内存降到约1/20、速度约4倍，还保住了排序与结构不变量。这是内部轶事，拿来理解「Agent时代基建怎么迭代」可以，拿来当你司选型标杆则过满。

和Google Piper、Meta Sapling的关系

文中明确参考了大型monorepo前辈，尤其提到Sapling服务端Mononoke与Bonsai一类思路。Scion并不是「第一个不用Git的公司」，而是「在Agent日合并三万次」这个新压力点上，把「客户端永远在线」写成了第一性原理。普通团队更常见的路径仍是：把Git用好（浅克隆、稀疏检出、更好的缓存），同时把Agent的提交粒度与评审策略收紧。

站长视角：和51发现导航读者的关系

来本站的人未必要自研VCS，但很多人正在给团队选Claude Code、Cursor工作流。可以多问一句：你们CI是否已经因为Agent提交变慢？如果还没有，优先看测试分流与缓存；如果已经有，再去读Anthropic这篇，把「服务端查询代替全量检出」列进技术债清单。

合并队列在Agent时代为什么难照搬

博客提出一个尖锐问题：当测试还在跑时，可能已有成百上千变更合入，传统「全局锁住合并队列」难以复制。他们更多转向合并后与部署前的自动化验证，并接受并发冲突由Claude快速修复。这对企业的启发不是「取消CI」，而是「CI门禁的形状要随提交速率重画」——例如缩小必测集、扩大异步测、强化回滚。

来源与核查日期

• Anthropic Engineering：Redesigning source control at Anthropic（2026-10-13，10-15更新）

核查日期：2026-10-18（新加坡时间）。合并量、资源占用等为Anthropic自述。