> 本文搬运自外网，原文链接见文末
四个月翻了十二倍，单体仓库是怎么被撑爆的
前阵子我们在 Lovable 的复盘里聊过一个切身体会：当程序员开始带着一群 AI Agent 写代码，一个人的周均 PR 产出从 20 个飙到 150 个，最先卡脖子的环节就从写代码变成了做 Code Review。那如果把这种编程方式放大到一整个前沿 AI 实验室，让成百上千名工程师和全天候运转的自主 Agent 循环同时往一个单体仓库里推代码，接下来被撑爆的会是什么？Anthropic 刚刚交出了一份让人意想不到的答案：最先撑不住的，是统治了软件行业二十年的版本控制底座 Git。
今年 10 月中旬，Anthropic 工程团队公开了一份内部基础设施复盘，披露了他们在过去大半年里经历的一场极限自救。故事的起因是内部代码产出的指数级暴涨。随着 Claude 模型迭代，以及 Claude Code 在内部研发、自动化实验和性能优化循环里的全面铺开，Anthropic 单体仓库在 2026 年 5 月的日均代码合入量大约是 2,500 次；到了 9 月，这个数字直接冲破了每天 30,000 次。短短四个月时间，代码合入吞吐量翻了 12 倍，相当于一天 24 小时里平均每 2.8 秒就有一次变更合入主干。
更要命的压力来自读取端。经过长期的高频提交，Anthropic 单体仓库的主干历史体积已经逼近 100 GB，就算把工作区代码压缩打包，单份体积也超过了 25 GB。与此同时，每天泡在仓库上的消费者早就换了主力：除了人类工程师的开发机，还有成千上万个短暂存活的 Agent 沙箱、自动化研究任务，以及规模庞大的持续集成流水线。
单算 CI 环境这一项，每天就要执行大约 2,500 万次代码签出。我们可以算一笔简单的乘法账：如果这 2,500 万次签出每次都老老实实走标准 Git 流程，把超过 25 GB 的工作区拉取下来，每天产生的网络传输流量就会超过 600 PB。为了不让主库当场瘫痪，基础设施团队不得不维护几百台内部 Git 镜像服务器来分摊流量，但克隆变慢、同步延迟和算力空转已经到了修修补补救不回来的地步。
统治软件业二十年的 Git，错在了哪条假设上
为什么全世界开发者用了二十年都觉得稳如泰山的 Git，会在这种规模下突然崩盘？要回答这个问题，得先回头看一眼 Git 在 2005 年诞生时的底层设计假设。
当年 Linus Torvalds 设计 Git，脑子里装的是人类开源社区的协作场景。在这个场景里，核心前提有三个：
参与者是人类，每天产生的提交次数有限，围绕人类的阅读和手写速度打转。 架构是去中心化的，每个人的本地克隆都是一份完整、自包含的代码仓库。 工作模式是离线优先的，哪怕你带着笔记本电脑坐上没有网络的飞机，依然可以在本地翻看十年来的提交历史、切分支、做合并。
这三条假设在人类手写代码的时代无比优雅，但放到 2026 年的 Agent 工程环境里，每一条都变成了沉重的反噬。因为在 Anthropic 的机房里，每天发起两千多万次签出的主力根本不会坐飞机，也从来不需要断网写代码。无论是跑自动化评测的 Claude Agent 沙箱，还是跑单元测试的 CI 容器，按定义从生下来那一刻起就是永远在线的。一个存活时间只有五分钟、只为了修改三个文件并跑通测试的 Agent 沙箱，凭什么要先花好几分钟从镜像节点拉取几十 GB 的历史包和全量目录树？
看清这个矛盾之后，Anthropic 做了一个极其果断的架构决定：既然修补 Git 镜像集群已经没有出路，那就彻底放弃去中心化和离线优先的包袱，专门为永远在线的 Agent 和 CI 负载重写一套版本控制系统。
他们给这套新系统起名叫 Scion。整个设计只围绕一个核心判断展开：客户端默认永远联网，所有昂贵的存储、历史追溯和合并计算全部收归服务端，客户端只保留受限的本地缓存，用到哪个文件再去服务端按需拉取。
不存目录树快照，版本控制还能怎么设计
把版本控制从客户端搬回服务端，听起来很像回到了早年的集中式系统，但要在每天 3 万次合入、2,500 万次签出的规模下保持毫秒级响应，底层数据结构必须重新设计。
在传统 Git 里，每次提交本质上都关联着一棵完整的目录树快照。当仓库膨胀到百万级文件、日均合入三万次时，频繁打包、哈希计算和遍历目录树有向无环图，会把服务端和客户端的 CPU 一起拖垮。Scion 换掉了这套存储模型，吸取了 Google Piper 和 Meta Sapling 服务端架构 Mononoke 的先行经验，改用 Bonsai 数据结构把服务端的数据切分成了四层：
第一层是写前日志里的轻量级变更集。在 Scion 中，最小的工作单元换成了记录在服务端写前日志里的变更集，甩掉了全量目录树快照的包袱。每个变更集极其轻巧，里面只记录相对于第一个父节点修改了哪些文件路径，外加指向底层文件内容块的指针。客户端提交代码时，省去了在本地打包对象数据库的步骤，直接向服务端发一次轻量级的远程调用，由服务端顺序写入日志即可。
第二层是内容寻址的不可变块存储。所有文件的真实内容都会经过压缩，按内容哈希寻址，存进后端的对象存储里。因为文件内容块是不可变的，不同分支、不同历史版本之间只要文件内容没变，就天然共享同一个指针，彻底消除了重复落盘的开销。
第三层是整套设计里最精妙的部分，叫作派生数据。平时我们用版本控制工具，除了提交和拉取代码，还需要查某行代码是谁写的、看某个目录的历史改动记录、或者在提交图里快速跳转。如果把这些索引全塞进核心提交流程，每次合入都会变慢。Scion 把所有位于基础变更集之外的查询结构全剥离出来，统称为派生数据。这些数据结构有一个共同特征：都可以根据父节点的派生数据加上当前变更集的改动递归计算出来。服务端可以根据业务冷热程度，选择在提交时立即算出结果，或者等到有人查询时再按需惰性求值。这种剥离带来了一个巨大的工程红利：如果团队下周想加一套全新的代码拷贝检测索引或者路径搜索结构，只需要在服务端新增一种派生数据类型，在后台静默算完就行，所有客户端和 Agent 沙箱一行代码都不用改。
第四层则是面向客户端的 API 直查与稀疏签出。因为历史、Diff 和 Blame 全都作为派生数据躺在服务端，绝大多数只需要做代码分析、评审或者局部修改的 Agent 任务，直接调服务端 API 就能拿到所需上下文，压根不需要在本地磁盘上签出一份完整仓库。就算遇到必须落盘编译的任务，客户端也只通过受限的本地缓存拉取所需目录，签出耗时直接从原来的好几分钟缩短到了几秒钟。
一天合入三万次代码，评审和排队怎么跟上
如果只换掉底层的 git 命令行工具，一天 30,000 次合入的洪流照样会在上游把研发流水线冲垮。原因很简单：在传统的开发流程里，代码写完之后要经历漫长的本地 Rebase、人工逐行评审，最后塞进一条串行的合并队列等待测试通过。当合入频率高达每两三秒一次时，你在本地刚跑完 Rebase 准备推送，主干就已经往前走了几十个版本；如果所有变更都堵在一条单线程的合并队列里抢全局锁，整家公司的代码合入马上就会锁死。
所以在重写 Scion 的同一时期，这支团队顺手把围绕代码合入的周边生态也重做了一遍，核心立起了三根支柱：
全部收归服务端的并发合入管线：既然客户端总是落后于主干，Scion 干脆把 Rebase、合并与冲突检测全部挪到了服务端执行。服务端掌握着全局最新的写前日志，能够在极短时间内完成非冲突路径的并发落地。同时，工程团队调整了验证重心，把原本堆在合入前串行独木桥上的重型测试往后挪，大幅强化合入后与部署前的自动化验证体系。就算极少数高并发合入引发了逻辑冲突，也可以依靠随时在线的 Coding Agent 在几分钟内自动定位并提交修复补丁，用极快的自愈速度换取主干的高吞吐。 专为高吞吐设计的评审台 Antique：传统的网页端 PR 界面是为人类一天看几个补丁设计的，面对海量由 Agent 生成、高频迭代的变更集很快就会变得卡顿且难以抓重点。团队配套开发了一套名为 Antique 的内部代码评审界面，专门针对高频变更集、结构化差异对比以及人机协同评审做了深度定制，还配上了全新的全局代码搜索引擎。 源码级细粒度 IAM 权限系统：在传统 Git 仓库里，权限控制通常极其粗放，只要一个任务能克隆仓库，往往就能把整个单体仓库的源码看个底朝天。当公司里有成千上万个自动运行的 Agent 沙箱和外部研究任务时，这种粗放模式会带来严重的安全隐患。Scion 在服务端 API 层直接内建了细粒度的身份与访问管理，精确规定每一个 Agent 身份、每一个研究容器能够读取或修改哪些目录路径，把安全边界焊死在了源码服务端。
为了直观展示传统的本地串行合入与 Scion 服务端流水线的差异，我们可以看下面这段简化的服务端提交流程伪代码：
def land_changeset_on_server(agent_id: str, base_rev: str, modified_files: dict[str, bytes]):
verify_path_permissions(agent_id, list(modified_files.keys()))
blob_pointers = {
path: blob_store.put_immutable_compressed(content)
for path, content in modified_files.items()
}
latest_head = wal.get_latest_head()
rebased_parent = server_side_fast_rebase(base_rev, latest_head, set(modified_files.keys()))
changeset = Changeset(parent=rebased_parent, file_changes=blob_pointers, author=agent_id)
new_rev = wal.append_atomic(changeset)
derived_data_engine.schedule_incremental_update(new_rev)
post_merge_pipeline.enqueue(new_rev)
return new_rev
从这段逻辑里能看得很清楚：客户端既不用拉全量历史，也不用自己扛着几十 GB 的目录树在本地解冲突。它只管把改好的几个文件发给服务端，剩下的权限校验、内容落盘、服务端自动变基和派生索引更新，全在中心化服务端一气呵成。
七个人五个月换掉底层底座，账是怎么算过来的
看到这里，你可能也会替他们捏一把汗：给一家高速运转的 AI 公司换版本控制底座，堪比给正在万米高空飞行的喷气式客机换发动机，而且还要把 100 GB 的历史记录、几千万次日常构建和配套的评审系统一起迁过去，到底要多少人干多久？答案既反常识又在情理之中：整个项目从立项研发到把单体仓库彻底从 Git 迁走，一共只用了 7 名工程师，历时 5 个月。
7 个人能在 5 个月里啃下原本需要几十人团队打磨两三年的硬骨头，秘诀正是引发这场危机的源头，也就是 Claude 本身。在开发 Scion 的过程中，这支小团队把内部最新版本的 Claude 当成了核心主力。复盘里分享了一个极其生动的细节：为了把庞大的旧 Git 历史完整转换并导入 Scion 的 Bonsai 数据结构，工程师们先手写了第一版数据导入管线，跑通之后发现性能和内存开销都不够理想。于是他们直接让内部版 Claude 对着这版代码做重写和优化。Claude 重写出来的版本一次性跑通了全量数据校验，运行速度比人类手写版快了 4 倍，内存占用也直接降到了原来的二十分之一。
全量切换到 Scion 之后，最终交出的工程账单非常有说服力：
结合上面的数据图可以看得很明白，这场架构手术没有半点炫技成分，实打实帮公司省下了海量的服务器和等待时间。Anthropic 在文章末尾也坦承，他们并不打算把 Scion 开源或者包装成通用的 Git 替代品。对于绝大多数日常提交还在几百次的常规团队来说，Git 依然是最好用的工具。
但 Scion 的诞生却像一面提前立在路边的镜子。过去两年里，所有人的目光都盯在模型能不能把代码写对上；等到模型真的能日夜不停地产出高质量补丁时，人们才突然发现，我们手里握着的编译器、版本控制、合并队列、代码评审台乃至权限系统，全都是按照人类手指敲键盘的速度设计的。当写代码的速度被放大十倍甚至百倍，软件工程里那些原本不起眼的摩擦点就会瞬间变成堵死全局的堰塞湖。Anthropic 今天在每天 3 万次合入时撞上的这堵墙，用不了多久，就会出现在每一家认真推进 Agent 规模化工程的团队面前。
原文与参考链接：
Anthropic 官方原文（Redesigning source control at Anthropic）：https://www.anthropic.com/research/redesigning-source-control Simon Willison 拆解笔记：https://simonwillison.net/2026/Oct/13/redesigning-source-control-at-anthropic/
-- 完 --
机智流推荐阅读：
1.
2.
3.
4.
cc | 大模型技术交流群 hf | HuggingFace 高赞论文分享群 lc｜LangChain 技术交流群 code | AI Coding 交流群 具身 | 具身智能交流群 硬件 | AI 硬件交流群 推理 | AI 推理框架交流群 智能体 | Agent 技术交流群
