Cursor 用一群 Agent 重造 SQLite：仅凭 835 页手册，无源码、无测试、不联网
摘要：Cursor 工程团队让一群 AI 智能体仅凭一份 835 页的 SQLite 手册，从零用 Rust 实现了一个数据库引擎，并全部通过预留测试。实验发现，通过规划者与执行者分工，成本可以从 10,565 美元降至 1,339 美元，差了近 8 倍。关键启示是：智能体的协作方式，往往比模型本身的强弱更重要。
花 10,565 美元让 AI 写 SQLite，和花 1,339 美元做到同样的事，区别可能不在模型够不够强，而在于你怎么用它。
Cursor 的工程团队刚刚公布了一项实验：一群智能体仅凭一份 835 页的 SQLite 手册，用 Rust 从零实现了一个数据库引擎。这些智能体既没有拿到源代码，也没有测试套件或二进制文件，更无法访问互联网。最终，智能体集群交付了一个数据库实现，并在后续运行中通过了全部预留的 SQL 结果一致性测试。
值得关注的是成本差距。全部使用前沿模型、让昂贵模型承担所有工作的方案花费了 10,565 美元；采用规划者与执行者分工的方案，由前沿模型负责规划、较便宜的模型负责执行，在实现相近质量的情况下只花了 1,339 美元。差了将近 8 倍。
换句话说，这场实验最有价值的结论，与其说是“一个 Rust 版的 SQLite 克隆已经可以直接拿来用了”，不如换成另一种理解：如今，智能体如何编排，可能比你选用哪一个具体模型更重要。
另外，Cursor 已经通过一套严格的测试设计来验证智能体集群的产物。最终的评估工具是 sqllogictest——来自 SQLite 项目的一套测试工具，用于验证不同数据库引擎执行相同 SQL 查询时能否返回相同结果。这套测试包含数百万条 SQL 查询，覆盖了 SQL 行为的广泛范围。
关键是，Cursor 采用了“预留测试集”（held-out test suite）——智能体集群事先并不知道这套测试集的存在。研究团队在每次运行后还人工检查代码和整个运行过程，确认智能体没有走捷径或只针对测试内容优化。结果在多种模型配置下都通过了这套预留测试集中的全部测试。
SQLite 实验并非 Cursor 的第一次尝试
这次实验是 Cursor 一系列连续实验的最新一步。
在更早的长时间自主编程实验中，Cursor 曾让数百个智能体协作，从零构建浏览器。最初的协同设计采用扁平结构：所有智能体共享一份协调文件，主动认领任务，并通过锁机制或乐观并发方式协同工作。
Cursor 表示，这些系统最终陷入了锁竞争，反复执行重复且风险较低的任务，同时回避那些困难、需要端到端负责的工作。
在下一轮迭代中，Cursor 将规划与执行分离。规划智能体负责探索代码库，并递归创建任务；工作智能体则专注于一个边界明确的具体任务；裁判智能体判断是否还需要继续迭代。这时，系统已经开始摆脱“一个聪明模型编写大量代码”的思路，逐渐转向一套控制系统。
在后续文章中（https://cursor.com/cn/blog/self-driving-codebases），Cursor 又介绍了由规划者、执行者、工作智能体和裁判组成的多种实验方案。随后他们发现，持续运行的执行者承担了过多工作：它既要规划、研究和修改代码，又要处理合并、审查，并判断任务是否已经完成。
最终系统重新采用根规划者架构。根规划者掌握完整目标，递归地将任务委派成范围狭窄的工作单元，但自身永远不参与具体实现。工作智能体完成任务后，只向将任务交给它的规划者返回一次交接结果。
SQLite 实验又加入了一系列机制，将这种层级结构变成一条高吞吐量的软件生产线：定制版本控制系统；由中立第三方智能体解决冲突；把设计决策写入共享文档，并通过可由编译器校验的引用将决策传递到下游代码；使用观察角度有意错开的评审智能体；以及由智能体共同维护、供后续智能体继承使用的共享“Field Guide”。
当单个智能体独自承担一项完整任务时，它必须自行走完整棵任务树，一路下探到每个叶节点，并在整个过程中始终在上下文中维持祖先节点、当前位置以及更宏观的目标。随着运行时间拉长，单个智能体容易出现上下文拥挤和注意力失衡：要么过度专注眼前工作，逐渐丢失全局目标；要么努力维持全局视角，却无法充分处理局部细节。
在新的 swarm 实验中，规划器从不负责实现，所以它的上下文不会被底层细节塞满；而 worker 从不负责规划，因此它可以把全部上下文都投入到一小块具体工作中。
Cursor 推测，智能体 swarm 的可扩展性很大一部分来自这种上下文效率，未必主要来自并行性。由于规划与执行之间的上下文隔离在不同集群规模下都存在，这种拆分即使面对中等规模任务，也可能改善智能体表现。
关键发现：智能体编排重于模型能力
Cursor 测试了四种配置，覆盖不同能力与成本区间。第一种，GPT-5.5 同时担任规划器和 worker，全程使用强大的前沿模型。
（后续内容将在下一段继续）
关键要点
- Cursor 的实验证明：让 AI 智能体仅凭一份 835 页的手册，就能从零用 Rust 构建一个通过全部测试的 SQLite 克隆。
- 规划者与执行者分工的方案（1,339 美元）比全部使用前沿模型（10,565 美元）成本低了近 8 倍，但质量相近。
- 智能体的协作方式——尤其是规划与执行的上下文隔离——可能比选哪个模型更关键。
本段深入对比了四种模型组合在重造 SQLite 实验中的成本表现，揭示了「前沿模型只做决策，低成本模型负责执行」的核心成本优化策略。同时详细拆解了旧蜂群遇到的脑裂、文件膨胀、七万次冲突等典型问题，并介绍了新蜂群如何通过智能体版本控制、设计文档引用和冲突解决等机制实现近千倍的效率提升。最后引申出软件工程正在从「实现目标的手艺」转向「定义目标的学问」这一趋势。
四种模型组合的成本账：为什么只让聪明模型做决策
实验共测试了四种模型搭配方案：
- 方案一：Grok 4.5 同时担任规划器和执行者，作为成本相对较低的前沿模型基准。
- 方案二：Opus 4.8 担任规划器，Composer 2.5 担任执行者——以前沿模型的判断力搭配低成本执行模型。
- 方案三：Fable 5 担任规划器，Composer 2.5 担任执行者，用来观察能力稍弱的规划模型是否会削弱组合价值。
- 方案四：GPT-5.5 同时担任规划器和执行者，作为全前沿模型的高成本对照。
关键洞察隐藏在成本分布里。以 Opus 4.8 + Composer 2.5 的组合为例：Opus 作为规划器只产生了一小部分 token，却占了总成本的约三分之二；而 Composer 作为执行者处理了绝大多数 token，成本却只占剩下的三分之一。在所有运行中，执行者消耗了至少 69% 的 token，多数组合中这个比例甚至超过 90%。
数字更能说明问题：在 GPT-5.5 同时担任两个角色的那次运行中，仅执行者部分的成本就高达 9373 美元。而在 Opus 4.8 规划 + Composer 2.5 执行的方案中，整个执行者集群的总成本只有 411 美元。
这个现象背后有个核心逻辑：在大型任务中，真正需要前沿智能的环节其实不多——主要是最初的任务拆解、设计决策和一些权衡取舍。一旦前沿规划器把这些不确定性收敛为详细明确的指令，低成本模型只需要照着执行即可。这就是成本节省的最大来源。
旧蜂群踩过的坑：脑裂、文件膨胀与七万次冲突
同样使用 Grok 4.5，旧蜂群在两小时内产生了 68000 次提交，积累超过 70000 次合并冲突。最大的几个文件在整个运行期间持续膨胀，其中冲突最严重的文件被 1173 个不同智能体改动过，累计 7771 次冲突。运行不到两小时就不得不暂停。而新蜂群跑完完整的四小时，提交少得多，冲突不到 1000 次。
旧蜂群存在典型的「脑裂」问题——多个规划器互相不知道对方的工作，重复实现同一功能，导致代码仓库膨胀到 54 个 crate，其中甚至包含三个彼此独立的 SQL 包。新蜂群则稳定在 9 个 crate，之后再无新增。
最终代码量也相差悬殊：在 Fable 5 组合中，旧蜂群和新蜂群都通过了完整测试，但旧蜂群需要 64305 行引擎代码，而新蜂群只用了 9908 行。Opus 组合同样如此：旧框架下用了 19013 行代码，得分为 97%；新框架下只用了 4645 行，得分达到 100%。
新蜂群的解决思路：为智能体重写协作规则
Cursor 此前的浏览器蜂群使用共享协调文件和 Git 等传统工具，Git 上的提交峰值约为每小时 1000 次。新蜂群的产出峰值提升到每秒约 1000 次，传统版本控制系统依赖的粗粒度锁完全无法应对这种吞吐量。因此，Cursor 从零构建了一套面向智能体的版本控制系统。
问题一：规划器相互冲突——两个规划器分别在不同区域实现同一功能，互相不知情。新蜂群的方案是让规划器自己承担设计决策，不把决策权下放，同时确保不会让两个被委派的子树去决定同一个问题。
问题二：规划器明知对方存在仍来回博弈——针对同一批文件反复修改。新蜂群让智能体把决策记录在共享设计文档里，依赖某项决策的代码会附带一个可经编译校验的引用，追溯到对应文档。当规划器在不知情时产生矛盾，协调器会合并这些文档，而引用会一路传导解决结果。
问题三：合并冲突堆积——新蜂群引入一个中立的第三方智能体，专门负责解决冲突。
问题四：巨型文件膨胀——所有智能体都向少数几个文件中塞入代码，却没人负责精简。新蜂群允许执行者标记臃肿文件，暂时阻止新提交进入，再由外部智能体负责拆分。
问题五：核心代码逐渐僵化——智能体容易从历史模式中学到「不要触碰核心代码」。新蜂群允许智能体主动引入带说明的破坏性变更，让编译错误把影响传导至整个系统；遇到构建失败的智能体可根据说明完成后续更新。
软件工程正在变成什么
AI 能力的每一次跃升，都提高了工程师可工作的抽象层级。
自动补全让工程师按单行代码工作。早期模型把这一层级提升到代码块，智能体则进一步提升到文件或功能层面。而这次实验里，工作的基本单位变成了规格说明——Cursor 给了智能体 835 页文字手册，最终得到一个能通过 SQL 一致性测试的数据库实现。
Cursor 认为，这次实验中最稀缺的资源，也是未来软件工程中可能持续稀缺的资源，是对意图进行准确描述的能力。
当开发者只需要设定目标、附上规范、定义评估器，剩下的交给编排系统反复拆解和尝试——软件工程正在变成一门定义目标的学问，而不是实现目标的手艺。工程师的核心工作，可能逐渐从「怎样亲自实现」，转向「怎样准确描述目标、约束条件和验收标准」。