Cursor 用 Agent Swarm 重写 SQLite，成本差 15 倍 · AI HOT
meng shao @shao__meng 43
2026-07-21 09:24 · 14小时前
跳到正文 AI 摘要 Cursor 团队用 Agent Swarm 从零实现 SQLite 的 Rust 复刻，仅凭 835 页文档，通过 withheld 测试集 100%。新 harness 下，质量相近时成本从 $1,339（Opus 规划 + Composer 执行）到 $20,057（全程 Fable 5），差 15 倍。核心在于让强模型只做高熵决策，便宜模型吃执行量，而非一律上最贵模型。
meng shao @shao__meng · X 2026-07-21 09:24 · 14小时前
在 X 看原推 · x.com AI 摘要 Cursor 团队用 Agent Swarm 从零实现 SQLite 的 Rust 复刻，仅凭 835 页文档，通过 withheld 测试集 100%。新 harness 下，质量相近时成本从 $1,339（Opus 规划 + Composer 执行）到 $20,057（全程 Fable 5），差 15 倍。核心在于让强模型只做高熵决策，便宜模型吃执行量，而非一律上最贵模型。
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...
形状随问题生长，不是固定拓扑。他们认为这解释了为何同一套结构能覆盖浏览器、数学、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...
