花 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 次，传统版本控制系统依赖的粗粒度锁已经无法应对这种吞吐量，因此 Cursor 从零构建了一套面向智能体的版本控制系统。
两个规划器在不同区域各自实现同一功能，彼此毫不知情，最后互相冲突。新蜂群的解决方案是让规划器自己承担设计决策，而不是将这类决策委派出去，同时确保不会让两个被委派的子树去决定同一个问题。
更棘手的是，两个规划器明明知道对方存在，却仍然围绕同一批文件来回博弈。新蜂群让智能体把决策记录在共享设计文档里，依赖某项决策的代码会附带一个可经编译校验、并可追溯到对应文档的引用。当规划器在不知情的情况下相互矛盾时，协调器会合并这些文档，而这些引用会将解决结果一路传递到下游。
合并冲突本身，新蜂群引入中立的第三方智能体专门负责解决。
另一个问题是巨型文件膨胀：所有智能体都不断向少数几个文件中塞入代码，却没有智能体负责主动精简。新蜂群允许执行者标记臃肿文件，暂时阻止新的提交进入，再由外部智能体负责拆分。
还有核心代码逐渐僵化的问题。在人类维护的代码库中，智能体容易从历史模式中学会“不要触碰核心代码”。新蜂群允许智能体主动引入带有说明的破坏性变更，再让编译错误将影响传导至整个系统；遇到构建失败的智能体可以根据说明完成后续更新。
软件工程正在变成什么
AI 能力的每一次跃升，都提高了工程师可工作的抽象层级。
自动补全让工程师能够按单行代码来工作。早期模型把这一层级提升到了代码块，而智能体则进一步提升到了文件或功能层面。这次实验里，工作的基本单位就变成了规格说明：Cursor 给了智能体 835 页的文字手册，最终得到一个能够通过 SQL 一致性测试的数据库实现。
Cursor 认为，这次实验中真正稀缺的资源，以及未来软件工程中可能持续稀缺的资源，是对意图进行准确描述的能力。
当开发者只需要设定目标、附上规范、定义评估器，剩下的交给编排系统去反复拆解和尝试——软件工程正在变成一门定义目标的学问，而不是实现目标的手艺。工程师的核心工作，可能逐渐从“怎样亲自实现”，转向“怎样准确描述目标、约束条件和验收标准”。
从这个角度看，现在的编程工具，开始有点像编译器。编译器会通过一系列中间步骤，把源代码翻译成机器代码。区别在于，编译器在每一步都会保留语义，而现 Agent 每一步都是概率性的，意图与执行之间始终存在一道裂缝。
缩小这道裂缝，正是 Cursor 在过去一年里反复尝试解决的核心问题。Cursor 最近发布的新版 Agents 界面，核心方向之一是让开发者能够在同一视图中并行运行多个智能体。SQLite 实验为这一产品方向提供了研究依据：开发者的工作正在从亲自动手实现代码，逐渐转向组织、监督和编排智能体。
当然，835 页且结构完整的 SQLite 手册终究是一个相对理想的输入条件。真实代码库充满模糊之处、未记录的行为，以及只存在于老员工脑子里的口头经验。当智能体面对一套停留在 2019 年的过时文档时，这套架构还能不能打，是另一回事。
参考链接：
