当Cursor的工程团队用一群AI智能体，仅凭一本835页的SQLite手册就从零写出了一个可运行的Rust数据库引擎，他们发现了一个反直觉的事实：智能体怎么编排，比你选哪个模型更重要。
这个结论不是推测，而是用真金白银验证出来的。
一个实验，四种配置，八倍成本差
实验目标很简单：智能体集群只能读SQLite手册（835页），不能看源码、不能跑测试、不能联网。用Rust从零实现，最后用SQLite官方测试套件（sqllogictest，数百万条SQL查询）验证正确性，且测试集是"预留"的——智能体事先不知道会被考什么。
Cursor跑了四种配置：
- 纯高端： GPT-5.5 同时担任规划器和执行者 → 成本 $10,565
- 纯性价比： Grok 4.5 同时担任规划器和执行者 → 基准对比
- 混合方案A： Opus 4.8 规划 + Composer 2.5 执行 → 成本 $1,339
- 混合方案B： Fable 5 规划 + Composer 2.5 执行 → 成本略高
关键发现：所有通过测试的配置，最终产出质量大致相当，但成本差了将近8倍。
混合方案（前沿模型规划 + 低成本模型执行）只花了$1,339，而让GPT-5.5包办一切花了$10,565。刨去执行者消耗的token占整体69%-90%以上，但执行者token单价远低于规划者——在Opus 4.8+Composer组合中，Opus只产生了少量token却占了约三分之二成本，Composer处理了绝大多数token却只占三分之一。
核心洞察很直白：大型任务中真正需要前沿智能的环节其实不多——任务拆解、设计决策、某些权衡取舍。一旦规划器把不确定性收敛为详细指令，便宜的模型照做就行。
从"一个聪明模型写大量代码"到"一套控制系统"
这次实验是Cursor一系列迭代的收官之作。往回看，演进路径清晰得令人惊叹：
第一代：扁平自协调（失败）
所有智能体地位平等，通过共享协调文件认领任务。结果：锁竞争严重，智能体回避困难任务，只做简单重复的事。如同一个没有项目经理的团队——人人都在忙，但没人愿意啃硬骨头。
第二代：规划与执行分离（初步可行）
规划智能体探索代码库、递归创建任务；工作智能体专注执行；裁判判断是否继续迭代。但持续运行的执行者任务过载：既要规划、研究、改代码，又要合并、审查、判断完成。
第三代：根规划器架构（稳定高效）
根规划者掌握完整目标，递归委派窄范围的工作单元，但永远不参与具体实现。工作智能体完成任务后只向父节点返回一次结果。上下文隔离是核心——规划器不被底层细节塞满，worker不因全局目标分心。
第四代：SQLite蜂群（高吞吐生产线）
在根规划器基础上叠加了全套工业化机制：
- 定制VCS： 从Git的每小时1000次提交提升到每秒1000次
- 中立冲突解决： 第三方智能体专门处理合并冲突（旧蜂群70000次冲突→新蜂群不到1000次）
- 设计文档+编译校验引用： 智能体把决策写入共享文档，依赖代码附带可追溯引用
- 多视角审查： 多种低相关叠加的审查视角，像自动驾驶系统一样可靠
- Field Guide： 智能体自主维护的共享知识库，供后继者继承
- 臃肿文件拆分： worker标记巨文件，外部智能体负责拆分
- 主动破坏性变更： 允许引入破坏性修改，编译器将影响传导至全系统
结果有多震撼？ 旧蜂群（Fable 5组合）用了64,305行引擎代码通过测试，新蜂群只用了9,908行。Opus 4.8组合更夸张：旧框架19,013行得分97%，新框架4,645行得分100%。
智能体蜂群为何有效：上下文效率大于并行性
这是Cursor自己给出的、我认为最有价值的洞察。
当单个智能体独自承担完整任务，它必须走完整个任务树，同时在上下文中维持祖先节点、当前位置和宏观目标。随着时间拉长，上下文拥挤和注意力失衡必然出现——要么过度专注眼前丢失全局，要么死守全局视角导致局部无力。
蜂群通过角色分解解决了这个问题：规划器从不实现，上下文不会被底层细节塞满；worker从不规划，可以把全部上下文投入一小块具体工作。
Cursor推测，蜂群的可扩展性更多来自这种上下文效率，未必主要来自并行性。这也是为什么即使是中等规模任务，合理拆分也能改善表现。
软件工程正在变成"定义目标的学问"
这次实验揭示了一个更深层的范式转移。
自动补全让工程师按行工作，早期模型提升到代码块，智能体进一步提升到文件/功能层面。而蜂群把规格说明变成了工作的基本单位。
Cursor的判断是：未来真正稀缺的，是对意图的准确描述能力。
当开发者只需要设定目标、附上规范、定义评估器，剩下的交给编排系统去拆解和尝试——软件工程正在从"怎样亲自实现"转向"怎样准确描述目标、约束条件和验收标准"。
更形象地说，现在的智能体编排系统，开始有点像编译器。编译器把源代码翻译成机器代码，每一步保留语义。而蜂群对意图做类似的事：规划器把目标解析成任务树，再细化为可执行的工作。区别在于，编译器的每一步都是确定的，蜂群的每一步都是概率性的。缩小这道"意图→执行"的裂缝，正是Cursor过去一年反复尝试的核心问题。
对开发者和团队的启示
- 别再迷信"最强模型"。 实验证明，在合理编排下，混合模型方案能在成本降低8倍的同时产出相近质量。真正值得投入精力的，是设计好规划与执行的边界。
- 上下文隔离是规模化智能体的关键。 分割角色→隔离上下文→专注局部，这套原则在人类团队中成立，在AI智能体集群中同样成立。
- 审查成本远低于工作成本。 多视角叠加的审查系统投入回报很高，小错误在累积之前就能被纠正。
- 规格说明的质量决定上限。 835页结构完整的SQLite手册是理想输入。真实代码库充满模糊、未记录的行为和口头经验——把模糊需求转化为精确规格，正在成为工程师的核心竞争力。
- 从"一个Agent写全部"到"一群Agent分工协作"，这条路径已经被验证可行。值得关注的是，Cursor最近发布的新版Agent界面允许在同一视图中并行运行多个智能体，SQLite实验为这一产品方向提供了底层研究依据。
参考来源：