Cursor 团队晒出的 swarm 实战：用 Opus 规划、Composer 执行，四小时从零写出能通过全套测试的 SQLite，成本只要一千刀出头。工程细节很硬核，值得看他们怎么解决多 agent 的协调问题。
Cursor 团队用 Agent Swarm 系统从零实现 SQLite，依据 835 页文档用 Rust 编写并 100% 通过 withheld 的 sqllogictest。新 harness 下，Opus 4.8 规划 + Composer 2.5 执行成本约 $1,339，而全程用 Fable 5 则需 $20,057，质量相近。关键工程发现：协调成本和上下文效率比并行更重要，新系统冲突低于 1000 次，旧系统超 7 万次。成本大头在于更贵模型的规划决策，但廉价 worker 可承担 90%+ 的 token 消耗。
Agent Swarm 与新模型经济学：Fable 5 全程两万刀，Opus 规划 + Composer 执行一千三 https://t.co/edsde4pWnC 当任务规模大到单 agent 扛...
Agent Swarm 与新模型经济学：Fable 5 全程两万刀，Opus 规划 + Composer 执行一千三 cursor.com/blog/agent-swa… 当任务规模大到单 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 github.com/cursor/minisql… 读完后应保留的判断边界 · Harness > 模型混搭：行为差异比分数差异更能解释「能不能持续跑完」。 · 并行不是主因，上下文分工才是——这解释了为何中等任务也可能受益。 · 成本优化的主杠杆是「frontier 只做高熵决策，廉价模型吃执行量」，不是一律上最贵模型。 · 这是强受控实验（封闭环境、文档即规格、功能等价测试）；真实工程还有产品判断、历史包袱、组织流程，不能直接外推为「swarm 已可替代团队」。 · Cursor 团队也承认：GPT-5.6 Sol 因 prompt 敏感导致 runaway，未公平纳入；solo frontier 成本仅作参考、未正式打分。 Cursor @cursor_ai 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 varied 15x depending on which model mix we used. 🔗 View Quoted Tweet 💬 2 🔄 0 ❤️ 0 👀 572 📊 2 ⚡