本期亮点

  • Origin Code Hosting：Cursor 发布自研 Git 托管系统，以 WAL-first + S3 为核心设计，突破 GitHub Spokes 的水平扩展瓶颈
  • Cloud Agents 更新：事件驱动的 Subscriptions、子 agent 独立 VM、/goal 持久目标
  • 技术深度：Continuity 系统设计详解，值得反复研读

核心解析：为什么 Git 托管是个地狱级难题

Vicent Martí（Origin 项目负责人）在这篇博文中给出了一个教科书级别的系统分析。他的核心论点是：Git 的分布式设计是针对 Linux 内核那样的去中心化工作流优化的，但现实中 99% 的公司其实需要一个强一致的中央协调点。这个根本矛盾导致大规模 Git 托管成为一个被低估的技术难题。

Packfile：一切的罪魁祸首

Git 的数据存储单元是 packfile，这是一种压缩后的二进制格式，对象在 packfile 里的物理位置与其在 DAG 中的逻辑位置毫无关联。一个 commit 指向某个 tree，tree 指向若干 blob，要读取它们必须沿着 DAG 边跳转，而每条边都可能跳到 packfile 里任意偏移量的位置。

这种随机读写模式在本地 NVMe 上没问题，但一旦上网络存储，带宽和延迟会让性能崩溃。GitHub 早年试过 GFS（Google File System）和 DRBD，最终都撞墙了——packfile 随机读的 IO 模式和网络文件系统的线性读写模式天然不兼容。

GitHub Spokes 的历史选择与局限

GitHub 在 2013 年推出的 Spokes 是一个三副本强一致的复制方案，使用 3PC（三阶段提交）来保证每个 push 在所有副本同步完成后才应答。这个设计在很长时间内都是行业标准，GitHub、GitLab 等主流平台都借鉴了类似思路。

但 Spokes 有一个致命弱点：3PC 的延迟由最慢的节点决定。想增加更多副本提升读取吞吐？副本越多，每次 push 的协调成本越高，吞吐量反而下降。这就是"tail at scale"问题。

此外，Spokes 把副本当作"宠物"而非"牲畜"——每个副本里存的是真实 Git 仓库，损坏一个就得立即修复，否则三副本坏两个就丧失 quorum 了。运维成本极高。

Continuity：重新设计 Git 存储

WAL-first 架构

Continuity 的核心洞察是：把 WAL（Write-Ahead Log）作为 Source of Truth，S3 作为 WAL 的存储后端。

Push 流程：
1. 同时写本地 NVMe packfile + 上传 S3 WAL entry
2. 只有 WAL 完全持久化后才应答 client
3. Reference transaction 在本地副本 prepare 后，更新 WAL index（也是一个 S3 对象）
4. WAL index 的更新是原子的（通过 S3 CAS 实现）

这个设计保证了线性化（linearizable）push：所有 push 的全局顺序由 WAL 的原子更新保证，没有分布式协调开销。

无状态的"有状态"系统

最妙的地方在于：虽然系统保证强一致，但它不需要任何节点级别的共识。

  • 仓库在哪不重要，用 rendezvous hashing 做路由，但路由信息不准确也没关系
  • S3 是 source of truth，任何节点都可以作为"primary"接收 push
  • 如果某节点上没有某个仓库的本地副本？直接从 WAL 回放即可

"There's no state and no consensus here. Any server can be the primary."

这和传统的"找 master"的思路完全相反——系统在正常时选择同一个 primary 优化性能，但在故障时完全不 care 谁是 primary，因为 WAL 保证了一切正确性。

UDP gossip + 条件 GET：真正可水平扩展的复制

副本之间通过 UDP gossip 同步：每个 gRPC 包携带该副本已同步到的 WAL index ETag。当某个副本收到 fetch 请求时，它做一次 S3 conditional GET（If-None-Match: ）：

  • 304 响应：本地数据已是最新，直接服务读请求（<10ms）
  • 200 响应：需要先从 WAL 回放追赶，然后服务读请求

关键是：UDP 丢包无所谓，因为每次读操作都通过 S3 ETag 做最终校验。这是一种"乐观复制 + 最终校验"的设计——性能接近 eventual consistency，但一致性保证是实打实的强一致。

数据：线性扩展到 100+ 副本

  • 读取吞吐：100 副本下线性扩展，无退化
  • Push 吞吐（标准 S3）：~120 pushes/s（含压缩和复制）
  • Push 吞吐（S3 Express One Zone）：>300 pushes/s，受限于本地 Git 压缩速度

对 Cursor Agent 生态的意义

这篇文章表面讲 Git 托管，实际上揭示了 Cursor 的宏大野心。

Agent Swarm 的基础设施依赖。当 Cursor 推动"self-driving codebases"愿景时，需要大量并行的 agent 实例同时操作代码仓库。如果每个 agent 都要 clone 一个巨型 monorepo，或者 push 时要等 3PC 协调，agent 的并发能力会被 Git 基础设施卡死。

多副本按需分配。大型 monorepo 可以在数百个副本上服务 CI 并发读；数百万个 agent 临时创建的小仓库各自只需 1 个本地副本，S3 兜底可用性。这彻底解决了 Spokes"每个仓库都要 3 副本"的固定开销问题。

为 Cloud Agents 提供确定性保证。8/19 的 Cloud Agents 更新里，Subscriptions（事件驱动唤醒）和 /goal（持久目标）都需要后端状态可靠。Origin 的 WAL-first 设计让 Cursor 的 agent 系统有了强一致的状态基础——这才是让 agent"跨会话持续工作"的底层保障。

Cloud Agents 8/19 更新速览

功能意义
Subscriptions事件驱动：监控 PR、Slack thread、定时任务，事件触发 agent 唤醒
Custom Modes把 skill 当作固定 pin 的上下文，agent 始终在特定 playbook 模式下工作
Subagents on own VMs子 agent 运行在独立 VM，环境隔离、并行测试
/goal长期目标指令，agent 持续工作直到目标完全达成
Steering 改进发送 steering 消息不打断 agent，等待下一个 tool call 时机执行

观点

Cursor 正在做一件罕见的事：用工程系统性思维而非功能堆叠来做 AI 编程工具。

Origin Code Hosting 不是"又一个 GitHub 替代品"，而是一块专为 AI Agent 工作流重新设计的版本控制基础设施。WAL-first + S3 的组合解决了三个核心矛盾：

  1. 强一致 vs. 水平扩展（3PC 改为 S3 CAS）
  2. 高吞吐写入 vs. 随机读取（NVMe 缓存 WAL 回放）
  3. 多副本强一致 vs. 运维复杂度（仓库作为 warm cache 而非 pets）

这三个解法合在一起，才让 agent swarm 真正成为可能。这篇文章值得每个做分布式系统或 AI infrastructure 的人细读。

本期整理：2026-08-21