今年早些时候，我们开展了一系列实验，测试通过扩展智能体协作来共同实现目标的极限。我们的假设是，这将解锁任务规模和复杂性的一个新层级。

其中的旗舰项目是一个长时间运行的蜂群，从零开始构建一个 Web 浏览器。它作为概念验证取得了成功，但距离成为成熟、完善的软件还差得很远。

这项工作有意采用经验探索的方法。我们从一块空白画布出发，一步步迭代，摸索出一个稳定而有效的系统。从那以后，我们的目标一直是充分理解这个智能体蜂群，从而能够有意识地对它进行工程化设计。

为了检验这一进展，我们重新回到一个旧蜂群曾经难以完成的任务：只根据 SQLite 的文档，用 Rust 从零开始构建它。

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

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

我们还调整了不同模型承担的工作。在一些运行中，由一个模型包办所有工作；而在另一些运行中，则由一个前沿模型负责规划，再由一个快速且低成本的模型执行具体工作。每一种组合都产出了相近的质量，但成本差异非常大。¹

#树与叶子

对大型任务的描述天然会呈现出树状结构：根部是目标，再以递归方式不断细分为基本工作单元。我们的智能体群有两种角色，也都围绕这种树状分解来组织：

• 由最强模型驱动的规划器智能体，会将目标拆分成若干部分并委派出去。
• worker 智能体通常由速度更快、成本更低的模型驱动，负责执行这些部分。

这种设计涵盖了那些更为僵化的编排系统。智能体群不会给问题强加固定的拓扑结构，而是会沿着问题本身的轮廓自然扩展，其 compute 和 context 也会随着任务复杂度按比例伸缩。

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

#树如何影响记忆

当单个智能体独自承担一项完整任务时，它必须自行走完整棵树，一路下探到每个叶节点，并且在整个过程中始终在上下文中维持其祖先节点、当前位置以及更宏观的目标。

我们认为，这解释了为什么长时间运行的单个智能体会逐渐跑偏。它们要么专注于眼前的工作，从而失去对全局的把握；要么努力维持全局视角，却把局部环节做得更差。

在 蜂群 中，规划器从不负责实现，所以它的上下文不会被底层细节塞满；而 worker 从不负责规划，因此它可以把全部上下文都投入到一小块具体工作中。

我们怀疑，智能体 蜂群 的可扩展性更多来自这种上下文效率，而不是并行性本身。这种效率在 蜂群 的任何规模下都存在，这也是为什么这种拆分方式即使面对中等规模的任务，也能提升智能体的性能。

这种结构在其他地方也有类似体现。经济学家 Ronald Coase 在追问企业为何会存在时，提出，协调成本的增长速度快于工作本身，因此组织会形成由边界明确的单元构成的层级，而不是让所有人与所有人直接沟通。

#智能体的版本控制系统

在一篇较早介绍 swarm 的文章中，我们提到，Git 和 Cargo 这类工具依赖粗粒度锁来做并发控制。对单个开发者来说，这没问题；但对于数百个并发智能体产出的工作量，这种方式就完全行不通了。

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

为了支撑这样的活动速率，我们从零开始构建了一套新的版本控制系统 (VCS) 。吞吐量并不是我们要掌控这一层的唯一原因。系统中的每一次更改都会经过 VCS，因此冲突也会最先在这里暴露出来；而下一节中的若干协调机制，也是直接在这一层内部实现的。

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

人类工程团队有一套标准的协作机制，比如代码审查、责任归属、站会和合并队列。这些机制适用于人类的工作节奏，但在 swarm 的提交速率下，我们会看到一些人类团队平时几乎不会遇到的失效模式。

#脑裂设计

两个彼此不知情的规划器，在代码库的不同部分以不同方式实现了同一个概念。

我们通过提示解决了这个问题。规划器自己做出设计决策，而不是将这类决策委派出去；同时，我们还要求它们确保不会让两个被委派的子树去决定同一个问题。

#规划器之间的冲突

一种更棘手的冲突形式是：两个规划器彼此知晓对方的存在，并围绕同一批文件反复修改、相互博弈。

问题在于，双方对现实有着两套不同的认知，而合并工具无法消除这种分歧。相反，我们让智能体把决策记录在共享的设计文档中。依赖某项决策的代码会附带一个可经编译校验、并可追溯到对应文档的引用。当规划器在不知情的情况下相互矛盾时，协调器会合并这些文档，而这些引用会将解决结果一路传递到下游。

#合并冲突

在 swarm 中，智能体经常会因为同时处理同一文件而发生冲突。要解决这种冲突，它们必须先停下来，理解另一个智能体的上下文，再在此基础上完成合并。worker 智能体并不擅长处理这种情况，实际中往往要么覆盖对方的更改，要么放弃自己的更改。

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

#超大文件

有些文件特别容易成为智能体集中处理的对象。每个智能体可能只会添加少量代码，而且没有任何一个智能体负责让这些文件保持精简。

这些“超大文件”会拖慢一切。它们在传输、比对差异和合并时成本高昂，还会不断成为冲突的源头。

为了解决这个问题，我们让 worker 智能体能够标记臃肿的文件。文件一旦被标记，我们就会阻止新的提交，并由外部智能体将这个过度膨胀的文件拆分成更小的模块。

#僵化

智能体在由人类参与的现有代码库中工作时，已经学会了：即使核心代码确实需要改动，也不要轻易去碰它。

为了解决这个问题，我们允许有意引入破坏性变更。若某个智能体判断对核心部分的改动确实值得，它就可以在自身范围之外提交一个有针对性的补丁，并留下注释说明这么做的原因。

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

#审查视角

在一个既长时间运行又是多智能体的系统中，错误会不断累积，因此这个群体需要一种机制，在小错误演变成根本性问题之前完成自我纠正。

我们试验了许多不同的审查视角，比如给审查智能体提供 worker 的完整对话记录，或者只提供其输出，或者只提供代码库。我们也尝试过让审查者基于不同模型运行，接受不同训练，并具备不同的“个性”。

没有任何一种单一视角能发现所有问题，但彼此低相关的视角可以叠加起来，就像自动驾驶系统并不依赖某一个完美组件，却依然能达到高于人类的可靠性。投入在审查上的算力回报很高，因为审查的成本远低于它所审查的工作。我们怀疑，这种叠加式审查系统，是这些运行能够持续保持高质量的重要原因之一。

#让智能体塑造环境

迹象引导是一种让蚂蚁、白蚁等群居生物无需直接沟通也能协同运作的机制。它们塑造环境，而环境又会塑造下一个个体。

在更早的运行中，我们加入了诸如“保留笔记”和“记录决策”之类的规则，因为这些规则看起来显然有益。现在回头看，这实际上是在让智能体为未来的自己和队友沉淀知识。

我们又通过一个由智能体自主编写、共享上下文的实验，把这件事向前推进了一步。我们把它称为 Field Guide。它是一个完全由智能体管理的文件夹，其中的 index.md 会在启动时自动注入给每个智能体。决定哪些内容进入这份指南是智能体的职责，它们唯一的限制就是行数预算。

这份指南背后的逻辑是：模型权重是冻结的，因此真正值得记录的，恰恰是那些出乎意料的情况，这样下一个智能体的任务轨迹就能更短。

Field Guide 还是一项处于早期阶段、但已经展现出良好效果的实验。我们预计，在那些并非完全由智能体掌控的代码库中，它带来的收益会更大。训练模型为它们的后继者写作——在这种情况下，捕捉得越好，奖励就越高——是一个值得继续研究的有趣方向。

#SQLite 实验

我们让配备了上述所有改进的新版本 swarm 用 Rust 实现 SQLite 这份长达 835 页手册中的全部内容。我们没有向它提供源代码、测试套件、SQLite 二进制文件，也不提供互联网访问权限。

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

我们从未告诉 swarm 这套测试的存在。每次运行后，我们都会人工审查代码和整个运行过程，检查是否存在作弊或走捷径的情况，并确认系统的构建是均衡推进的，而不只是针对测试会检查到的地方做优化。

在阅读这些曲线时，请记住，智能体会自行选择策略。有些会先打下广泛的基础，连续数小时得分较低，随后在后期突然跃升；另一些则会先深挖某一个领域，很快拿到分数，然后在补齐其余部分时进入平台期。相比某个具体时刻的精确分数，整体趋势更重要。

#不同模型组合下的结果

我们测试了四种覆盖不同能力与成本区间的配置：

1. GPT-5.5 同时作为规划器和 worker。 全程使用强大的前沿模型。²
2. Grok 4.5 同时作为规划器和 worker。 这是我们最具成本效益的前沿模型，用作对比基准。
3. Opus 4.8 作为规划器，Composer 2.5 作为 worker。 以前沿级判断力搭配高效执行。
4. Fable 5 作为规划器，Composer 2.5 作为 worker。 用来观察次一级规划器是否会让这种混合方案更值得采用，还是恰恰相反。

新框架在每一种组合中都优于旧版。

Fable 5 混合方案在第一个小时内通过了大约三分之二的测试集。到四小时截止时，新版运行的结果介于 73% 到 85% 之间，而旧版运行的范围则是 11% 到 77%。

旧版的 Grok 4.5 运行在接近两小时时被暂停了 (下文详述) 。所有新版配置最终都通过了整个测试集。

未来，我们希望运行规划器与 worker 组合的完整 N×N 矩阵。就这一轮而言，真正重要的是不同框架版本之间的对比，而最终呈现出的行为差异也远比分数差异所显示的更大。

#深入剖析这些运行

先看最简单的活动指标，我们可以看到 Grok 4.5 在旧框架 和新框架 下的提交速率有何变化。旧运行在前两个小时内产生了 68,000 次提交，速度大约是新运行的 70 倍。

一种解读是，它的生产效率更高。另一种解读是，这些提交大多只是无效忙碌 (反复折腾、相互争抢、来回改动) 。

合并冲突数据更支持后一种解读。旧运行在我们暂停之前累计了超过 70,000 次冲突，而且增长速度还在加快，并没有趋于稳定；而新运行在完整的四小时内记录的冲突不到一千次。

冲突主要集中在体量增长最大的文件上。在旧运行中，最大的几个文件在整个运行期间持续膨胀，其中冲突最严重的那个文件累计了 7,771 次冲突，被 1,173 个不同的智能体改动过。而在新运行中，整个代码库里争抢最激烈的文件也只出现了 47 次冲突。

旧蜂群最大的协调失效——脑裂，也就是多个规划器重复彼此的工作——体现在 package 结构上。Rust 代码按称为 crate 的 package 组织，而在这样的项目里，每个 crate 大致对应一个主要组件。

旧运行一路扩张到 54 个 crate，其中包括三个彼此独立的 SQL package。新运行则很早就稳定在 9 个 crate，之后再也没有新增。

这一切最终都会反映在最终代码库中。在 Fable 5 mix 中，旧蜂群和新蜂群最终都通过了完整 suite，但旧蜂群需要 64,305 行引擎代码，而新蜂群只用了 9,908 行。Opus mix 也呈现出同样的趋势：旧框架 下用了 19,013 行代码，得分为 97%；新框架 下则只用了 4,645 行，得分达到 100%。

#模型经济性

我们在开头提到过，不同模型组合产出的质量都大致相当，但成本差异却非常大：从 Opus 4.8 混合方案 的 $1,339，到仅使用GPT-5.5的$10,565。token 数据揭示了这种差异的来源。

各次运行的支出结构都很一致：worker 至少承担了 69% 的 token，而大多数运行中这一比例都超过了 90%。

但美元成本的分布与 token 占比并不一致，因为规划器 token 的成本更高。在 Opus 4.8 与 Composer 2.5 的组合中，作为规划器的 Opus 只产生了很少一部分 token，却占了大约三分之二的成本；而作为 worker 的 Composer 处理了绝大多数 token，却只占剩下三分之一的成本。

在大型任务中，真正需要前沿智能的环节其实并不多，比如最初的任务拆解、设计决策，以及某些权衡取舍。一旦前沿规划器把这种不确定性收敛为详细而明确的指令，成本更低的模型就只需要照着执行。这是成本节省的一个巨大潜在来源。在同时使用 GPT-5.5 作为规划器和 worker 的那次运行中，仅 worker 的成本就高达 $9,373。而在由Opus4.8负责规划、Composer2.5负责执行的那次运行中，整个worker集群的成本只有$411。

还有一个值得注意的细节，可以从这两次混合运行的对比中看出来。Fable 5 规划器产生的账单略低于 Opus 4.8 规划器，尽管它的单 token 价格大约高出一倍，原因是它使用的规划 token 少得多。但 Fable 那次运行中的 worker 消耗了数倍于前者的 token，因此整次运行的总成本明显更高。

#把规格说明当作提示

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

自动补全让工程师能够按单行代码来工作。早期模型把这一层级提升到了代码块，而智能体则进一步提升到了文件或功能层面。

有了蜂群，工作的基本单位就变成了规格说明。

但要让这套方式行得通，蜂群 就必须真正遵循规格说明，而这也正是本文很大一部分内容的核心。我们给了蜂群 835 页文字说明，它最后返回了一个数据库。在这次实验中真正稀缺的，以及我们预计未来在软件工程中会持续稀缺的，是对意图的准确描述。

从这个角度看，蜂群 开始有点像编译器。编译器会通过一系列中间步骤，把源代码翻译成机器代码。蜂群 对意图做的事情与之类似。规划器会先把目标解析成任务树，再一步步将其细化为可执行的工作。区别在于，编译器在每一步都会保留语义，而 蜂群 的每一步都是概率性的。本文所描述的一切，都是为了缩小这一差距。

我们邀请您来看看蜂群 的产出。此次 solo Opus 4.8 run 生成的代码库已公开发布在 github.com/cursor/minisqlite。根据我们的初步判断，它看起来很不错，但我们还没有做更深入的人工分析。您也不妨亲自看看，并告诉我们您的发现。