Agent 时代，Cursor 的 Git 扩展实践

Git 最初就是为分布式协作设计的，但今天的大多数开发流程，都依赖中心化的代码托管服务。到了服务端，Git 的存储结构开始带来新的扩展难题：文件内容、提交和树对象会被压缩进 Packfile，很多 Git 操作又需要沿着 DAG 逐步读取相关对象。如果这些数据分散在远程存储中，一次操作就可能产生多次网络往返，延迟也会随之累积。

GitHub 后来用 Spokes 解决这类问题：每个副本都保留一份完整的 Git 仓库，并放在本地 NVMe 上。Push 时，系统先把 Packfile 分发到多个副本，再通过三阶段提交同步引用事务。这样一来，任意副本都能提供一致的 fetch 和 clone。

这套架构支撑 Git 托管很多年，但 Agent 带来了新的规模压力。

一方面是越来越大的 monorepo。CI 和读取流量持续增加，需要更多副本来分担压力；副本越多，三阶段提交越容易受到最慢节点影响，Push 吞吐也会下降。

另一方面是海量小型、短生命周期仓库。Agent 会频繁创建这类 repo，如果每个仓库都维持多份副本，存储和运维成本会很高。

Cursor 为此设计了 Continuity。它把写前日志放到 S3，让 WAL 成为仓库状态的权威来源，本地 NVMe 上的 Git 仓库则作为可恢复的 warm cache。Push 会先写入 WAL，再通过 CAS 更新索引；副本可以根据负载增加或减少，空闲仓库也可以从磁盘回收，需要时再从 WAL 恢复。

这样一来，大型 monorepo 可以扩展到更多副本，小仓库可以只保留少量本地副本，同时维持一致读。

Cursor 的测试中，只读操作扩展到 100 个副本时仍保持线性增长；S3 Standard 下，Push 吞吐约为 120 次/秒；S3 Express One Zone 下则超过 300 次/秒。

cursor Git Agent 分布式系统 系统设计