Cursor 这次到底做了什么

2026 年 7 月 20 日，Anysphere 团队在 Cursor 官方博客发布了一篇由 Wilson Lin 署名的文章《Agent swarms and the new model economics》（Cursor 博文）。在这篇文章中，团队公布了一项新的工程实验：他们使用名为 Cursor Swarm 的 Agent 编排系统，完全基于 835 页 SQLite 官方手册，用 Rust 语言从零实现了一个兼容 SQLite 语义与存储格式的数据库引擎。

消息传出后，社区讨论很快分化成两种声音。不少人认为 AI 已经能成功重写 SQLite，随时可以替换生产环境里的数据库。这种解读把实验的焦点看偏了。SQLite 实验并不是在展示可以上线的生产软件，而是团队针对上一轮 Agent Swarm 暴露出的痛点，做出的一轮受控工程回应。

在上一次浏览器实验里，Cursor 曾部署几百个 Agent 并行运行一周，试图从零构建一个 Web 浏览器引擎，最终生成了超过一百万行 Rust 代码。在当时的 Harness Engineering 调研 中，我们记录过那个实验暴露的矛盾：代码行数和提交数量被当作 Agent 生产力的证明，系统却没有收敛成可用的软件。在这次博文中，Cursor 主动把浏览器项目定性为“完成了概念验证，但距离精致软件还差得很远”。单纯投入计算资源去膨胀代码量，如果缺少有效的行为验证和质量约束，海量代码很难转化成成熟的产品。

因此在 2026 年 7 月的新实验中，Cursor 团队选择回到旧版 Swarm 曾经陷入挣扎的同一项任务：根据 SQLite 规范重新编写 Rust 实现。他们把旧版 Swarm 与新版 Harness 放在完全相同的任务、相同的模型以及相同的时间预算下，进行受控对照。团队给 Agent 的输入是 835 页 SQLite 官方手册，同时扣留了 SQLite 的 C 源码、原版测试套件、编译后的 SQLite 二进制文件以及互联网访问权限。衡量标准也变了：团队使用包含数百万条带有已知标准答案 SQL 查询的隐蔽测试集 sqllogictest，替代了过去对代码行数或提交数量的统计。

这场受控对照拉开了明显的差距。搭载 Grok 4.5 的新 Harness 在 4 小时内达到了 sqllogictest 80% 的通过率；相比之下，旧版 Swarm 在第 2 个小时前就因为失控的代码冲突与接口漂移而被强制暂停。Cursor 报告称，在新 Harness 的支持下，所有的全新配置最终都达到了 sqllogictest 100% 的通过率。

为什么重写 SQLite 这样一个底层的复杂系统，不仅没有让新 Harness 陷入瘫痪，反而能比之前的浏览器项目揭示出更多关于 Agent 编排与 Harness Engineering 的本质规律？

SQLite

为什么难，又为什么特别适合当考题

要写出一个 SQLite，在底层实现上要越过很多硬门槛。SQLite 远不是一层简单的 SQL 接口封装，而是一个完整的嵌入式关系型数据库。开发者需要从零构建手写的词法与语法解析器、查询绑定与优化器、基于 Pull 架构的算子树执行器、系统目录、B-Tree 索引、数据页管理器、回滚日志与 WAL 编解码，以及磁盘上的 SQLite format 3 文件格式。这些子系统交织在一起，要求系统在 SQL 语义、事务 ACID 特性、数据类型隐式转换和磁盘持久化格式上维持严格一致。

然而，正是这样一个实现难度极高的底层系统，在作为 Agent Evaluation 的考题时，展现出了三种罕见的优越属性：

完整且稳定的规范说明：835 页官方手册定义了完备且确定的目标行为，完全排除了需求模糊或目标动态漂移的干扰。

高密度的确定性反馈：以 Rust 为实现语言，强类型系统、所有权检查和 Cargo 工具链提供了高密度的编译时反馈，每一次修改都能立刻得到编译器的明确报错或通过信号。

隐蔽且客观的行结果裁判：SQL 语言自带可自动化比对的“行结果正确性”。通过未见的 sqllogictest，外部评测系统可以在不依赖 Agent 自评的前提下，对最终输出的 SQL 查询结果进行逐行校验。

下图展示了 Cursor Swarm 针对 SQLite 手册建立的编排与评估机制：

Cursor Swarm 把 SQLite 手册分配给规划与执行角色，再由独立 SQL 测试集检查行为结果；测试分数不等于生产成熟度

需要明确的是，Cursor 报告的所有配置最终达到 100% 通过 sqllogictest，只代表系统在 SQL 查询行结果正确性这一特定测试集上表现完备。测试集得分不等于生产环境里的成熟度，因为该测试集并没有覆盖 C API 导出、操作系统级文件锁、复杂并发与崩溃恢复压力。

既然 SQLite 提供了一套规范确定、反馈密集的测试土壤，那么当 Agent 规模扩大到成百上千个并发单位时，系统的主要矛盾会发生怎样的转移，又为什么会让 Harness Engineering 的三条扩展线在 Swarm 中同时变难？

Harness

Engineering 的三条扩展线，在 Swarm 里一起变难

我们在 三个 Scaling 维度的统一框架 中建立过 Harness Engineering 的三条扩展线：

时间扩展性：系统能否在长生命周期的任务中保持上下文不失真、目标不漂移、错误不累积。

空间扩展性：系统能否通过部署成百上千个 Agent 并行工作，把投入的计算资源转化为有意义的工程吞吐量，而不被代码分支合并与冲突挤压所淹没。

人机交互扩展性：人类开发者能否从逐行审阅代码、手动纠正错误的微观操作中解放出来，转向在更高维度的规范、约束与 Evaluation 层面操纵 Agent 系统。

对于单个 Agent，或是像 Codex、Claude Code 在常规开发中所调用的少量 Sub-agent 来说，瓶颈主要在于单线程的时间序列与上下文窗口限制。然而，当 Agent 的规模扩大到数十甚至上百个并发运行单位时，工程的核心矛盾发生了转移。

在多 Agent 并行场景下，简单增加 Agent 数量并不等于提升工程进度。如果不控制协同开销，大规模 Swarm 会同时在三个维度上遭遇退化。多个 Worker 在没有统一设计基准时并行编码，会定义出互相冲突的接口格式与类型声明，导致系统在时间推移中迅速失控；几十上百个 Agent 同时提交改动，代码合并冲突会呈爆发式增长，在旧版 Swarm 的浏览器实验中，累积的合并冲突超过了 70,000 次，大量算力和时间被浪费在解决代码冲突上；而如果每一个 Worker 的产出都需要人类开发者进行 Code Review，人类的注意力带宽会瞬间被填满，人机交互的扩展性也会彻底失效。

正如我们在 Evaluation-First 文章 中所强调的，评测的对象从来不是孤立的大语言模型本身，而是由模型与 Harness 组合而成的整体系统。在 Swarm 场景下，实际的任务难度是“实现难度”与“协同难度”的乘积。

面对多 Agent 并行时接口碰撞、代码冲突与合并瘫痪的巨大协同成本，Cursor 的新 Harness 必须拿出具体的控制手段，才能把这三条扩展线重新理顺。

Cursor

怎样把三条扩展线放进同一套 harness

Cursor 并没有把实验总结为“大家都去用 Swarm”的抽象倡议，而是把空间、时间、人机交互与模型经济学融合成一套紧密的工程 Harness 机制：

空间扩展：建立了递归的任务树架构，严格划分 planner 与 worker 的角色边界。在 Cursor 的定义中，planner 仅负责分解目标、设计架构与分发任务，绝不编写具体实现代码；worker 仅负责执行被分发的叶子节点任务，绝不进行全局规划。为了防止架构分裂，系统通过共享设计文档和带有编译检查的引用维护全局约束。在合并协同上，Cursor 引入了专门的 Reconciler 和第三方 Merge Agent 机制，结合自动注入的 Field Guide/index.md，把合并冲突从旧实验的 70,000 多次大幅降低到新实验 4 小时内不到 1,000 次。

时间扩展：把庞大的数据库构建任务切碎为作用域受限的叶子节点，并为 worker 提供持久化的书面上下文。worker 只需要在局部的上下文内完成窄范围的代码编写与编译验证，大大降低了单 Agent 随时间推移而产生的目标漂移。这并没有从根本上消除长时运行中的上下文漂移，但系统通过架构约束缩短了单次执行的暴露时间。

人机交互扩展：人类工程师无需审阅每一个 worker 的微观代码，而是把控制力上移到最上游：将既有的 835 页 SQLite 手册与编译、架构约束转成任务边界，并保留外部独立的裁判 sqllogictest。人类通过定义 spec 与 Evaluation 来操纵系统。

经济学与模型分工：实验揭示了模型分工在经济学上的影响。Cursor 发现，把昂贵的前沿模型部署在任务树的 planner 节点进行架构分解，而让更便宜、更快速的模型充当 worker 舰队执行具体叶子节点，可以在保持 100% 测试通过率的同时大幅降低总成本。在 Cursor 报告的受控对照中，GPT-5.5 独挑大梁的单次运行成本高达 $10,565，而 Opus 4.8（作为 planner）加上 Composer 2.5（作为 worker）的混合方案总成本仅为 $1,339（其中 worker 舰队仅花费 $411）。在另一项测试中，单独使用 Grok 4.5 作为 planner 与 worker 也在 4 小时内达到了 80% 的通过率。需要明确的是，这是针对该特定任务实验的报告数据，不能简单外推为通用场景下固定 15 倍的成本节省。

在底层机制上，Swarm 是一套由多个 Agent 组成的分布式协调控制平面，无需赋予其魔力模型标签。只有在必须依靠共享控制平面来解决庞大冲突与分工时，普通 Sub-agent 才有升级为 Swarm 的必要。

这套控制平面能够高效运转，前提在于任务拥有确定的规范、密集的机制反馈以及可自动化检验的规则。一旦脱离了这个前提条件，看似强悍的 Harness 就会面临截然不同的工程现实。

这是一次秀肌肉，不是大多数产品团队的日常

尽管 Cursor 的 SQLite 实验在 Harness Engineering 上取得了突破，但我们必须客观评价其工程边界：它是在理想条件下展示能力上限的一场工程演示，无法直接当作大多数产品团队日常工程的通用解法。

为什么说它不是产品团队的日常？因为真实世界的产品开发与 SQLite 重写有着本质的不同：

SQLite 重写的核心特征在于“目标高度确定”：它有 835 页长达多年的成熟规范，有确定的磁盘格式和 SQL 语义。工程的主要矛盾是“如何高效实现已知规范”。

大多数真实产品工程的核心困境在于“确定要构建什么”：需求在不断变化，用户反馈在动态调整，系统需要与复杂的遗留系统集成，处理边界模糊的副作用、权限控制与跨进程并发。在这种场景下，意图本身是不完整的。

如果在需求尚不明确、约束尚未固化的产品早期强行引入大规模 Swarm，Swarm 强大的代码生成吞吐量只会以极高的效率成倍放大错误的意图，产生大量不可维护的代码。

这一点在 Cursor 公开的代码仓库 cursor/minisqlite 中得到了印证。审阅该仓库可以发现：

该代码库来自 solo Opus 4.8 的运行产物，没有采用成本对比实验中的 Opus 4.8 + Composer 2.5 混合架构。

尽管代码库包含了约 200,000 行 Rust 代码、14 个 crate 和 5,650 个测试，但在接口与生产功能上存在明确的边界：它没有任何 CLI 命令行工具、没有 C API 导出、没有 prepared statement 预编译接口，且只支持进程内并发协调，完全没有操作系统级跨进程文件锁与 -shm 共享内存协议（参见 minisqlite GitHub Issue #1 讨论）。

关于市场上对“Rust 重写 SQLite”的误解也需要澄清：Cursor 的 minisqlite 是一个研究性的生成产物，与 Turso 团队主导的 Limbo/Turso Database 项目属于完全不同的组织与工程路线，不能混为一谈。

下图清晰地划分了从 SQL 行正确性到生产级数据库之间的多维工程边界：

从 SQL 行结果正确到可替代生产 SQLite 之间，还要分别检查接口兼容、跨进程并发、性能和长期维护

最终，我们可以为工程团队得出一个清晰的选择法则：

当产品意图尚在探索、需求与约束随用户反馈不断变化时，应当使用单个 Agent 或少量 Sub-agent（如 Codex、Claude Code）配合人类开发者的紧密反馈；

只有当产品的意图与规范已经高度固化、任务可以被拆分为独立的机械可验证单元，且系统协调成本明显低于并行带来的速度提升时，投入资源去构建和运行一个复杂的 Swarm Harness 才真正具备工程合理性。