前言¶
2026 年 7 月下旬，Cursor 在官方博客公布了升级版 Agent Swarm 架构的设计思路与基准测试结果。这套多 Agent 编排系统随 Cursor 3 的 Agent 运行时一同演进：前沿模型负责「拆任务、定方案」，廉价 Worker 模型负责「写代码、跑实现」。在「仅凭 SQLite 手册、从零用 Rust 重写数据库」的封闭实验中，新架构各配置最终均达到 sqllogictest 100% 通过率，Opus 4.8 规划 + Composer 2.5 执行的组合总成本约 \(1,339**，而全程使用 GPT-5.5 的单模型方案约 **\)10,565——差距接近 15 倍。
这组数据出自 Cursor 自研基准，并非生产环境实测；但它清晰指向一个正在被更多团队讨论的方向：多模型协作可能比「全程上最强模型」更划算。本文基于 Cursor 官方博客与公开报道，梳理架构要点、实验数据与落地时的注意点。
背景：从浏览器 Swarm 到 SQLite 复刻¶
Cursor 早在 2026 年初就用 Agent Swarm 做过「从零写浏览器」的概念验证：能跑通，但离可交付产品还有距离。团队随后把重点放在理解并工程化 Swarm 本身，并回到旧版 Swarm 曾卡住的难题——仅凭 835 页 SQLite 官方手册，在 Rust 中实现完整数据库引擎。
实验条件刻意收紧：
- 不提供 SQLite 源码、二进制、测试套件；
- 禁止联网；
- 评测使用 Swarm 事先不知道的 sqllogictest（数百万条 SQL 查询及标准答案）。
旧版 Swarm 在此任务上表现不佳：Grok 4.5 单模型配置在不到两小时内因协调失败被暂停；四小时后各旧配置通过率仅在 11%～77% 之间。新版 Swarm 在同样时间预算下，四小时后通过率落在 73%～85%，且所有新配置最终都达到 100%。
核心架构：Planner 与 Worker 的树形分工¶
Cursor 将大型任务自然建模为一棵任务树：根节点是总目标，递归分解为可执行的叶子节点。Swarm 中两类 Agent 各司其职：
- Planner（规划者）：运行前沿大模型，负责把目标拆成子任务、做架构与关键设计决策，不写实现代码。
- Worker（执行者）：运行更快、更便宜的模型（基准中多为 Composer 2.5），在叶子节点执行具体编码，不做规划。
这种分工针对的是长程 Agent 的上下文问题。单个 Agent 若既要「记住全局目标」又要「处理当前文件细节」，容易在任务树上漂移——要么盯细节丢大局，要么守大局做不好局部。Planner 上下文不被实现细节占满，Worker 则把全部上下文留给单一窄任务，Cursor 认为这比单纯堆并行度更能扩展 Swarm 能力。
Cursor 在博客中还类比了 Ronald Coase 关于企业层级的论述：协调成本增长快于工作量本身，因此系统会自然形成有边界的分工单元，而不是让所有人两两对话。
协调层：每秒千次提交与失败模式治理¶
高并发 Agent 写代码时，Git 等常规工具很快成为瓶颈。早期浏览器 Swarm 在 Git 上峰值约 1,000 commits/小时；新版自研 VCS 峰值约 1,000 commits/秒。所有变更经 VCS 流转，冲突在此层最先暴露，多种协调机制也内嵌其中。
Cursor 文档化了若干在「人类 tempo」下少见的失败模式及对策：
| 失败模式 | 简要说明 | 应对思路 |
|---|---|---|
| Split-brain | 多个 Planner 各自实现同一概念 | 规划者自己做设计决策，禁止子树重复决定同一问题 |
| Planner 争用 | 两个 Planner 在同一文件上反复拉锯 | 共享设计文档 + 编译期引用，Reconciler 合并冲突决策 |
| Merge 冲突 | Worker 不擅长合并，易覆盖或放弃 | 中立第三方 Agent 专门处理合并 |
| Megafiles | 热门文件膨胀导致 diff/merge 成本飙升 | Worker 可标记臃肿文件，外部 Agent 拆模块 |
| 僵化（Ossification） | Agent 不敢改核心代码 | 允许「有意破坏」并留注释，编译错误驱动下游同步 |
此外还有多层 Review Lenses（不同模型、不同输入范围的审查 Agent 叠加），以及 Agent 自维护的 Field Guide——带行数上限的知识文档，每次新 Agent 启动时自动注入，用于沉淀「意外发现」、缩短后续轨迹。
SQLite 基准：准确率、代码量与冲突对比¶
官方博客对比了四种模型组合（新旧 Harness 各跑一遍）：
- GPT-5.5 同时担任 Planner 与 Worker
- Grok 4.5 同时担任 Planner 与 Worker
- Opus 4.8 规划 + Composer 2.5 执行
- Fable 5 规划 + Composer 2.5 执行
新版 Harness 在每种组合下均优于旧版。 以 Grok 4.5 为例：旧版两小时内产生约 68,000 次提交（约为新版的 70 倍），但累积 70,000+ 次 merge 冲突后被暂停；新版全程冲突 不足 1,000 次。旧版 Rust 工程拆成 54 个 crate（含 3 套 SQL 包），新版稳定在 9 个 crate。
代码量差异同样显著（均为引擎代码行数）：
- Fable 5 组合：旧版 64,305 行 vs 新版 9,908 行（均最终 100% 通过）
- Opus 组合：旧版 19,013 行、97% vs 新版 4,645 行、100%——代码量减少约 85%，准确率反而更高
Opus 单跑产出的代码库已开源：github.com/cursor/minisqlite，读者可自行审阅质量。
模型经济学：Worker 占 Token，Planner 占账单¶
四种配置最终质量相近，总成本却从 \(1,339**（Opus + Composer 2.5）到 **\)10,565（GPT-5.5 单模型）不等，约 15 倍 差距。
Token 结构上，Worker 在各次运行中至少占 69%，多数超过 90%——执行阶段是 Token 大头。但美元分布不同：Planner 用的前沿模型单价高。以 Opus + Composer 2.5 为例，Opus 规划仅占少量 Token，却约占 总成本的三分之二；Composer Worker 处理绝大多数 Token，只占约 三分之一。
更直观的对比来自 GPT-5.5 单模型 run：Worker 侧 alone 约 $9,373；换用 Opus 规划 + Composer 2.5 执行时，整个 Worker 舰队约 $411，质量相当。这说明「规划阶段用贵模型、执行阶段用便宜模型」在 Cursor 的封闭实验里具备巨大降本空间。
Composer 2.5 是 Worker 侧的主力：基于 Moonshot Kimi K2.5 开源 checkpoint，经 Cursor 继续预训练与 RL；标准档定价 \(0.50/M 输入、\)2.50/M 输出（另有 Fast 档 \(3/\)15，交互默认）。Cursor 称其智能水平可比肩 Opus 4.7、GPT-5.5，该说法尚未经第三方公开基准独立验证。
需注意：Fable 5 规划虽比 Opus 少消耗规划 Token，但其 Worker 总 Token 数倍于 Opus 组合，整次 run 反而更贵——说明 Planner 质量会传导到 Worker 效率，不能只看规划单价。
与 Cursor 3 的关系¶
Cursor 3 于 2026 年 4 月 2 日发布，核心是 Agent 优先的统一工作区：Agents Window、本地/云端/SSH 多 Agent 并行、多仓库布局等。Agent Swarm 的 Planner/Worker 编排是这一 runtime 上的架构升级，而非单独售卖的模型产品；TPS 等媒体报道将其描述为 Cursor 3 多 Agent 能力的一部分。
对用户而言，界面层已支持并行管理 Agent 舰队；Swarm 论文级改进（自研 VCS、Field Guide、Review 栈）则主要体现于 Cursor 内部长跑任务与 Cloud Agent 场景。
对工程团队的启示与局限¶
可借鉴的思路：
- 任务路由：分解、架构、关键 trade-off 用强模型；明确子任务交给 Composer 2.5 等低成本模型——与业界「用最小够用模型完成任务」的趋势一致。
- Spec 即 Prompt：Swarm 把工程抽象层级从「文件/功能」抬到「规格说明」；835 页手册进、数据库出，稀缺资源是意图描述的质量。
- 协调与 VCS 同等重要：70,000 次冲突 vs 不足 1,000 次，说明多 Agent 的瓶颈往往在编排与合并，而非单点模型智商。
必须保留的审慎：
- 基准是合成、闭卷、Cursor 自评，公司有展示产品优势的商业动机。
- Cursor 博客亦引用研究：约 68% 的生产 AI Agent 在 10 步以内停滞——今日的成本红利多适用于可控实验，尚不能等同日常业务代码库。
- Composer 2.5 与前沿模型的对等说法、Fable 5 等部分模型细节，应以 Cursor 披露为准，待社区复现。
小结¶
Cursor 新版 Agent Swarm 用 Planner/Worker 树形分工、自研高吞吐 VCS 与多层审查，在 SQLite-to-Rust 基准上同时改善了准确率、代码体量与 merge 冲突。模型组合层面，Opus 4.8 + Composer 2.5 相对 GPT-5.5 单模型方案总成本降低约 15 倍，Worker 侧 alone 可从约 \(9,373** 压到约 **\)411。
这对正在评估 AI 编码 Agent 采购与架构的团队是一记清晰的信号：多模型编排可能和「换更强模型」同样重要。下一步 worth 关注的，是同类 Planner/Worker 策略在真实遗留代码库、合规与审计要求下的可复制性——以及 minisqlite 等开源产物能否经受社区独立审查。
