智能体集群与新模型经济性
今年年初，我们开展实验测试智能体集群协作完成目标的能力边界，假设这种模式能解锁更复杂、规模更大的任务层级。
我们的核心项目是让智能体集群长期协作，从零开始构建一款网页浏览器。作为概念验证，项目取得了成功，但距离产出成熟软件还有很大差距。
这项工作完全基于实证探索：我们从空白状态起步，逐步迭代至稳定有效的系统。此后，我们的目标转为深入理解智能体集群的运作机制，从而实现可控的工程化设计。
为验证研究进展，我们回到了旧版集群曾棘手的任务：仅依据SQLite文档，用Rust语言从零实现SQLite。
初步结果令人振奋。我们让新旧集群在相同模型、相同时间预算下完成同一任务，通过独立的SQL测试套件通过率衡量表现。
新集群在所有模型配置下的表现均更优。使用Grok 4.5时，新集群4小时内达到80%的通过率，而旧集群陷入混乱，不到2小时就不得不中止运行。
我们还测试了不同模型的分工组合：有的测试中单一模型包揽所有工作，有的则由前沿模型负责规划，轻量低成本模型负责执行。所有组合的产出质量相近，但成本差异巨大。1
大型任务的描述天然呈现树状结构：根节点是总目标，向下递归分解为基础工作单元。我们的集群围绕这一树状结构设置两种角色：
- 规划智能体：由最先进的模型驱动，负责将目标拆解为子任务并分配出去。
- 执行智能体：通常由速度更快、成本更低的模型驱动，负责完成具体子任务。
这一设计是更僵化的编排系统的超集。它不会给任务强加固定结构，而是让集群形态贴合任务需求，计算资源与上下文信息的规模也随任务复杂度动态调整。
我们认为，正是这种特性让该设计能适配各类任务，比如构建浏览器、解决数学问题、优化GPU内核。我们也在内部用它排查开源软件漏洞、提升自有代码库的测试覆盖率，以及生成数十亿 token 的合成训练数据。
若让单个智能体承担完整任务，它必须独自遍历整个任务树：既要深入到每个叶节点执行具体工作，又要全程牢记上层任务、当前进度和整体目标。
我们认为这正是单智能体长期运行易“跑偏”的原因：要么专注眼前工作而忽略全局，要么死守全局目标却搞砸具体任务。
而在集群模式下，规划智能体从不负责具体实现，因此不会被底层细节占用上下文；执行智能体从不参与规划，可将全部上下文资源投入单一细分任务。
我们推测，智能体集群的可扩展性主要源自这种上下文效率，而非并行性本身。这种效率在任何规模的集群中都能体现，因此即便处理中等规模任务，这种分工模式也能提升智能体的表现。
这种结构在其他领域也有迹可循。经济学家罗纳德·科斯曾探讨企业存在的意义，他提出：协调成本的增长速度快于工作量本身，因此组织会形成分层的有限单元，而非让所有人直接沟通。
在此前关于集群的文章中，我们提到Git、Cargo等工具依赖粗粒度锁实现并发控制。这对单个开发者来说足够，但面对数百个并发智能体的工作量，就完全行不通了。
今年年初的浏览器集群项目，Git提交峰值约为每小时1000次；而新系统的提交峰值可达每秒1000次。
为支撑这样的高活跃度，我们从零构建了一套新的版本控制系统（VCS）。自主研发这一层级不仅是为了提升吞吐量：系统中的所有变更都会经过VCS，因此冲突最早在这里显现，后续介绍的若干协调机制也直接在VCS内部实现。
人类工程团队有一套标准协调机制，比如代码评审、代码归属、站会、合并队列等。这些机制适配人类的工作节奏，但在智能体集群的提交速率下，会出现人类团队极少遇到的失效模式。
协调问题与解决方案
重复设计：两个规划智能体互不了解，在代码库不同区域用不同方式实现同一功能。 我们通过优化提示词解决此问题：要求规划智能体自行做出设计决策，而非将其下放，并确保不同子任务树不会重复处理同一设计问题。
设计冲突：更棘手的情况是，两个规划智能体知晓彼此存在，却通过反复修改同一文件产生冲突。 这种问题源于对“需求”的认知分歧，合并工具无法解决观念冲突。我们的方案是让智能体将决策记录在共享设计文档中，依赖该决策的代码需包含指向文档的编译校验引用。当规划智能体无意间做出矛盾决策时，协调智能体将合并文档，引用会自动将决议同步到下游代码。
文件冲突：集群内的智能体经常同时修改同一文件。若要解决冲突，它们需暂停工作、理解对方上下文并合并内容，但执行智能体不擅长此操作，实际中要么覆盖他人修改，要么放弃自己的工作。 对此，我们引入中立第三方智能体，代表各方介入并解决合并冲突，其目标是保持公正高效，类似人类团队中的合并队列机制。
巨型文件：部分文件是智能体的高频工作区域，每个智能体仅添加少量代码，但没有主体负责控制文件大小。 这些“巨型文件”会拖慢整个系统：传输、对比、合并成本极高，还会成为冲突频发地带。 我们的解决方案是让执行智能体标记臃肿文件，标记后系统会阻止新提交，并由外部智能体将过大的文件拆分为更小的模块。
核心代码不敢改：智能体从与人类协作的现有代码库中习得经验，即便核心代码需要修改也不敢触碰。 为此，我们允许智能体主动修改核心代码：判断核心代码值得修改的智能体，可在自身任务范围外提交针对性补丁，并附上修改理由。 编译器会将变更同步到系统其他部分，所有依赖旧设计的代码都会构建失败。遇到错误的智能体将查看注释、理解修改逻辑，然后更新自身负责的代码以适配新设计。
在长期运行的多智能体系统中，错误会不断累积，集群需要在小错误演变为根本性问题前自我修正。
我们测试了多种评审模式：给评审智能体提供执行智能体的完整对话记录、仅提供输出结果，或仅提供代码库；还尝试用不同训练背景、不同“性格”的模型担任评审。
单一模式无法覆盖所有问题，但不同模式的组合能实现互补——就像自动驾驶系统无需单个完美组件，也能达到超越人类的可靠性。评审环节的算力投入回报率很高，因为评审成本远低于其审核的工作成本。我们认为，这种多层评审系统是集群持续产出高质量成果的关键因素之一。
stigmergy（环境介导协作）
stigmergy（环境介导协作）是蚂蚁、白蚁等群居生物无需直接沟通就能协调行动的机制：它们改造环境，而环境又引导后续个体的行为。
在早期实验中，我们就设定了“记录笔记”“文档化决策”等规则，当时只是觉得这些做法显然有益。现在回顾，这些规则其实是让智能体为未来的自己和队友沉淀知识。
我们进一步推进这一思路，开展了一项名为“现场指南（Field Guide）”的实验：智能体自主编写、共享上下文信息。这是一个完全由智能体管理的文件夹，其index.md文件会自动注入每个智能体的初始上下文。智能体负责筛选指南内容，唯一限制是行数上限。
该指南背后的逻辑是：模型权重是固定的，因此捕捉意外遇到的信息至关重要，能让后续智能体的工作路径更短。
现场指南的初步实验结果喜人。我们预计，在智能体不完全熟悉的代码库中，其作用会更加显著。未来一个有趣的研究方向是训练模型为后续智能体编写指南，让更优质的知识沉淀获得更高奖励。
最终测试：用Rust实现完整SQLite
我们让整合了上述所有改进的新版集群，依据835页的SQLite手册，用Rust实现完整的SQLite系统。测试中，我们不提供SQLite源代码、测试套件、二进制文件，也不允许访问互联网。
我们用sqllogictest测试套件衡量进度。该套件由SQLite项目开发，用于验证不同数据库引擎对同一查询的返回结果是否一致，包含数百万个带有已知正确答案的查询，集群实现的数据库答对的比例即为得分。运行过程中，得分曲线上升代表进度推进。
集群并不知道该测试套件的存在。每次运行结束后，我们都会人工审核代码和运行过程，检查是否存在作弊或取巧行为，确认系统是均衡构建的，而非仅针对测试点开发。
解读得分曲线时需注意：智能体自主选择工作策略。有的先搭建广泛基础，数小时内得分较低，后期突然飙升；有的先深耕某一领域，早早取得分数，随后进入平台期再补充其他部分。相比特定时间点的精确得分，整体趋势更有参考价值。
我们测试了四种兼顾能力与成本的配置：
- GPT-5.5兼任规划与执行：全程使用顶尖前沿模型。-2
- Grok 4.5兼任规划与执行：作为成本效益较高的前沿模型，用作对比基准。
- Opus 4.8负责规划，Composer 2.5负责执行：前沿模型做决策，轻量模型高效执行。
- Fable 5负责规划，Composer 2.5负责执行：验证次顶级模型担任规划者是否能提升混合模式的性价比。
新版框架在所有组合下的表现均优于旧版：
- Fable 5混合配置在第一个小时内就通过了约三分之二的测试；4小时截止时，新版集群的得分在73%至85%之间，而旧版仅为11%至77%。
- 旧版Grok 4.5运行不到2小时就被迫中止（下文详述），而所有新版配置最终都实现了100%的测试通过率。
未来我们计划测试所有规划-执行模型的组合矩阵，但本次实验重点是对比新旧框架，实际行为差异的影响远大于得分差异。
从最直观的活跃度指标——提交速率来看，Grok 4.5在新旧框架下的表现差异显著：旧框架运行前2小时产生了68000次提交，速率约为新框架的70倍。
一种解读是旧框架效率更高，另一种则是大部分提交都是无效操作（重复劳动、冲突、无意义变更）。
合并冲突数据支持后一种解读：旧框架在中止前累积了超过70000次冲突，且冲突数量还在加速增长；而新框架在4小时全程仅记录了不到1000次冲突。
冲突集中出现在最大的文件中：旧框架中，最大的文件持续膨胀，最热门的单个文件累计产生7771次冲突，涉及1173个不同的智能体；而新框架中，整个代码库最具争议的文件仅出现47次冲突。
旧集群最大的协调失败——“分裂大脑”（即规划智能体重复工作），在包结构中体现得尤为明显。Rust代码通过名为crate的包组织，在这类项目中，每个crate对应一个主要组件。
旧框架最终生成了54个crate，其中包含3个独立的SQL包；而新框架很早就确定了9个crate，且后续从未新增。
这些差异最终体现在代码库规模上：使用Fable 5混合配置时，新旧集群都最终通过了全部测试，但旧集群需要64305行引擎代码，新集群仅用9908行；Opus混合配置也呈现同样趋势：旧框架下达到97%得分需要19013行代码，新框架下100%得分仅需4645行。
如前文所述，所有模型组合的产出质量相近，但成本差异巨大：Opus 4.8混合配置成本为1339美元，而单独使用GPT-5.5的成本高达10565美元。token数据揭示了成本差异的来源。
所有运行的token消耗结构一致：执行智能体消耗的token占比至少为69%，多数情况下超过90%。
但成本分配与token分配并不一致，因为规划智能体的token单价更高。在Opus 4.8+Composer 2.5的组合中，作为规划者的Opus仅消耗少量token，却占据约三分之二的成本；而作为执行者的Composer处理了绝大多数token，成本仅占剩余三分之一。
大型任务中，真正需要前沿智能的环节其实很少，比如初始任务分解、设计决策和某些权衡判断。一旦前沿规划模型将模糊需求转化为明确详细的指令，低成本模型只需按指令执行即可。这能带来巨大的成本节约：单独使用GPT-5.5时，仅执行智能体的成本就达9373美元；而Opus 4.8规划+Composer 2.5执行的组合中，整个执行智能体集群的成本仅为411美元。
对比两种混合配置有一个值得注意的细节：尽管Fable 5的token单价约为Opus 4.8的两倍，但由于它消耗的规划token少得多，规划环节的成本略低；不过Fable组合中执行智能体消耗的token是Opus组合的数倍，导致整体成本更高。
思考与展望
每一次AI能力的跃升，都提升了工程师的工作抽象层级：
- 代码补全让工程师能逐行编写代码；
- 早期AI模型将抽象层级提升到代码块；
- 单智能体则进一步提升到文件或功能模块；
- 而智能体集群让工作单元变为需求规格。
要实现这一点，集群必须严格遵循规格，这正是本文大部分内容探讨的重点。我们给集群835页的文字说明，它交付了一个可用的数据库。在本次实验中，未来软件工程领域中，最稀缺的资源将是对需求意图的精准描述。
从这个角度看，智能体集群开始像一个编译器：编译器通过一系列中间步骤将源代码转化为机器码，而集群则对“需求意图”做类似处理——规划智能体将目标解析为任务树，逐步细化为可执行的工作。两者的区别在于，编译器在每一步都严格保留语义，而集群的每一步都带有概率性。本文介绍的所有机制，都是为了缩小这一差距。
我们邀请你探索集群的产出：单独使用Opus 4.8完成的代码库已开源至github.com/cursor/minisqlite。初步看来质量良好，但我们尚未做深入人工分析，欢迎你自行查看并分享发现。