前言¶
2026 年 7 月，Cursor（Anysphere）发布了一项名为 Agent Swarm 的研究实验：让多 Agent 蜂群仅凭 835 页 SQLite 官方文档，在 Rust 中从零重建 SQLite 数据库引擎——不提供源码、不提供测试套件、不提供 SQLite 二进制、也不允许联网。最终，新架构下的多种模型组合均通过了 sqllogictest 全部测试；其中 Opus 4.8 负责规划、Composer 2.5 负责执行 的混合方案，总成本约 1339 美元，而 GPT-5.5 单模型包办规划与执行 的方案约 10565 美元。质量相近，成本差了一个数量级。
这不是「模型又变强了」的简单叙事，而是 Agent 编排经济学 的一次量化验证：大任务里真正需要前沿模型的地方，可能只占很小一块；一旦规划层把歧义消解成明确指令，廉价模型足以承担绝大部分执行工作。本文基于 Cursor 官方博客、开源仓库 minisqlite 及 Hacker News 讨论，梳理实验设计与结论，供正在评估多 Agent 方案的开发者参考。
实验在测什么¶
Cursor 把这次 SQLite 重建当作 新旧蜂群 harness 的对照实验。旧版蜂群曾在类似任务上陷入合并冲突与重复建设；新版则叠加了自研版本控制系统、冲突仲裁、设计文档对齐、文件拆分、多层 Review 等机制。
任务约束如下：
- 输入：835 页 SQLite 手册（ prose 规格）。
- 输出：Rust 实现的完整数据库引擎。
- 禁止：SQLite 源码、官方测试套件、sqlite3 二进制、互联网访问。
- 评测：实验方在 Agent 不知情的情况下，用 sqllogictest 打分——这是 SQLite 项目用于跨引擎一致性验证的套件，包含数百万条 SQL 及已知正确答案，得分即通过比例。
实验结束后，Cursor 还人工审查代码与运行过程，排查作弊、走捷径、以及「只修测试覆盖区域」的局部优化。
Planner 与 Worker：树形分解¶
Cursor 将大任务自然建模为一棵 任务树：根节点是总目标，递归拆成可执行子任务。蜂群只有两个核心角色：
- Planner（规划者）：通常由前沿模型驱动，负责分解目标、做架构与设计决策、向下委派。
- Worker（执行者）：通常由更快、更便宜的模型驱动，负责在窄范围内实现具体代码。
Planner 不写实现细节，Worker 不做全局规划。Cursor 认为，这比固定拓扑的编排系统更灵活——蜂群形状随任务复杂度伸缩，上下文效率 才是规模化的关键，而不只是并行度。
类比经济学里的科斯定理：协调成本增长快于工作量本身，所以组织会分层，而不是让所有人两两直接沟通。单 Agent 长时运行容易「漂移」——要么盯住眼前细节丢全局，要么抱着大图做不好局部；分层则让各层上下文各就其位。
新 harness 解决了哪些「千次提交/秒」的故障¶
早期浏览器蜂群实验峰值约 1000 commits/小时；新系统峰值约 1000 commits/秒。Git 级别的粗粒度锁已无法支撑，Cursor 为此自研 VCS，并在其中实现协调逻辑。
官方博客重点提到几类人类团队不常遇见、但高并发 Agent 会放大的故障：
- Split-brain 设计：两个 Planner 各自实现同一概念。对策：Planner 必须亲自做设计决策，并保证委派子树不重复决策同一问题。
- Planner 争用：两个 Planner 在同一文件上来回改。对策：共享设计文档 + 代码中 compile-checked 引用；冲突时由 reconciler 合并文档并向下传播。
- 合并冲突：Worker 不擅长合并，容易覆盖或放弃。对策：中立第三方 Agent 专门仲裁冲突。
- Megafiles：热门文件越写越大，diff/merge 成本爆炸。对策：Worker 可标记臃肿文件，外部 Agent 负责拆分模块。
- Ossification（僵化）：Agent 学到「别动核心代码」。对策：允许有理由的越界修改，编译错误驱动下游 Agent 跟进调整。
此外还有 Review lenses（多种审查视角叠加）和 Field Guide（Agent 自维护的共享上下文索引），用于长时运行中抑制错误累积。
SQLite 实验结果¶
Cursor 测试了四种模型组合（新旧 harness 对照，相同时间预算）：
| 配置 | 角色 |
|---|---|
| GPT-5.5 | Planner + Worker 均为 GPT-5.5 |
| Grok 4.5 | Planner + Worker 均为 Grok 4.5 |
| Opus 4.8 + Composer 2.5 | 前沿规划 + 高效执行 |
| Fable 5 + Composer 2.5 | 次一线规划 + 高效执行 |
新 harness 在每一种组合下都优于旧 harness。 以 Grok 4.5 为例：新系统在 4 小时内达到约 80% 通过率，旧系统不到 2 小时就因失控被暂停。4 小时截止时，新系统得分在 73%–85% 区间，旧系统在 11%–77% 区间；新系统的每一种配置最终都达到了 sqllogictest 100% 通过率。
行为差异往往比分数更说明问题。旧 Grok 运行 2 小时内产生约 68000 次提交，约为新系统的 70 倍，但伴随 70000+ 次合并冲突；新系统全程 4 小时冲突不足 1000 次。旧系统最热单文件被 1173 个 Agent 触碰、累计 7771 次冲突；新系统最热文件仅 47 次。包结构上，旧系统膨胀到 54 个 crate（含 3 套 SQL 包），新系统早期稳定在 9 个 crate。
代码体量同样悬殊：Fable 5 配置下，旧系统引擎代码约 64305 行才跑满测试，新系统约 9908 行；Opus 配置下，旧 harness 约 19013 行得 97%，新 harness 约 4645 行得 100%。
1339 美元 vs 10565 美元：模型经济学¶
官方给出的总成本区间：Opus 4.8 混合方案约 1339 美元，GPT-5.5 单模型方案约 10565 美元。 各次运行的 token 结构一致——Worker 至少承担 69% token，多数超过 90%；但 美元分布与 token 分布并不重合，因为 Planner token 单价更高。
在 Opus 4.8 + Composer 2.5 组合中：
- Opus 作为 Planner：token 占比很小，却约占 总成本的三分之二。
- Composer 作为 Worker：承担绝大多数 token，却只占约 三分之一成本。
更直观的对比：
- GPT-5.5 单模型方案中，仅 Worker 部分 就花了 9373 美元。
- Opus 规划 + Composer 执行的方案中，整个 Worker 舰队 只花了 411 美元。
Cursor 的结论是：大任务里只有少数时刻真正需要前沿智能——初始分解、设计决策、关键权衡。一旦 Planner 把模糊目标压成明确指令，廉价模型按 spec 执行即可。两种混合方案（Fable 5 与 Opus 4.8 各配 Composer 2.5）质量相近，但 Fable 规划 token 更少、Worker token 却多几倍，整体反而更贵——说明 Planner 选型 同样影响经济学，不能只看单价。
minisqlite：蜂群的产物长什么样¶
实验产出的 minisqlite 已开源：github.com/cursor/minisqlite（Anysphere 组织下同名仓库）。README 描述其为 SQLite 的 Rust 重实现，覆盖 SQL 方言、查询规划与执行、事务、存储引擎及官方 on-disk 格式；可读写 sqlite3 生成的数据库文件。
公开 API 刻意极简：Connection::{open, open_in_memory, execute, query}，约 20 万行 Rust、14 个 crate、5650 个测试，库代码无 unsafe。Cursor 注明尚未做深度人工审计，欢迎社区审阅。
仓库创建时间为 2026-07-17，早于博客广泛传播，说明代码与文章是同一实验链条的公开延续。
「规格即 Prompt」：对开发者的启示¶
Cursor 将能力演进概括为抽象层级的抬升：补全 → 代码块 → 文件/功能 → Agent 蜂群下的 spec（规格）。这次实验的稀缺输入不是算力，而是 835 页 prose 规格；蜂群像一台 概率性编译器，把意图逐级 lower 成可执行工作，每一步都可能偏离，于是需要 VCS、Review、设计文档等工程化约束来收窄 gap。
对日常工程实践的启示可以概括为三点：
- 分层模型是成本杠杆，不是噱头。 若你的任务可拆成「少量关键决策 + 大量确定性实现」，Planner/Worker 混合值得纳入成本模型，而非默认全链路用最贵模型。
- 编排质量往往大于模型分数。 同一 Grok 4.5，新旧 harness 表现天差地别；合并冲突、crate 膨胀、代码行数说明 协调机制 才是规模化瓶颈。
- 规格与测试仍是锚点。 Agent 未被告知 sqllogictest 的存在，却仍需通过外部一致性验证；无论蜂群多复杂，可并行、可判定的验收标准 仍是信任基础。
Hacker News 上对此实验的讨论（约 278 points、143 条评论）也呈现两极：一方认为这预示「规格驱动 + 廉价 Worker 集群」的未来；另一方质疑 SQLite 语义已大量存在于模型权重中，「仅凭文档重建」是否等价于从零构建。这些争议不影响 成本结构 这一核心数据，但提醒读者：实验验证的是 harness + 模型经济学，而非「AI 已无需人类数据库专家」。
结语¶
Cursor Agent Swarm 的 SQLite 实验，用可复现的基准（sqllogictest）和公开代码（minisqlite），把 「规划用强模型、执行用弱模型」 从经验法则变成了带美元数字的工程命题。1339 美元与 10565 美元的差距，主要来自 Worker 舰队该用谁、以及 harness 能否让廉价模型 稳定执行 而非 无效内卷。
若你正在设计多 Agent 流水线，不妨先问两个问题：哪些步骤真的需要 frontier 判断？执行层的验收标准能否像 sqllogictest 一样清晰、可并行？答案将比「再换一个更强的单模型」更接近真实的 Agent 经济学。
参考来源
- Cursor 官方博客：Agent swarms and the new model economics
- 开源仓库：cursor/minisqlite
- Hacker News 讨论：Agent swarms and the new model economics
