cursor agent swarm 是什么：成本与编排
Cursor 研究里的 agent swarm 不是产品开关：Planner+Worker 树状分解、自研 VCS 与 SQLite-from-docs 实验里的失败模式。
搜 cursor agent swarm 是什么，多半会搜到 Cursor 2026 年的研究文，而不是 IDE 里某个叫 Swarm 的开关。那是 Cursor 内部做多 Agent 编排的实验与工程复盘：Planner 用强模型拆任务，Worker 用便宜快的模型执行，配合自研版本系统扛极高 commit 吞吐。产品里的 Cloud Agent、worktree、CLI 仍是单会话或少会话形态，别把研究概念当成已上线的菜单项。
Planner 与 Worker 怎么分工
Agent swarms and the new model economics 把大任务自然描述成树：根是目标，递归拆到可执行叶子。Swarm 两个角色都沿同一棵树组织：
- Planner：强模型，只做分解与委派，不亲自写实现细节。
- Worker：快且便宜的模型，只执行被派到的那一片。
单 Agent 要自己从根走到每个叶子，上下文里同时塞祖先、当前节点和全局目标，长任务容易 drift。Swarm 里 Planner 上下文不被低层 diff 填满，Worker 上下文只服务窄任务；Cursor 认为这种上下文效率比「单纯并行开很多 Agent」更关键，中等规模任务也能受益。论文里 Opus solo 与 Fable solo 也跑过对照，成本在图里用 hatched bar 标出，质量未做 formal grade，说明 frontier 单模仍贵，但 hybrid 的价值在 harness 而不只在模型名。
这和你在 IDE 里开多个 Composer 会话不同：研究 swarm 有共享 VCS、设计文档 reconciler、中立 merge agent 等配套。日常编码可参考 别让 AI agent 白烧 token 控制会话数，但别期待 IDE 一键复现论文里的 1000 commits/s。博客还类比 Ronald Coase 的企业层级：协调成本随规模超线性增长，所以用有边界的 Planner/Worker 单元，而不是人人全上下文对话。
自研 VCS 与 SQLite-from-docs 实验
早期 browser-from-scratch swarm 在 Git 上峰值约 1000 commits/hour；新系统在自研 VCS 上峰值约 1000 commits/s。所有变更过 VCS，碰撞在这里先暴露，split-brain、merge、megafile 等机制都建在这一层。
回归测试任务：只给 835 页 SQLite 手册，让 swarm 用 Rust 从零实现，不给源码、测试套件、二进制和网络。评分用 sqllogictest held-out 套件（agent 不知道它的存在）。据 Cursor 自测，新旧 harness 在相同模型与时间预算下，新 swarm 在各配置下都更高；Grok 4.5 新 swarm 四小时内到约 80%，旧 swarm 第二小时内 spiral 被暂停。旧 Grok run 两小时内约 68k commits、7 万+ merge conflicts，最热单文件 7771 次冲突；新 run 四小时 conflicts 不足一千，最热文件 47 次。
四种模型组合（全 GPT-5.5、全 Grok 4.5、Opus 4.8+Composer 2.5、Fable 5+Composer 2.5）最终都能到 100% 套件通过，但账单差一个数量级：文档举例 Opus+Composer 混合约 $1,339，全 GPT-5.5 约 $10,565；worker token 占 69%–90%+，planner token 单价更高，Opus planner 约占总成本三分之二而 Composer worker 占三分之一。上述数字均为厂商实验数据，读者自行判断外推范围。
高峰 commit 率下的失败模式
人类团队熟悉的 code review、ownership 在 swarm tempo 下会变形。Cursor 命名的对策（摘要）：
| 失败模式 | 现象 | 对策方向 |
|---|---|---|
| split-brain | 两个 Planner 各实现同一概念 | Planner prompt：设计决策自己做，子树不重复决定同一问题 |
| planner contention | 两 Planner 来回改同一文件 | 共享 design doc + 编译期引用；reconciler 合并文档 |
| merge conflicts | Worker 覆盖或放弃他人改动 | 中立第三方 merge agent |
| megafiles | 热点文件膨胀、碰撞集中 | Worker 标记 bloated；阻断新提交，外部 agent 拆模块 |
| ossification | Agent 不敢动核心代码 | 允许带注释的 intentional breakage，编译错误驱动下游更新 |
还有 stacked review lenses：给 review agent 不同输入粒度（全 transcript / 仅输出 / 仅代码库）与不同模型，单 lens 抓不全，decorrelated 叠加接近「多传感器」；review 算力相对 worker 便宜，博客称回报高。Field Guide 是 agents 自维护的共享文件夹，index.md 按行预算注入每个 agent 启动上下文，专门记「对 frozen weights 的 surprise」，类似 stigmergy（蚂蚁靠环境间接协调）。
对日常 Cursor 用户意味着什么
研究结论指向「工作单元变成 spec」：Planner 把意图降到可执行指令后，弱模型也能跟。这与 Cursor 支持 agent plugins 把 skills/MCP 打包复用的方向一致，但 swarm 是 Cursor 内部 harness，不是 Settings 开关。
若你关心 Cloud Agent 怎么在 VM 里跑、怎么 handoff，看 cursor 本地和云端 agent 怎么切换 与 Cloud Agent hooks 指南。公开产物：solo Opus 4.8 run 的 minisqlite 在 github.com/cursor/minisqlite，Cursor 自述未做深度人工审计，可自行看代码。旧 swarm 54 个 Rust crate、三个 SQL 包；新 run 稳定在 9 个 crate，说明 split-brain 收敛差异会反映在最终仓库形状上，而不只是分数曲线。
博客把 swarm 比作「意图编译器」：Planner 把 spec 降到 task tree，再降到可执行工作，每一步都是概率性的，所以需要 VCS、review lens、Field Guide 来补确定性。对你写 spec 的启示是：Cloud Agent 或 Notion 里给 agent 的说明越可执行，越接近 swarm 论文里「Composer worker 能 cheap 跟」的前提；模糊 epic 即使用最强模型，单 Agent 仍会 drift，更别说多 Agent。Cursor 未承诺把 swarm harness 产品化，读这篇是为了理解官方为何推 Planner/Worker 分层与 mixed-model 计费叙事，而不是在 IDE 里找 Swarm 开关。
若只记一句 takeaway：同样 SQL 套件通过率，模型混用可以接近 solo frontier 质量，但账单可差一个数量级；工程上更值得抄的是 failure mode 清单（split-brain、megafile、ossification）和 review lens 叠加，而不是 commit 速率本身。
Grok 4.5 旧 harness 在第二小时内 spiral 被 pause，新 harness 同模型四 hour 到约 80% 再爬满套件，说明 swarm 收益主要来自协调机制迭代，换模型 alone 救不了 split-brain。Fable 5 hybrid 虽 planner 单价更高，但 planning token 更少；Opus hybrid worker 段仅约 $411，对比全 GPT-5.5 worker 段 $9373，是文中最极端的成本对比，标注为 Cursor 实验数据。