Cursor 用一群Agent重造SQLite：仅凭 835 页手册，无源码、无测试、不联网

花 10565 美元让 AI 写 SQLite，和花 1339 美元做到同样的事，区别可能不在模型够不够强，而在于你怎么用它。 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，全程使用强大的前沿模型。 第二种，Grok 4.5 同时担任规划器和 worker。Cursor 将其作为成本相对较低的前沿模型基准。 第三种，Opus 4.8 担任规划器，Composer 2.5 担任 worker，以前沿模型的判断能力搭配成本更低的执行模型。 第四种，Fable 5 担任规划器，Composer 2.5 担任 worker，用来观察能力次一级的规划模型会让混合方案更划算，还是削弱这种组合的价值。 关键洞察在于成本分布。在 Opus 4.8 与 Composer 2.5 的组合中，作为规划器的 Opus 只产生了很少一部分 token，却占了大约三分之二的成本。而作为执行者的 Composer 处理了绝大多数 token，却只占剩下三分之一。在所有运行中，worker 至少消耗了 69% 的 token，多数组合中更是超过 90%。 在同时使用 GPT-5.5 作为规划器和执行者的那次运行中，仅执行者的成本就高达 9373 美元。而在 Opus 4.8 负责规划、Composer 2.5 负责执行的运行中，整个执行者集群的成本只有 411 美元。 在大型任务中，真正需要前沿智能的环节其实并不多，比如最初的任务拆解、设计决策，以及某些权衡取舍。一旦前沿规划器把这种不确定性收敛为详细而明确的指令，成本更低的模型就只需要照着执行。这是成本节省的一个巨大潜在来源。 脑裂、文件膨胀、七万次冲突，旧蜂群踩过的坑 同样使用 Grok 4.5，旧蜂群在两小时内产生了 68000 次提交，并积累了超过 70000 次合并冲突。最大的几个文件在整个运行期间持续膨胀，其中冲突最严重的那个文件累计了 7,771 次冲突，被 1,173 个不同的智能体改动过。于是，这次运行在不到两小时的时候被迫暂停。新蜂群跑了完整的四小时，提交少得多，冲突不到 1000 次。 旧蜂群存在脑裂现象，也就是多个规划器重复彼此工作，导致一路膨胀到 54 个 crate，其中甚至包含了三个彼此独立的 SQL package。新蜂群稳定在 9 个 crate，之后再无新增。 最终代码量差异也大，在 Fable 5 组合中，旧蜂群和新蜂群最终都通过了完整测试集，但旧蜂群需要 64,305 行引擎代码，而新蜂群只用了 9,908 行。 Opus 组合也呈现出同样的趋势：旧框架下用了 19,013 行代码，得分为 97%；新框架 下则只用了 4,645 行，得分达到 100%。 Cursor 此前的浏览器蜂群采用共享协调文件和 Git 等传统工具，Git 上的提交峰值约为每小时 1000 次。新蜂群的产出峰值则提升到每秒约 1000 次，传统版本控制系统依赖的粗粒度锁已经无法应对