Cursor 测试新型 AI 智能体集群：规划者+执行者分工，4小时通过80% SQL测试

今年早些时候，我们开展了一系列实验，测试将智能体扩展至协同完成一个目标时的能力极限。我们的假设是，这将解锁一个全新的任务规模与复杂度层级。

旗舰项目是一个长期运行的集群从零开始构建一个网页浏览器。它作为概念验证取得了成功，但远未达到精致软件的水准。

那项工作是刻意以经验主义方式进行的。我们从一张白纸开始，通过爬山法逐步逼近一个稳定、有效的系统。自那以后，我们的目标一直是充分理解智能体集群，以便有意识地对其进行工程设计。

为了检验这一进展，我们回到了旧集群曾经苦苦挣扎的一项任务：用 Rust 从零开始构建 SQLite，除了其文档之外不借助任何其他东西。

我们的初步结果令人鼓舞。我们在同一任务上运行了新旧两个集群，使用相同的模型和相同的时间预算，并测量了各自能通过多少留出的 SQL 测试套件。

新集群在每一种模型配置下都表现更好。使用 Grok 4.5 时，它在四小时内达到了 80%，而旧集群则陷入失控，不得不在第二小时之前就被暂停。

我们还改变了由哪些模型承担哪些工作。在一些运行中，一个模型包揽了所有工作，而在另一些运行中，一个前沿模型负责规划，一个快速、低成本的模型负责执行。每一种组合都产出了相似的质量，但成本差异极大。¹

树与叶

大型任务的描述天然呈现树状结构，根节点是一个目标，递归地细分为基本的工作单元。我们的集群有两种角色，二者都围绕这同一套树状分解来组织：

• 规划者智能体由最聪明的模型驱动，将一个目标拆分成若干部分并分派出去。
• 工作者智能体通常由更快、更便宜的模型驱动，负责执行这些拆分出的部分。

该设计是更 rigid 编排系统的超集。它不会对问题强加固定拓扑，而是让 swarm 的形态生长以覆盖问题的轮廓，并让计算与上下文随任务复杂度成比例扩展。

我们认为，这正是该设计能够泛化到诸如构建浏览器、求解数学问题以及优化 GPU kernel等多样化任务的原因。我们也在内部用它来发现并修复开源软件中的漏洞、提升我们自己代码库的测试覆盖率，以及生成数十亿 token 的合成训练数据。

树为记忆带来了什么

当单个智能体承担一项完整任务时，它必须亲自走完整棵树，下降到每一个叶子节点，同时在整个过程中把其祖先、当前位置以及更宏观的目标都保持在上下文中。

我们认为，这解释了长时间运行的单智能体为何会偏离方向。它们要么专注于眼前的工作而失去对全局的把握，要么紧握全局而在具体环节上表现更差。

在集群中，规划者从不实现，因此其上下文永远不会被低层细节填满；而工作者从不规划，因此可以将全部上下文用于一项狭窄的工作。

我们怀疑，智能体集群的扩展能力更多来自这种上下文效率，而非并行本身。这种效率在集群的任何规模下都存在，这正是为什么这种分解即使在中等规模的任务上也能提升智能体表现。

这种结构在其他地方也有回响。经济学家罗纳德·科斯在追问企业为何存在时，论证道，协调成本的增长快于工作本身，因此组织会沉淀为层层受限的单元，而不是让每个人都与所有人直接沟通。

面向智能体的版本控制系统

在此前一篇关于集群的文章中，我们提到 Git 和 Cargo 等工具依赖粗粒度锁来实现并发控制。这对单个开发者来说没问题，但对于数百个并发智能体所产生的工作量而言则行不通。

今年早些时候的浏览器集群在 Git 上每小时峰值约为 1,000 次提交。新系统的峰值约为每秒 1,000 次提交。

为了支撑这样的活动速率，我们从零构建了一套全新的版本控制系统（VCS）。吞吐量并非我们掌控这一层的唯一原因。系统中的每一次变更都会经过这套 VCS，因此它正是冲突最先显现的地方，而下一节中提到的若干协调机制，也直接在这套系统内部实现。

每秒 1,000 次提交下的失效模式

人类工程团队拥有标准的协调机制，比如代码审查、归属权、站会和合并队列。这些系统以人类的节奏运转，但在智能体集群的提交速率下，我们会看到人类团队通常不会遇到的失效模式。

脑裂式设计

两个规划者彼此不知情，却在代码库的不同位置以不同方式实现了同一个概念。

我们通过提示词解决了这个问题。规划者自行做出设计决策，而不是将其下放，并且我们要求他们确保任意两个被下放的子树不会对同一个问题做出相同的决定。

规划者之间的争用

一种更棘手的争用形式是，两个规划者彼此知晓，并围绕相同的文件通过来回变更展开争斗。

问题在于这是对现实的两种不同图景，而合并工具无法修复分歧。于是，我们让智能体在共享设计文档中记录决策。依赖某项决策的代码会携带一个经过编译检查的引用，指回其对应的文档。当规划者们在不知情的情况下相互矛盾时，一个协调器会合并这些文档，引用则将解决方案向下游传播。

合并冲突

在集群内部，智能体会不断在同一批文件上发生碰撞。为了解决碰撞，它们必须停下来，吸收另一个智能体的上下文，并围绕它进行合并。工作型智能体并不擅长这一点，实际上，它们要么覆盖另一方的改动，要么放弃自己的改动。

为了解决这个问题，我们创建了一个系统，由中立的第三方智能体介入合并冲突，并代表所有各方解决冲突。它唯一的目标就是保持公正和高效，类似于工程团队中合并队列的运作方式。

巨型文件

有些文件是智能体特别喜欢工作的地方。每个智能体可能只添加少量代码，而没有任何单个智能体负责让这些文件保持精简。

这些“巨型文件”会拖垮一切。它们的传输、差异比对和合并成本都很高，并且会成为持续碰撞的发生地。

为了解决这个问题，我们为工作型智能体提供了一种标记臃肿文件的方式。一旦被标记，我们就会阻止新的提交，并由一个外部智能体将这个过度膨胀的文件分解为更小的模块。

僵化

智能体已经从与人类协作处理现有代码库的过程中学会了一件事：即便核心代码需要改动，也不要去碰它。

为了解决这个问题，我们授权有意的破坏性变更。如果某个智能体判断某项核心改动值得去做，它可以在自身职责范围之外提交一个聚焦的补丁，并留下注释说明这样做的原因。

编译器会将这一变更传导至系统的其余部分，所有依赖旧设计的部分都会构建失败。每个遇到这类错误的智能体都会找到那条注释，阅读其中的推理过程，并更新自己负责的那部分工作以保持一致。

审查视角

在一个既长时间运行又多智能体的系统中，错误会不断累积，而智能体集群需要一种在微小失误变成根基性问题之前自我纠正的方式。

我们尝试了许多种审查视角，比如给审查智能体提供工作智能体的完整对话记录，或者只提供其输出，又或者只提供代码库而不给其他任何内容。我们还尝试了让审查者运行在不同的模型上，这些模型具有不同的训练背景和不同的个性。

没有任何单一视角能捕捉到所有问题，但去相关化的视角可以叠加，就像自动驾驶系统无需任何单一完美组件就能达到超越人类的可靠性一样。花在审查上的算力回报很高，因为审查远比它所审计的工作便宜。我们怀疑，这套叠加式审查系统是这些运行能够持续保持高质量的主要贡献因素。

让智能体塑造环境

共识主动性（Stigmergy）是蚂蚁和白蚁等群体生物无需直接沟通即可协调行动的机制。它们塑造环境，而环境又塑造下一个生物体。

在早期的运行中，我们编码了一些规则，比如“保持记录”和“记录决策”，因为它们看起来显然是有益的。回想起来，这些规则让智能体将知识固化下来，供未来的自己和队友使用。

我们通过一项名为“Field Guide”的自撰共享上下文实验将这一理念进一步推进。它是一个完全由智能体拥有的文件夹，其 index.md 会在每个智能体启动时自动注入。智能体的职责是策划指南的内容，它们唯一的约束是行数预算。

该指南的底层逻辑是：模型权重是冻结的，因此恰恰是那些意外遭遇值得被记录下来，以便下一个智能体的轨迹更短。

《实地指南》是一项早期实验，结果颇具前景。我们预计，在智能体并未完全掌控的代码库上，其收益会更大。训练模型为其后继者编写内容——记录得越好，奖励越高——是一个有趣的后续研究方向。

SQLite 实验

我们让新版本的集群（配备了上文描述的所有改进）用 Rust 实现整本 835 页的 SQLite 手册。我们扣留了源代码、测试套件、SQLite 二进制文件，并切断了互联网访问。

为了衡量进展，我们以 sqllogictest 作为评分标准，这是 SQLite 项目构建的一个测试套件，用于检验不同数据库引擎对相同查询是否返回相同结果。它包含数百万条已知正确答案的查询，评分就是集群的数据库答对的比例。进展表现为一次运行过程中不断上升的曲线。

集群从未被告知这个测试套件的存在。每次运行后，我们都会人工审查代码和运行过程本身，检查是否存在作弊和走捷径的情况，并确认系统是均衡地构建出来的，而不是只在测试所关注的地方构建。

在阅读这些曲线时，请记住智能体是自己选择策略的。有些智能体先构建广泛的基础，数小时内得分都很低，随后才出现迟来的飙升；而另一些则深入某一个领域，早早得分，然后在补齐其余部分时进入平台期。趋势比某一时刻的确切分数更重要。

不同模型组合的结果

我们测试了四种兼顾能力与成本的配置：

1. GPT-5.5 同时担任规划者和执行者。 全程使用一个强大的前沿模型。²
2. Grok 4.5 同时作为规划者和执行者。 我们高性价比的前沿模型，作为对照点。
3. Opus 4.8 作为规划者，Composer 2.5 作为执行者。 前沿判断力搭配高效执行。
4. Fable 5 作为规划者，Composer 2.5 作为执行者。 用以观察更高一档的规划者会让这种混合方案更值得还是更不值得。

新的测试框架在每一种组合中都优于旧的。

Fable 5 混合方案在第一个小时内就通过了约三分之二的测试套件。到四小时的截止时间，新的运行结果落在 73% 到 85% 之间，而旧的运行结果则在 11% 到 77% 之间。

旧的 Grok 4.5 运行在其两小时节点之前就被暂停了（详见下文）。每一个新配置最终都通过了 100% 的测试套件。

未来我们希望运行规划者-执行者组合的完整 N×N 矩阵。在本轮中，真正重要的比较是测试框架版本之间的比较，而行为差异最终远比分数差异所显示的要大得多。

深入剖析各次运行

从最简单的活动度量入手，我们可以看到 Grok 4.5 在旧测试框架与新测试框架下提交速率的差异。旧的那次运行在头两个小时内产生了 68,000 次提交，大约是新的运行速度的 70 倍。

一种解读是它效率更高。另一种解读是，这些提交大多是无效忙碌（反复折腾、争抢、频繁改动）。

合并冲突的数据支持后一种解读。旧运行在我们暂停它之前累积了超过 70,000 次冲突，而且是在加速而非趋于稳定，而新运行在整整四个小时内记录的冲突不到一千次。

冲突集中在文件增长最大的地方。在旧运行中，最大的文件在整个运行过程中持续增长，其中单个最热门的文件收集了 7,771 次冲突，被 1,173 个不同的智能体触碰过。而在新运行中，整个代码库中争用最激烈的文件只出现了 47 次。

旧集群最大的协调失败——脑裂，即规划者彼此重复对方的工作——体现在包结构上。Rust 代码被组织成称为 crate 的包，而在这样一个项目中，每个 crate 大致对应一个主要组件。

旧运行膨胀到了 54 个 crate，其中包括三个独立的 SQL 包。新运行很早就稳定在九个 crate，并且再也没有增加过。

所有这些都体现在最终的代码库中。在 Fable 5 组合中，旧集群和新集群最终都通过了完整测试套件，但旧集群需要 64,305 行引擎代码，而新集群只用了 9,908 行就完成了。Opus 组合呈现出相同的形态：在旧框架下为 19,013 行、评分 97%，而在新框架下为 4,645 行、评分 100%。

模型经济学

我们在开头说过，每种模型组合都产出了相近的质量，而成本却相差悬殊，从 Opus 4.8 混合方案的 $1,339 到单独使用 GPT-5.5 的 $10,565。token 数据揭示了这一差异的来源。

支出的结构在每一次运行中都保持一致，worker 至少承担了 69% 的 token，大多数情况下超过 90%。

但费用的分配与 token 的分配不同，因为 planner 的 token 更贵。在 Opus 4.8 与 Composer 2.5 的混合方案中，作为 planner 的 Opus 只产生了很小一部分 token，却占了大约三分之二的成本，而作为 worker 的 Composer 处理了绝大多数 token，只占剩余三分之一的成本。

大型任务中真正需要前沿智能的时刻并不多，比如最初的分解、设计决策以及某些权衡取舍。一旦前沿 planner 把模糊性收敛为详细、明确的指令，较便宜的模型只需照做即可。这是一个巨大的潜在成本节约来源。在 planner 和 worker 都使用 GPT-5.5 的那次运行中，仅 worker 就花费了 $9,373。而在由 Opus 4.8 负责规划、Composer 2.5 负责执行的那次运行中，整个 worker 集群只花费了 $411。

有一个值得注意的细节来自对两次混合运行的比较。Fable 5 planner 的账单比 Opus 4.8 planner 略低，尽管其每 token 价格大约是后者的两倍，因为它使用的规划 token 少得多。但 Fable 那次运行的 worker 消耗的 token 是前者的好几倍，整个运行的总成本因此高出不少。

规格即提示词

AI 能力的每一次跃升，都提升了工程师所能工作的抽象层级。

自动补全让工程师一次处理一行代码。早期的模型将这一层级提升到一块代码，而智能体又将其提升到一个文件或一个功能。

有了集群（swarm），工作单元变成了规格说明（spec）。

要做到这一点，集群必须真正遵循规格说明，而这正是本文大部分内容所讨论的。我们给了集群 835 页的文字，它交回了一个数据库。在这个实验中稀缺的东西，也是我们预计未来软件工程中会稀缺的东西，就是对意图的恰当描述。

从这个角度看，集群开始变得像一个编译器。编译器通过一系列中间步骤将源代码向下翻译为机器码。集群对意图做着类似的事情。规划器将目标解析为任务树，然后一步步将其降低为可执行的工作。区别在于，编译器在每一步都保留语义，而集群在每一步都是概率性的。本文所描述的一切，都是为了弥合这一差距。

我们邀请你来探索集群的输出。单独运行 Opus 4.8 所得的代码库已公开在 github.com/anysphere/minisqlite。根据我们的初步浏览，它看起来很棒，但我们尚未进行更深入的人工分析。请你自己看看，并告诉我们你的发现。

1. 为了解单打独斗的前沿模型成本，我们还单独运行了 Opus 4.8 和 Fable 5。我们只对这些运行做了非正式评分，因此这里不对它们的质量下结论，不过根据经验，我们预计这两个模型都会有不错的表现。它们的成本在图表中以阴影柱状条显示。↩

2. 我们原本希望将 GPT-5.6 Sol 作为前沿配置。这个新模型似乎比我们测试的其他模型对字面和强调性措辞更敏感，而且我们遇到了其他模型从未产生的失控式循环。由于这个模型刚发布不久，没有时间为其调整提示词，而只为一个模型调优、其余模型不动又会让对比失准，所以我们退回到了 GPT-5.5。↩