Cursor 的新版 Agent swarm 根据 835 页手册重写了大部分 SQLite，并让每种新版模型组合最终在一套封存 SQL 逻辑测试上达到 100%。这是重要结果，也很容易被误读。
这里的 100% 表示生成引擎对被测 SQL 查询返回了预期结果，不代表 100% 分支覆盖、完整 SQLite 兼容、崩溃安全、性能达标、跨进程锁正确，更不等于生产可用。
这次实验最强的证据指向 Harness，而不是 SQLite 的替代品。
Cursor 实际测试了什么
Cursor 让 old/new swarm 在同一个 Rust 实现任务、相同模型组合和预设时间预算下对比。Agent 能看到 SQLite manual，但无法访问 SQLite 源码、测试套件、binary 和互联网。Cursor 表示 swarm 不知道封存 sqllogictest 的存在，运行结束后还进行了人工反作弊检查。
四种配置分别是：
- GPT-5.5 同时担任 planner 和 worker；
- Grok 4.5 同时担任两个角色；
- Opus 4.8 做 planner，Composer 2.5 做 worker；
- Fable 5 做 planner，Composer 2.5 做 worker。
四小时截止时，新版得分为 73% 至 85%，旧版为 11% 至 77%。所有新版配置后来都达到 100%，但 Cursor 没有公开每种配置到达 100% 的精确时间。旧 Grok run 在两小时前因协调失控被暂停，因此没有实际消耗完整预算。
这些得分、成本、冲突数量和人工审查都来自 Cursor 自报。精确测试快照、grader、完整 run logs 和复现实验脚本尚未公开。
真正的突破是减少协调浪费
最有说服力的数字并不是最终 SQL 得分。
在 Grok 对照中，旧 swarm 前两小时产生 68,000 个 commits，约为新版的 70 倍；暂停前累计超过 70,000 次 merge conflicts。新版完整运行四小时，冲突少于 1,000 次。
旧版最热点文件出现 7,771 次冲突，被 1,173 个 Agent 修改；新版最热点文件只有 47 次。旧架构扩张到 54 个 crates，其中包含三个互相竞争的 SQL package，新架构则稳定在九个。
代码规模也呈现同一趋势。Fable 新旧配置最终都达到 100%，engine code 却分别为 9,908 行和 64,305 行。Opus hybrid 的旧版用 19,013 行达到 97%，新版用 4,645 行达到 100%。
这是一组有效的 Harness Engineering 证据。共享设计记录、专门的冲突处理、架构检查、不同 review lens 和任务树减少了无效活动。Agent 更忙不等于进度更快。
模型分工让成本相差近八倍
Cursor 报告新版 run 成本最低为 1,339 美元，对应 Opus 4.8 planner 与 Composer 2.5 worker；最高为 10,565 美元，对应 GPT-5.5 同时承担全部角色。Worker 至少消耗 69% token，多数配置超过 90%。GPT-5.5 worker 单独花费 9,373 美元，而 Opus hybrid 的 Composer worker fleet 为 411 美元。
这不意味着某种组合在所有任务上都便宜近八倍。价格、任务结构、模型行为和 planner 质量都会变化。实验真正说明的是：planner 与 worker 的经济性应该分别测量。执行消耗大多数 token，少量更昂贵的规划却能重塑整棵任务树。
不要把 benchmark 与公开仓库混成一次运行
Cursor 发布了 cursor/minisqlite，但它来自 solo Opus 4.8 run，并不是 Opus planner 与 Composer worker 的 benchmark 产物。Cursor 把 solo run 描述为非正式评分，也表示公开工件只做过初步检查。
仓库本身仍可独立确认大量工程成果：约 20 万行 Rust、14 个 crates、5,650 个带 #[test] 标记的测试函数，以及一个刻意收缩的 public API。
README 也明确记录了边界：
- 没有 CLI；
- 没有 C API；
- 没有 prepared-statement interface；
- 没有 OS-level file locking 和 SQLite
-shm协议； - 并发协调只覆盖同一进程；
- 没有基于统计信息的查询成本估算；
- 单表最多选择一个 index，也没有 OR-merge。
Workspace version 是 0.0.0，发布功能关闭。在本次核验快照中，仓库也没有 release、CI workflow、license 文件或 security policy。这些是产品化缺口，不代表源码没有技术价值。
更关键的是，公开仓库无法复现 Cursor 私有的 100% 得分。README 表示针对真实 SQLite 的 differential testing 在仓库外完成。
sqllogictest 证明什么
SQLite 官方文档非常明确：sqllogictest 只问一个问题，数据库是否算出了正确答案。
它不测：
- 性能与索引选择是否最优；
- 磁盘和内存使用；
- 事务行为；
- 并发与锁；
- Unicode 和本地化。
因此，100% 是对特定查询分布的语义正确性证据，不是通用数据库证书。
这也是数据库版本的评估器接口问题：搜索压力会改进评估器测量的目标，契约之外的要求仍可能无人优化、无人看见。
SQLite 的发布证据是一张矩阵
SQLite 不依赖单一套件。官方测试策略组合四个主要 harness：
- TCL 包含 51,445 个 distinct cases，完整运行产生数百万次实例；
- TH3 包含 50,362 个 distinct cases，完整覆盖约 240 万次实例，并有更大的 release soak；
sqllogictest包含数百万查询；dbsqlfuzz同时变异 SQL 和数据库文件。
更广的体系还覆盖 OOM、I/O 错误、commit 期间断电、损坏文件、边界值、资源泄漏、并发、多平台、多种编译配置、回归与 fuzzing。TH3 会针对部署后的 object code 运行，并对 SQLite core 追求 branch 与 MC/DC coverage。
数据库正确性存在多条独立轴。一条查询在正常运行时返回正确行，并不能证明断电后不会丢数据。
三层生产就绪门禁
AI 生成系统可以使用三层独立门禁。
第一层：语义正确性
- conformance tests 与 golden results；
- 独立封存案例；
- 与可信实现做 differential testing；
- 用 mutation tests 证明套件能发现植入错误。
Cursor 的封存 SQL suite 主要提供这一层证据。
第二层：引擎韧性
- 崩溃恢复与耐久性；
- OOM、磁盘满、short write 和 I/O 故障注入；
- 损坏与对抗输入；
- 多线程和多进程锁；
- fuzzing、sanitizer、泄漏与竞争检测；
- 跨平台和跨编译配置；
- 性能与最坏资源上限。
这些故障并不是“查询答错一点”，而是不同类别的危险。
第三层：产品化
- 稳定且有文档的 API；
- 迁移和兼容策略；
- prepared statement 与必要语言绑定；
- CI、签名发布、provenance、license 和漏洞响应；
- 可观测性、回滚、运维所有权和支持承诺。
生产可用还包括工件失败后由谁负责。
下一次 swarm 实验应公开什么
未来实验若增加以下材料，会更容易独立审计：
- 精确任务规格和测试快照 hash；
- Harness、模型、prompt 和工具版本；
- 每次 run 的 seed、预算、日志与停止原因；
- 所有最终工件，而不是另一个 solo run；
- 第三方复现说明；
- 分别报告语义、韧性、性能和接口得分；
- 同时披露失败和人工干预，而不只报告最好结果。
不能因为 Cursor 没有复刻 SQLite 成熟发布体系，就否定整个实验。它证明的是更具体的进步：新版 swarm 在多种模型组合下显著减少冲突，并生成更连贯的软件。这说明 Harness 架构确实会改变长任务 Coding Agent 的经济性。
它还没有证明生成数据库适合保存生产数据。
常见问题
Cursor swarm 通过了 SQLite 的全部测试吗？
没有。它在 Cursor 的封存 SQL 逻辑测试中达到 100%。SQLite 还使用多套 harness 和其他韧性、发布测试。
公开 minisqlite 是 4,645 行的 Opus hybrid 结果吗？
不是。公开仓库来自 solo Opus 4.8，是另一个工件。
5,650 个 tests 等于完整覆盖吗？
不等于。这只是测试函数数量。完整覆盖还需要 statement、branch、condition、配置和故障发现能力等证据。
实验最明确地证明了什么？
新版 swarm 大幅减少协调浪费。即使最终 SQL 得分接近，冲突数量、crate 结构和代码规模也明显改善。