前言¶
2026 年 7 月，Cursor 在官方博客「Agent swarms and the new model economics」中公布了 Cursor 3 升级版 Agent Swarm 的架构与基准结果。这套系统把 AI 编码工作拆成两类角色：Planner（规划者） 用前沿大模型做任务分解与设计决策，Worker（执行者） 用更快、更便宜的模型写代码。两者配合，在「仅凭 SQLite 手册、从零用 Rust 重写数据库引擎」的闭卷测试中，四种正式对比配置最终都达到了 sqllogictest 隐藏测试集的 100% 通过率；最便宜的一组（Opus 4.8 规划 + Composer 2.5 执行）总账单约 \(1,339**，而同任务下 GPT-5.5 单模型包办约 **\)10,565。
媒体常把这一差距概括为「约 15 倍」——这个数字来自非正式对照跑分（Fable 5 单模型约 $20,057 ÷ $1,339）。Cursor 自己在四组受控对比里给出的区间是 约 7.9 倍；若只比 Worker 层 token 账单，GPT-5.5 单跑 Worker 花费 $9,373，Opus + Composer 混合跑 Worker 仅 $411，差距约 22 倍。下文按官方一手信息梳理架构原理、基准细节与成本算术，方便读者判断这套分层是否值得在自己的工程里借鉴。
单 Agent 的上下文困境¶
Cursor 把大型软件任务自然建模成一棵树：根节点是总目标，递归向下拆成越来越小的子任务。单个 Agent 若独自完成整棵树，必须在上下文里同时记住「全局目标、当前路径、叶子节点细节」，长程运行中很容易 漂移——要么只顾眼前实现、丢失架构一致性，要么死守大图、局部代码质量下降。
Agent Swarm 的解法很直接：
- Planner：只负责拆分与委派，不写实现代码，上下文不被低层细节占满。
- Worker：只执行被派发的窄任务，不做规划，全部上下文留给当前这一块工作。
Cursor 认为，Swarm 的可扩展性主要来自这种 上下文效率，而不只是「多开几个 Agent 并行」。经济学家 Coase 关于「企业为何存在」的论述在这里有呼应：协调成本增长快于工作量本身，因此系统会自然分层，而不是让所有人两两直接对话。
SQLite 转 Rust：闭卷基准怎么测¶
为验证新架构，Cursor 让新旧两代 Swarm 做同一道题：
只给 835 页 SQLite 官方手册，要求用 Rust 实现完整数据库引擎；不提供 SQLite 源码、测试套件、二进制和互联网访问。
评分使用 SQLite 项目的 sqllogictest——包含数百万条 SQL 及标准答案，用于跨引擎比对查询结果。Swarm 事先不知道 这套测试存在；跑完后 Cursor 还会人工审查是否作弊、是否只在测试覆盖区域堆代码。
四组受控模型配置如下：
- GPT-5.5 兼任 Planner 与 Worker（强前沿模型单跑）
- Grok 4.5 兼任 Planner 与 Worker（成本较低的前沿模型单跑）
- Opus 4.8 规划 + Composer 2.5 执行
- Fable 5 规划 + Composer 2.5 执行
新 harness 在每一组配置下都优于旧版。 四小时后，新系统通过率约在 73%–85%，旧系统仅 11%–77%；旧版 Grok 跑甚至在两小时内因 merge 冲突失控被暂停。最终，四组新配置全部达到 100%。
代码体量差距同样明显。以 Opus 相关对比为例：旧 harness 约 19,013 行、准确率 97%；新 harness 4,645 行、准确率 100%，代码量约减 85%。旧 Grok 跑在 2 小时内产生约 68,000 次 commit（约为新系统的 70 倍），却积累 7 万+ merge 冲突；新系统全程不足 1,000 次冲突。旧版把项目拆成 54 个 Rust crate（含 3 套重复 SQL 包），新版稳定在 9 个 crate。
账单算术：7.9 倍、15 倍与 22 倍¶
先看 Cursor 正式对比的四组总成本（均达到 100% 通过率）：
| 配置 | 总成本（约） |
|---|---|
| Opus 4.8 + Composer 2.5 | $1,339 |
| Grok 4.5 单模型 | $1,928 |
| Fable 5 + Composer 2.5 | $2,234 |
| GPT-5.5 单模型 | $10,565 |
$10,565 ÷ $1,339 ≈ 7.9 倍——这是官方受控对比里最直接的「总账单倍数」。
Worker 层才是大头：各次运行中 Worker 产出至少 69% token，多数超过 90%。GPT-5.5 单跑里 Worker alone 约 \(9,373**；Opus 规划 + Composer 执行时，整个 Worker 舰队约 **\)411。$9,373 ÷ $411 ≈ 22.8 倍——这反映的是「执行层换便宜模型」的杠杆，而非整单成本。
媒体报道的 ~15 倍，通常用图表中带脚注的 Fable 5 单模型非正式跑（约 $20,057，Cursor 标明 informal run for cost calibration, not part of the controlled comparison）去除以 $1,339 得出。算术成立，但对照组不在官方评分矩阵内，引用时需说明口径。
Composer 2.5 作为 Worker 的定价为：输入 \(0.50 / 百万 token**，输出 **\)2.50 / 百万 token。Cursor 创始人 Michael Truell 称其基于 Kimi K2.5，性能宣称接近 Opus 4.7 / GPT-5.5——该说法尚未经第三方公开基准独立验证。在 Opus + Composer 混合跑中，Opus 作为 Planner 只产出少量 token，却约占 总成本的三分之二；Composer 处理绝大多数 token，只占约 三分之一——说明「少数时刻需要前沿判断力，大量执行可以下沉到廉价模型」这一分工逻辑。
1000 commits/s：协调工程才是隐藏主角¶
旧版浏览器 Swarm 在 Git 上峰值约 1000 commits/小时；新版自研 VCS 峰值约 1000 commits/秒。所有变更经 VCS 汇聚，冲突在这里最先暴露，多种协调机制也实现在这一层。
Cursor 文档化了若干在高并发下才会放大的失败模式及对策：
- Split-brain（分裂脑）：两个 Planner 互不知晓，各自实现同一概念。对策：Planner 自己做设计决策，并保证委派子树不重复决定同一问题；共享设计文档 + 编译期引用 绑定决策与代码。
- Merge 冲突：Worker 不擅长合并，容易覆盖或放弃。对策：中立第三方 Agent 专门仲裁冲突。
- Megafiles（巨型文件）：多 Agent 往同一文件堆代码，diff/merge 成本爆炸。对策：Worker 可标记臃肿文件，外部 Agent 将其拆成更小模块。
- Ossification（僵化）：Agent 学到「不要动核心代码」。对策：允许有理由的越界修改，编译错误驱动下游 Agent 跟随调整。
- Field Guide（现场指南）：Agent 自维护、有行数上限的知识文档，每次会话启动时注入，类似蚁群的 Stigmergy（环境痕迹协调）。
此外还有多种 Review Lens 叠加审查——不同模型、不同信息粒度并行审代码，类似自动驾驶多传感器融合，用相对便宜的审查算力换整体质量。
从 Vibe Coding 到「Spec 即 Prompt」¶
Cursor 把 Swarm 的工作单元抬升到 Spec（规格说明） 一层：Autocomplete 时代一行一行补全，Agent 时代以文件/功能为单位，Swarm 时代则以 意图描述 为输入。本次实验只给了 835 页手册 prose，输出是可运行的数据库——稀缺资源从「会不会写循环」变成 「能不能把意图写清楚」。
这与 Vibe Coding（氛围编程） 的流行形成有趣对照：个人开发者用自然语言快速迭代原型；Swarm 则把同一思路推到 工业级并行与账单优化——前沿模型只在分解与关键 trade-off 上出场，其余交给 Composer 这类「够用的 Worker」。Swarm 被 Cursor 比作 概率性编译器：Planner 把目标降到任务树，再逐步 lower 成可执行工作；与确定性编译器不同，每一步都有不确定性，上文那些 VCS、Review、Field Guide 机制就是在 缩小语义漂移。
开源仓库 github.com/cursor/minisqlite 发布了 Opus 4.8 单跑版本的代码（非上述最便宜混合跑），供社区自行审查质量。
冷静看待：基准很亮，落地仍早¶
需要强调的 caveat：
- 这是 Cursor 自研基准上的自研系统，商业上有展示动机；闭卷重写 SQLite 与日常业务代码库差异很大。
- Cursor 在文中引用的外部研究指出：68% 的生产环境 AI Agent 在 10 步以内 就会停滞——今日的成本优势主要体现在 受控长任务实验，尚不能自动外推到普通 CRUD 维护。
- Fable 5 作 Planner 虽 planning token 更少，但其 Worker 消耗远高于 Opus Planner 配置，总成本反而更高——说明「Planner 越强/越省不一定越便宜」，Worker 效率与规划质量强耦合。
- 混合架构对 Spec 质量 依赖极高：Planner 一旦分解错误或设计文档矛盾，廉价 Worker 只会高效地写错代码。
结语¶
Cursor 3 的 Agent Swarm 用 Planner/Worker 分层回答了一个工程经济学问题：大任务里真正需要前沿模型的时刻很少，但 token 产量最大的执行层可以换便宜模型。 在 SQLite→Rust 闭卷测试中，新 harness 在准确率、代码量、冲突率上全面优于旧版；受控总成本从约 $10,565 降到 $1,339（约 7.9 倍），Worker 层 alone 可从 $9,373 降到 $411（约 22 倍）。「15 倍」作为传播口径存在，但读者应区分 总账单、Worker 账单、非正式对照 三种算法。
对普通开发者，短期更现实的收益可能是 Cursor 3 产品里的 多 Agent 并行编排 与 Composer 2.5 这类高性价比 Worker；长期则值得思考：你的团队是否能把需求写成像 SQLite 手册那样足够明确的 Spec，让 Planner 分得清、Worker 写得稳。分层架构节省的不只是 API 账单，还有 merge 冲突和冗余 crate 带来的 认知与协作成本——这或许比 headline 里的倍数更值得带入下一次架构评审。
