Cursor 让便宜模型承担大部分编码工作

关键信息

Cursor 认为，规划者代理会把目标递归拆成更小的任务，而执行者代理则使用更快、更便宜的模型完成这些任务；这种分工有助于缓解上下文管理问题。该基准测试隐藏了源代码、测试、SQLite 二进制文件和互联网访问权限，并使用了包含数百万条 SQL 查询及已知答案的 sqllogictest。

资讯摘要

Cursor 将新版代理群和旧版系统做了对比，要求它们仅根据文档重建 Rust 版 SQLite。测试环境被刻意限制：两套系统都看不到源代码、测试套件、SQLite 二进制文件，也不能访问互联网。Cursor 表示，新系统在所有测试配置中都成功了，并在基准测试上达到 100%。相比之下，旧版代理群陷入了大量合并冲突，产生了许多无效工作。Cursor 认为，架构上的关键变化是把代理分成规划者和执行者两类：规划者用更强的前沿模型递归拆解任务，执行者用更快、更便宜的模型完成具体编码。

公司声称，这样可以减轻长任务中的上下文负担，避免代理在长时间运行后偏离目标。Cursor 还提到，旧系统虽然也有执行者、裁判和整合器，但整合器最终成了新的瓶颈而不是解决方案。新版系统的写入速度更高，以至于 Git 无法承受这种负载，因此 Cursor 为代理专门构建了自己的版本控制方式。为减少协调问题，代理会把决策写入共享设计文档，并在编译时把代码与对应文档关联起来；当出现冲突时，会由中立代理来解决，文件过大时还会被拆分成更小的模块。

资讯正文

Cursor 的 agent 群集表明，当前沿模型负责规划工作时，更便宜的模型就能处理大部分编码任务

Cursor 让升级后的 agent 群集与前一代系统正面较量：它要求两者都仅凭文档、在没有源代码和互联网访问的情况下，用 Rust 重建 SQLite。新系统的每一种配置都在测试套件上达到了 100%，而旧的群集则被自身的合并冲突拖住了脚步。

在 Cursor，agent 编队已经从研究项目变成了核心产品。借助 Cursor 3，开发者可以并行运行整个 AI agent 编队。Cursor 背后的公司 Anysphere 最近以 600 亿美元被埃隆·马斯克的 SpaceX 收购。

该系统将 agent 分为两种角色：使用强大前沿模型的规划 agent 递归地把一个目标拆分成更小的任务；使用更快、更便宜模型的执行 agent 完成这些任务。其结果是一个会随着工作推进而自适应的任务树。

Cursor 表示，这种角色拆分主要解决的是上下文问题。单个 agent 必须在遍历整棵树的同时，既记住总体目标，又记住当前任务。这也有助于解释为什么 agent 在长时间任务中会跑偏。在 Cursor 的群集里，规划者不写代码，执行者不规划。

Git 无法处理每秒 1,000 次提交

Cursor 早期的浏览器群集在 Git 上每小时大约能完成 1,000 次提交。它使用了执行 agent、一个裁判 agent，以及一个负责解决冲突的集成器。结果，集成器最终制造出的瓶颈比它消除的还多。

新的群集达到了每秒 1,000 次提交，因此 Cursor 构建了自己的版本控制系统，因为以这种速度工作的 agent 会产生人类团队从未遇到过的故障模式。

Cursor 所称的“split-brain design”中，两个规划者会在不知情的情况下在不同位置构建同一个想法，并以不同方式实现它。当规划者彼此知晓并通过相互竞争的编辑互相阻塞时，争用就更难管理了。

Cursor 让 agent 将决策记录在共享设计文档中。与某项决策相关的代码，会通过一个在编译时检查的引用链接回该文档。

当出现合并冲突时，一个中立的 agent 会介入并解决它们。执行者会把臃肿的文件标记出来，交给外部 agent 将其拆分为更小的模块。由于 agent 已经学会在与人类协作、处理现有代码库时不要触碰核心代码，Cursor 于是允许它们有意把事情弄坏。agent 可以在其分配区域之外修补代码，而编译器会将这一变更贯穿整个系统。

多种审查角度与一份自我维护的操作手册

Cursor 测试了几种审查方法。一个审查者拿到的是执行 agent 的完整对话记录，另一个只看到输出，第三个只看到代码库。没有任何单一视角能发现所有问题，但彼此不相关的视角组合起来，可靠性更高。

Cursor 还测试了一个“field guide”，即由 agent 自行维护、并设有固定行数限制的知识文件夹。每个 agent 在启动时都会接收其中内容。由于模型权重是冻结的，因此记录那些出人意料的发现是值得的，这样后续的 agent 就可以走捷径。

Cursor 给这个 swarm 提供了 835 页的 SQLite 手册，并让它构建一个 Rust 实现。源代码、测试套件、SQLite 二进制文件以及互联网访问都被禁止提供。基准测试是 sqllogictest，这是一个包含数百万条 SQL 查询和已知答案的测试套件。这个 swarm 并不知道它的存在。

旧 swarm 产生的工作量超过了它完成的工作量

Grok 4.5 的运行结果说明了为什么旧系统落后。旧 swarm 在两小时内产生了 68,000 次提交，大约是新系统的 70 倍。大部分活动都是无效工作。旧运行累计出现了超过 70,000 次合并冲突，而新运行在整个测试期间始终保持在 1,000 次以下。

旧运行中争议最大的文件记录了 7,771 次冲突，涉及 1,173 个 agent；相比之下，新运行只有 47 次。相同的“双脑”问题也出现在包结构上。旧运行把项目拆成了 54 个 Rust crate，并分成了三个独立的 SQL 包。新运行则很早就稳定在 9 个 crate。

在 Fable 5 配置中，旧 swarm 需要 64,305 行引擎代码，而新系统只需要 9,908 行。在 Opus 配置中，旧系统生成了 19,013 行代码，得分为 97%。新系统则以 4,645 行代码达到了 100%。

更便宜的 worker 模型带来了最大的节省

总成本从采用 Opus 混合方案时的 1,339 美元，到单独运行 GPT-5.5 时的 10,565 美元不等。在每一次运行中，worker 至少占 token 总数的 69%，通常超过 90%。但由于 planner token 的成本更高，费用结构看起来不同。在 Opus 混合方案中，planner 只产生了很小一部分 token，却占了总账单的三分之二。

Cursor 认为，大型任务中只有少数部分需要前沿模型级别的智能，包括任务拆解和关键设计决策。一旦前沿级 planner 解决了歧义，更便宜的模型就可以按照它的计划执行，不过这些混合运行也表明，planner 的质量仍然很重要。Fable 5 的 planner 使用的规划 token 比 Opus 更少，但它的 worker 需要更多 token 才能完成任务，因此 Fable 运行的总体成本更高。

Cursor 将 swarm 描述为一种概率编译器，它会一步一步把意图翻译成可执行的工作。公司表示，在这次实验中，准确描述这种意图是主要限制。Cursor 已将 Opus 单独运行时的代码库以 minisqlite 的名义发布在 GitHub 上。

像这样的运行如今已不再局限于实验室试验。Fable 5 的预发布版本处理了 Bun 从 Zig 重写为 Rust 的大部分工作。64 个实例在 11 天内编写了超过 100 万行代码，花费约 16.5 万美元。生产环境中的使用情况仍然不同。2025 年底发表的一项研究发现，在生产中使用的 agent 中，有 68% 在人类介入之前最多只完成了十个步骤。对 47% 的 agent 来说，这一上限还不到五步。

来源与参考

1. 原始链接
2. Cursor's agent swarm suggests cheaper models can handle most coding when frontier models plan the work