# Cursor 用 Agent Swarm 重写 SQLite，成本差 15 倍

- 来源：meng shao (@shao__meng)
- 发布时间：2026-07-21 09:24
- AIHOT 分数：43
- AIHOT 链接：https://aihot.virxact.com/items/cmrtzxl5s45c7bihzd439mgpv
- 原文链接：https://x.com/shao__meng/status/2079377048582426679

## AI 摘要

Cursor 团队用 Agent Swarm 从零实现 SQLite 的 Rust 复刻，仅凭 835 页文档，通过 withheld 测试集 100%。新 harness 下，质量相近时成本从 $1,339（Opus 规划 + Composer 执行）到 $20,057（全程 Fable 5），差 15 倍。核心在于让强模型只做高熵决策，便宜模型吃执行量，而非一律上最贵模型。

## 正文

Agent Swarm 与新模型经济学：Fable 5 全程两万刀，Opus 规划 + Composer 执行一千三
https://cursor.com/blog/agent-swarm-model-economics

当任务规模大到单 agent 扛不住时，真正的瓶颈从模型智力转向协调成本与上下文经济学；把 harness 工程化之后，模型组合可以做到质量接近、成本差一个数量级。

Cursor 团队在验证什么？
早先用 swarm 从零写浏览器：能跑通，但远未成「成品」。那次是经验摸索；这次目标是把 swarm 从试出来变成设计出来。

对照任务：只给 835 页 SQLite 文档，用 Rust 从零实现；无源码、无官方测试、无二进制、无外网。用 withheld 的 sqllogictest 打分。新旧 harness、同模型、同时间预算对比。

· 新 harness 在所有模型配置下都更好
· Grok 4.5：新系统 4 小时约 80%；旧系统不到 2 小时就失控暂停
· 不同模型 mix 质量接近，费用差极大

架构：树，而不是固定流水线
大任务天然是树：根目标递归拆到叶子。
· Planner：强模型，拆分、决策、委派
· Worker：快且便宜的模型，执行窄任务

形状随问题生长，不是固定拓扑。他们认为这解释了为何同一套结构能覆盖浏览器、数学、GPU kernel、找漏洞、提覆盖率、造合成数据等不同任务。

关键判断：可扩展性主要来自上下文效率，而不只是并行。
单 agent 要一边盯全局一边做局部，必然漂移；swarm 让 planner 不写实现、worker 不规划，各自把上下文用在该用的地方。文中用科斯的企业理论类比：协调成本上升比工作本身更快，所以组织会出现分层边界。

工程现实：千级 commit/秒下的失败模式
旧浏览器 swarm 约 1000 commits/小时；新系统峰值约 1000 commits/秒。Git 级粗锁不够用，他们自研了面向 agent 的 VCS--吞吐只是一半理由，另一半是：所有变更都过 VCS，碰撞最先在这里暴露，协调机制也可做进这一层。

五类失败与对策（这是文章的工程骨架）：
· Split-brain：两个 planner 不知情地做同一设计
· Planner 争用：双方知道对方却在改同一文件对打
· Merge conflict：Worker 不会好好 merge，会覆盖或放弃
· Megafiles：热文件膨胀 → 传输/diff/冲突爆炸
· Ossification：Agent 学「别动核心」

另外两块「质量与记忆」：
· Review lenses：多视角、去相关的审查叠加（类自动驾驶多传感器）；审查比重做便宜，他们认为这对长期质量贡献很大
· Field Guide（stigmergy）：agent 自写共享上下文，启动时注入；权重冻结时，值得记录的是「意外」--缩短后续轨迹

结果：分数接近时，行为差很多
四小时节点：新系统约 73%-85%，旧系统约 11%-77%；之后新配置都能到 100%。

更说明问题的是「过程指标」：
· 旧 Grok：2 小时约 6.8 万 commits（约新系统 70 倍），冲突 >7 万 且加速；新系统 4 小时冲突 <1000
· 最热文件：旧 7771 次冲突 / 1173 个 agent；新最热文件仅 47
· 包结构：旧 54 crates（含 3 个 SQL 包）；新早期定 9 crates 后不再增
· 代码量（同过全套）：Fable mix 旧 64305 行 vs 新 9908；Opus mix 旧 19013@97% vs 新 4645@100%

Commit 多 ≠ 生产力高；多数是 thrash。Harness 差，会把算力烧成协调税。

模型经济学（标题真正落点）
质量相近时，成本约从 $1，339（Opus 4.8 planner + Composer 2.5 worker）到 $20，057（全程 Fable 5）。

支出结构稳定：
· Token：worker 通常占 ≥69%，多数 >90%
· 美元：planner 单价高，可占成本大头（Opus hybrid 里 planner 约 2/3 费用，却只产小部分 token）

核心经济命题：
大任务里真正需要 frontier 的时刻很少--根拆解、设计决策、关键取舍。一旦歧义被压成明确指令，便宜模型就能执行。

对照：GPT-5.5 双角色时，仅 worker 就 $9，373；Opus 规划 + Composer 执行时，整个 worker 舰队 $411。

补充细节：更强的 Fable 5 planner 虽单价更高、规划 token 更少，但 worker 消耗暴增，整次跑反而更贵--说明「更强 planner」不等于更优总账，还要看它如何塑造下游工作量。

更大叙事：抽象层级上移到 Spec
能力跃迁在抬高工程师的工作单元：行 → 块 → 文件/功能 → spec。

他们把 swarm 比作编译器：把意图逐级 lower 成可执行工作；区别是编译器逐步保义，swarm 每步都是概率的--文中整套机制，都是在缩小这条概率间隙。

稀缺资源从「会不会写代码」转向 意图描述是否正确、可执行、可检查。公开产物：
cursor/minisqlite
https://github.com/cursor/minisqlite

读完后应保留的判断边界
· Harness > 模型混搭：行为差异比分数差异更能解释「能不能持续跑完」。
· 并行不是主因，上下文分工才是--这解释了为何中等任务也可能受益。
· 成本优化的主杠杆是「frontier 只做高熵决策，廉价模型吃执行量」，不是一律上最贵模型。
· 这是强受控实验（封闭环境、文档即规格、功能等价测试）；真实工程还有产品判断、历史包袱、组织流程，不能直接外推为「swarm 已可替代团队」。
· Cursor 团队也承认：GPT-5.6 Sol 因 prompt 敏感导致 runaway，未公平纳入；solo frontier 成本仅作参考、未正式打分。

### 引用推文

> Cursor：We had a team of agents rebuild SQLite from its 835-page manual. It created a replica in Rust which passed 100% of a held-out test suite. Interestingly, cost va...