你把一本835页的家具说明书交给一群人，却不让他们看成品、零件样板或网上教程，最后要他们做出能通过验收的家具。Cursor把类似的难题交给了AI：只读SQLite手册，不看源码，不拿现成测试，也不能联网，用Rust从零实现数据库引擎。
SQLite是嵌入手机、浏览器和应用程序的轻量级关系数据库；Rust则是一门强调内存安全和性能的系统编程语言。重造SQLite，能同时考验AI是否读懂复杂规范、能否写出底层代码，以及多个Agent——能够自主接任务和操作工具的AI程序——能否长期协作。
据InfoQ对Cursor材料的转述，这次实验最终交付了可运行的数据库实现。不过，目前公开供稿只有这一条报道，以下测试、成本和代码数据都缺少官方原文、代码仓库或第三方复现的交叉验证。
关键不是多叫几个人
早期蜂群采用较扁平的协作方式：多个Agent共享协调文件，自行认领任务，再通过Git合并代码。问题很像几十支装修队同时进场。大家都很忙，却可能重复砌墙、争抢同一扇门，还没人持续照看整体设计。
同用Grok 4.5时，旧蜂群不到两小时便产生68,000次提交和超过70,000次合并冲突。冲突最严重的文件被1,173个Agent修改，累计冲突7,771次。项目还膨胀到54个crate——Rust项目用来组织代码的包，其中甚至出现三个独立的SQL package。运行因此提前暂停。
新蜂群改用根规划者递归委派。规划者只负责拆任务和做设计决定，worker——专门执行具体任务的Agent——只处理边界清晰的小块实现。系统另设第三方Agent解决冲突，并用共享设计文档、错位评审和共同维护的“Field Guide”传递经验。
这个分工的直觉并不复杂：总设计师不用同时拧每颗螺丝，施工人员也不用一边铺地板，一边记住整栋楼的所有约束。规划与执行分开后，两边的上下文——模型当前能参考的信息——都更干净。
结果差异很明显。新蜂群完整运行四小时，合并冲突少于1,000次，代码结构稳定在9个crate。Fable 5与Composer 2.5组合中，新旧蜂群都通过完整测试集，但引擎代码分别为9,908行和64,305行。Opus组合下，新框架用4,645行代码获得100%得分；旧框架用了19,013行，得分97%。这些数字支持“编排减少重复劳动”的判断，但还不能证明它在其他项目里同样有效。
验收不是自己出题
最终评估使用sqllogictest——用大量SQL查询及预期结果检查数据库行为是否一致的工具。Cursor还设置了预留测试集：开发时不向Agent公开，最后才拿来验收，以降低针对已知题目投机过关的可能。研究团队也会人工检查代码和运行过程。
InfoQ称，新蜂群的多种模型配置通过了预留测试中的全部SQL结果一致性测试。这里必须限定范围：这说明相应实现能在该测试口径下返回正确结果，不等于它已具备SQLite的完整兼容性、可靠性、性能、安全性，更不代表可以直接投入生产。报道也没有给出预留子集的确切规模、覆盖范围和失败容忍规则。
昂贵模型该用在哪里
Cursor测试了四组规划器/worker：GPT-5.5/GPT-5.5、Grok 4.5/Grok 4.5、Opus 4.8/Composer 2.5，以及Fable 5/Composer 2.5。所有运行中，worker至少消耗69%的token——模型处理文本的计量单位，多数组合超过90%。
成本却不按工作量平均分布。Opus 4.8负责规划、Composer 2.5负责执行时，规划器只生成少量token，却占约三分之二成本；处理绝大多数token的worker只占约三分之一。GPT-5.5同时负责规划和执行时，仅worker就花费9,373美元；Opus 4.8/Composer 2.5方案的整个worker集群为411美元。
报道给出的总成本是10,565美元对1,339美元，相差近8倍，并称两者质量相近。更稳妥的理解是：昂贵模型或许只需处理任务拆解和关键取舍，大量明确的执行工作可以交给便宜模型。但两组数据缺少运行次数、单价、失败尝试和“质量相近”的统一口径，不能把价差直接当作普遍规律。
为什么值得关注
这场实验最有意思的地方，不是AI已经造出了可替代SQLite的产品，而是它把长周期协作编码的麻烦暴露得很具体：Agent越多，重复规划、上下文拥挤、文件争抢和合并冲突越可能吞掉并行带来的收益。
Cursor推测，蜂群扩展的关键可能是规划与执行的上下文隔离，而不只是同时启动更多Agent。现有材料能说明新架构在这次实验中更紧凑、冲突更少、成本更低，却还不足以确认编排普遍比模型选择更重要。
局限与未知
- 全部关键结果目前只有InfoQ这一条独立信源，模型名称、成本和测试数字仍需回查Cursor原始材料。
- SQL结果一致不等于完整重现SQLite，也没有性能、安全性和生产可靠性数据。
- 835页结构完整的手册是理想输入；面对过时文档、隐含规则和口头经验时，这套方法是否仍然奏效，材料没有回答。