Cursor工程师拆解Git托管20年难题：S3当WAL，磁盘Git降级为缓存

Cursor 工程师 Vicent Martí 最近发了一篇技术长文《Git at any scale》，把 20 年 Git 托管为什么这么难，讲成了一条干净到可怕的问题链。这位老哥在 GitHub 干了十年 Git 存储，是 libgit2 那拨人，对 Git 底层的理解属于第一梯队。

先说清楚，这篇文章跟 Origin 上线的软文没关系。Origin 现在还是 early beta，压测数字不是 SLA，镜像仓的 source of truth 仍是 GitHub。但文章本身，把 Git 托管的核心矛盾拆得极其透彻。

Git 的分布式，在服务端是原罪

Linus 当年给内核设计的是去中心化工作流，客户端每台电脑一份完整仓库，这在协作上是优点。但今天所有公司都跑在中心化托管上，问题就来了：服务器上的仓库必须和你笔记本上的长得一模一样。

文件系统语义、随机 IO、DAG 指针追逐，全是按这个假设长出来的。托管 Git 难，根源在数据模型就别扭。客户端分布式是特性，服务端分布式是枷锁。

对象扔进 S3 就完事？会被往返延迟打死

你不能把 Git 对象直接扔进 S3 或者 KV 存储就完事。Git 是 DAG，读一个 commit 得先拿到它才知道下一个 tree 的 key，读了 tree 才知道 blob。对象级分布式会被往返延迟打死。

有人试过 DHT，普通操作还行，但 git clone 因为协议必须吐 packfile，直接崩了。这条路走不通。

GitHub 的 Spokes 成了行业标准，但死穴很硬

GitHub 2013 年做的 Spokes 后来成了行业标准：本地 NVMe 放完整仓库，packfile 复制，引用更新走三阶段提交，强一致，任意副本可读。

但死穴很硬：

• 副本越多 push 越慢，被最慢那台拖死
• 每个仓库要 3 个副本，闲着也占着
• 仓库必须精确路由，checksum 坏了赶紧修

官方原话叫 repos as pets not cattle。2013 年 3 副本是最优解，今天巨型 monorepo 不够用，agent 海量短命小仓更不够用。

最值钱的翻转：S3 当 WAL，磁盘 Git 只是缓存

整篇最值钱的翻转在这里：Cursor 的 Continuity 把 S3 当 WAL，磁盘上的 Git 只是缓存。

Push 先写成 S3 上的 WAL，没持久化绝不 ack。本地 NVMe 是标准 Git 仓库，继续用原版 Git 工具，少发明新 bug。

没有 Paxos，没有 Raft，没有路由表，没有外部数据库。用 S3 的原子 CAS 选 primary，复制通知甚至走不可靠的 UDP gossip，丢包无所谓。replica 对 S3 做 conditional GET，304 说明已是最新，200 就追上。

有人压成一句话：S3 是块魔法软件，你肯让它当真相源，就能消掉 90% 的 Git 托管难题。不完全夸张。

伸缩形状终于对上了 Agent 世界

闲置仓库可以 0 副本，下次访问再从 WAL 物化。热 monorepo 可以拉到 100+ 读副本，读吞吐线性涨，push 不回退。

压测数据：S3 Standard 约 120 push/s，S3 Express One Zone 300+，瓶颈变成 Git 自己的 compaction。

人一天几次 clone push，agent 是几十上百个同时 clone、开分支、rebase、修 CI。旧架构两头难受：小仓浪费 3 副本，大仓加不了副本。这才是 Origin 存在的真正理由。

金句也是设计原则：降级时永远正确，健康时永远快

系统降级时永远正确，健康时永远快。降级从 S3 重建，正确性不丢；健康走本地 NVMe，快。

WAL 里有完整 provenance，每个 push 每次 repack 都能回放。Git 出 bug 时能精确倒带。

对不搞底层的人，记住三件事

第一，Cursor 做的事情跟 GitHub 皮肤完全无关。它在给成千上万 agent 同时撞同一个仓库修地基。上一轮 Cloud Agent 自动跟 PR 修 CI，底层要的就是这种存储。

第二，别因为这篇文章立刻搬家。Origin 早期功能不全，定价和安全细节还少，镜像仓 push 仍回 GitHub。

第三，可带走的心智只有一句：别把缓存当真相，日志才是真相。

AI 写代码的瓶颈，正在从模型会不会写，变成仓库能不能被一百个 agent 同时撞而不炸。这篇博客真正厉害的地方，是它把这句话写成了一个可运行的存储系统。

但设计厉害和产品打赢是两回事。应该是先敬畏技术，再等产品落地。