主页
「前沿模型只做规划,廉价模型负责执行」——Cursor 2026 年 7 月 20 日的研究长文用一场 SQLite 重写实验给出了迄今最有数字支撑的多智能体工程报告:同等质量,执行成本相差 22 倍。本文拆解它的机制、失效模式与可迁移的设计原则。
"Frontier models plan; cheap models execute." Cursor's July 20, 2026 research post backs this with the most data-rich multi-agent engineering report to date — a SQLite-rebuild experiment where identical quality came at a 22x spread in execution cost. This document unpacks the mechanism, the failure modes, and the transferable design principles.
它解决什么痛点:单个 Agent 跑长任务会「跑丢」——要么埋头细节忘了全局,要么盯着全局做不好细节;而把一群 Agent 简单并行起来,又会陷入合并冲突和重复劳动的泥潭(Cursor 旧系统重写 SQLite 时,两小时攒下 7 万+ 次合并冲突,被迫中止)。
The pain it solves: a single agent on a long task drifts — either it buries itself in detail and loses the big picture, or holds the big picture and botches the details. Naively parallelizing a crowd of agents instead drowns in merge conflicts and duplicated work (Cursor's old system racked up 70,000+ merge conflicts in two hours of the SQLite rebuild and had to be paused).
它的答案:把任务组织成一棵任务树,由两种角色分工:Planner(规划者)用最强的模型,只做拆解、设计决策和委派,从不写代码;Worker(执行者)用快而便宜的模型,只执行叶子任务,从不做规划。配上专为高并发自研的版本控制系统和一组「评审透镜」,新蜂群仅凭 835 页官方文档就用 Rust 重写了 SQLite,并最终 100% 通过 sqllogictest 测试套件。
Its answer: organize work as a task tree with two roles: planners on the strongest models do only decomposition, design decisions and delegation — they never touch code; workers on fast, cheap models only execute leaf tasks — they never plan. Add a purpose-built high-concurrency version control system and a set of "review lenses," and the new swarm rebuilt SQLite in Rust from nothing but its 835-page manual, ultimately passing 100% of the sqllogictest suite.
四种模型搭配,质量几乎相同,总成本从 $1,339(Opus 4.8 规划 + Composer 2.5 执行)到 $10,565(GPT-5.5 包办一切)不等;仅看执行侧,$411 对 $9,373,相差 22 倍。贵的智力只该花在少数真正需要它的时刻。
Four model mixes, near-identical quality, total costs from $1,339 (Opus 4.8 planning + Composer 2.5 executing) to $10,565 (GPT-5.5 doing everything); on the execution side alone, $411 vs. $9,373 — a 22x spread. Expensive intelligence should be spent only on the few moments that genuinely require it.
大任务的描述天然长成一棵树:根部是目标,递归拆分到基本工作单元。Cursor 蜂群的两种角色就绕着这棵树分工——这不是随意的架构选择,而是对「单 Agent 为什么会漂移」的直接回应。
Descriptions of large tasks naturally take the shape of a tree: a goal at the root, subdividing recursively into basic units of work. The swarm's two roles organize around that tree — not an arbitrary choice, but a direct answer to why single agents drift.
同一套设计已被 Cursor 用在多种任务上:从零造浏览器、解数学题、优化 GPU kernel、给开源软件找漏洞、提高自家代码库测试覆盖率、生成数十亿 token 的合成训练数据。
Cursor reports using the same design across diverse tasks: building a browser from scratch, solving math problems, optimizing GPU kernels, finding vulnerabilities in open-source software, raising test coverage on its own codebase, and generating billions of tokens of synthetic training data.
分层只是骨架,真正的工程量在协调层。Git 这类工具靠粗粒度锁做并发控制,对一名开发者够用,对数百个并发 Agent 完全不够——旧蜂群在 Git 上峰值约每小时 1000 次提交,新系统为此从零自研了版本控制系统(VCS),峰值达每秒约 1000 次提交。所有变更都过 VCS,冲突在这里最先显形,多项协调机制也直接内建其中。
Layering is just the skeleton; the real engineering lives in coordination. Tools like Git use coarse locks for concurrency — fine for one developer, unworkable for hundreds of concurrent agents. The old swarm peaked at ~1,000 commits per hour on Git; the new system ships a version control system built from scratch, peaking at ~1,000 commits per second. Every change passes through it, collisions surface there first, and several coordination mechanisms are implemented directly inside it.
在这种节奏下,Cursor 观察到五种人类团队很少遇到的失效模式,并给出了各自的修法:
At that tempo, Cursor observed five failure modes human teams rarely hit, each with its own fix:
长时程 + 多智能体意味着错误会累积,蜂群需要在小错变成地基之前自我纠偏。Cursor 试验了多种「评审透镜」:有的评审 Agent 看 Worker 全程记录,有的只看产出,有的只看代码库,还让不同模型、不同「性格」的评审并存。结论:没有单一透镜能抓住一切,但彼此不相关的透镜可以叠加——就像自动驾驶靠多个不完美组件叠出超人可靠性。评审算力回报很高,因为评审远比它审计的工作便宜。
Long-running plus multi-agent means errors accumulate; the swarm must self-correct before small mistakes become foundational. Cursor tried many "review lenses": reviewers seeing the worker's full transcript, only its output, or nothing but the codebase — across different models and personalities. Conclusion: no single lens catches everything, but decorrelated lenses stack — the way self-driving systems reach above-human reliability without any single perfect component. Review compute is high-return, since review is much cheaper than the work it audits.
另一项实验借鉴了蚁群的共识主动性(stigmergy)——通过改造环境来协调彼此:一个完全由 Agent 拥有的「Field Guide」文件夹,其 index.md 自动注入每个新启动的 Agent,由 Agent 自己决定什么值得写进去(唯一约束是行数预算)。逻辑很朴素:模型权重是冻结的,恰恰是「意外遭遇」值得记录,好让下一个 Agent 的轨迹更短。
Another experiment borrows stigmergy from ant colonies — coordinating by shaping the environment: a "Field Guide" folder owned entirely by the agents, whose index.md is auto-injected into every agent at start; the agents curate it themselves under a line budget. The logic is plain: model weights are frozen, so it's precisely the surprise encounters worth capturing so the next agent's trajectory is shorter.
考题:仅凭 835 页 SQLite 官方手册,用 Rust 从零实现整个数据库——源码、测试套件、SQLite 程序、互联网,一律不给。评分用 SQLite 项目自己的 sqllogictest(数百万条已知正确答案的查询),蜂群不知道这套测试的存在;每轮结束后 Cursor 人工审查代码与过程,排查作弊与偷工。
The exam: implement the entire database in Rust from nothing but SQLite's 835-page manual — no source, no test suites, no SQLite binary, no internet. Grading used the SQLite project's own sqllogictest (millions of queries with known answers); the swarm was never told the suite existed, and Cursor manually reviewed code and runs afterward for cheating and shortcuts.
结构性指标同样说明问题:旧系统(Grok 4.5)前两小时狂产 68,000 次提交——约为新系统节奏的 70 倍,但多数是空转(冲突、争抢、翻烧饼);包结构上,旧系统蔓生出 54 个 Rust crate、其中 3 个都是 SQL 包(裂脑的直接证据),新系统早早定型 9 个 crate 后再未增加。
Structural metrics tell the same story: the old system (Grok 4.5) churned out 68,000 commits in its first two hours — about 70x the new system's pace, mostly busywork (thrash, contention, churn). In package structure, the old run sprawled to 54 Rust crates including three separate SQL packages (split-brain in the flesh); the new run settled on nine crates early and never added another.
这是厂商自述的内部实验:评分虽用外部测试套件,但实验设计、人工审查和数字均出自 Cursor 一方;曲线形状受 Agent 自选策略影响(「趋势比某时刻的确切分数更重要」是 Cursor 自己的提醒)。Opus 4.8 单跑产出的代码库已公开(github.com/cursor/minisqlite),可自行检验。
This is a vendor-reported internal experiment: the grader is an external suite, but design, review, and numbers all come from Cursor. Curve shapes reflect agents' self-chosen strategies ("trends matter more than exact scores at exact moments" is Cursor's own caveat). The solo Opus 4.8 codebase is public at github.com/cursor/minisqlite for independent inspection.
四种配置质量趋同,成本天差地别。token 的分布很一致——Worker 至少吞掉 69% 的 token(多数配置超 90%);但钱的分布不同,因为 Planner 的 token 更贵:在 Opus 4.8 + Composer 2.5 组合里,Opus 产出的 token 占比很小,却占了约三分之二的花费。
Four configurations, converging quality, wildly different costs. Token structure was consistent — workers carried at least 69% of tokens (over 90% in most runs); but dollars split differently because planner tokens cost more: in the Opus 4.8 + Composer 2.5 mix, the planner produced a small fraction of tokens yet roughly two-thirds of the cost.
Fable 5 做 Planner 时,规划账单反而比 Opus 4.8 略低(单价约两倍,但规划 token 少得多)——然而它带的 Worker 消耗了数倍 token,整体反而明显更贵。规划的质量不只体现在规划本身的开销,更体现在它给执行端省了多少弯路;这两者未必同向。
With Fable 5 as planner, the planning bill came out slightly below Opus 4.8's (about twice the per-token price, far fewer planning tokens) — yet its workers burned several times as many tokens, making the run substantially more expensive overall. Planning quality shows up not in the planner's own bill but in how many detours it saves the executors — and the two don't necessarily move together.
给自己搭 Agent 系统的读者,可直接带走的设计原则:
If you're building your own agent systems, the portable principles:
① 单源厂商报告:数字未经独立复现,且 Cursor 自家销售廉价模型(Composer)与该结论存在利益一致性。② 任务选择偏向:SQLite 重写是「规格明确 + 验证完美 + 高度可并行」的理想蜂群任务;Google–MIT 研究提示,强耦合任务上多智能体的协调开销可能吃掉收益。③ 模型敏感性真实存在:Cursor 自己就因 GPT-5.6 Sol 对措辞过敏、出现「失控螺旋」而弃用之——换模型不是免费的。
① Single-source vendor report: figures aren't independently reproduced, and Cursor sells a cheap model (Composer) aligned with the conclusion. ② Task-selection bias: the SQLite rebuild is an ideal swarm task — precise spec, perfect verifier, highly parallel; the Google–MIT study warns coordination overhead can erase gains on tightly coupled tasks. ③ Model sensitivity is real: Cursor itself dropped GPT-5.6 Sol after "runaway spirals" from its sensitivity to emphatic wording — swapping models isn't free.
蜂群的可扩展性来自上下文效率而非并行本身;成本优势来自把前沿智力限定在拆解与决策的少数时刻;而这一切能立住的前提,是验证器和一整层不输于 Agent 本身的协调工程。
Swarm scalability comes from context efficiency, not parallelism itself; the cost advantage comes from confining frontier intelligence to the few moments of decomposition and decision; and both stand only on verifiers plus a coordination layer engineered as seriously as the agents themselves.