拆解 Cursor 多 Agent 重造 SQLite：规划-执行分离架构如何让成本降 8 倍

Cursor 团队最近放了一个实验：只给一群 AI Agent 一份 835 页的 SQLite 官方手册，不提供源码、测试集、二进制文件，也不联网，用 Rust 从零实现一个数据库引擎。最终，新蜂群架构通过了全部预留的 SQL 一致性测试；更关键的是，把「前沿模型做规划 + 低成本模型做执行」组合起来，成本从全用前沿模型的 10,565 美元降到 1,339 美元，差了将近 8 倍。

这件事对开发者的直接启发不是「Agent 可以替代程序员写数据库」，而是：当任务规模变大，Agent 怎么编排，比用哪个模型更重要。规划-执行分离、层级任务树、共享设计文档、可验证的引用链，这些工程机制正在成为新一代 AI 编程的基础设施。

如果你正在用 Cursor/Windsurf/Cline 做复杂项目，或者想把多个 Agent 串起来处理代码迁移、模块重构、测试补全，这套架构的思路可以直接抄作业。

核心思路：把任务树拆成「规划器」和「执行者」

单个 Agent 包揽大任务时，会出现一个经典困境：上下文要同时装下全局目标、当前子任务、历史决策、代码细节。时间一长，它要么盯死局部丢全局，要么看全局时局部潦草。Cursor 的解法是按树状结构拆分角色：

规划器（Planner）：只负责拆解任务，不写实现代码。它拥有完整目标，递归生成边界清晰的工作单元，然后委派出去。
执行者（Worker）：只负责实现被委派的具体任务，不参与规划。它可以把全部上下文都投入到一小块代码里。
裁判/审查者（Referee / Reviewer）：判断任务是否完成、是否需要回滚，提供多个错开视角的审查。
冲突协调者（Conflict Resolver）：中立的第三方 Agent，专门处理合并冲突和跨规划器的设计矛盾。

这种拆分本质上是在做上下文隔离。规划器不被底层实现细节塞满，执行者不被全局目标分散注意力。Cursor 认为，这其实是蜂群可扩展的主要来源，而不只是并行度。

用更工程化的语言描述，整个系统可以抽象成一条流水线：

目标 + 规格说明
    ↓
Root Planner（根规划器）
    ↓ 递归委派
子规划器 / 工作单元
    ↓
Worker Agent（实现具体模块）
    ↓
共享设计文档 + 可编译校验引用
    ↓
冲突协调器 + 审查视角叠加
    ↓
Held-out Test Suite（预留测试集）

这套架构不是只在 SQLite 实验里跑过。Cursor 说他们已经用类似结构做浏览器实现、数学问题求解、GPU kernel 优化、开源漏洞挖掘、测试覆盖率提升，以及生成训练数据。

关键机制 1：共享设计文档 + 可编译校验的引用

多 Agent 协作最怕「脑裂」：两个规划器在代码库不同部分实现了同一个概念，彼此不知道。传统合并工具只能解决文本冲突，解决不了语义冲突。

Cursor 的方案是：

规划器把设计决策写进共享设计文档。
依赖该决策的代码必须附带一个引用，指向对应文档条目。
这个引用可以被编译器校验。如果设计文档被协调器合并/修改，引用链会把解决结果传递到所有下游代码。

这就像给架构决策做类型检查。人类团队里的 ADR（Architecture Decision Records）是手写的、容易过时的；这里的 ADR 被当成一等公民，由 Agent 维护、由编译器强制执行。

一个简化的伪代码示例：

// 代码中的设计决策引用：引用设计文档第 B-07 条
// @design-ref: B-07 "SQL 表达式求值统一使用 Row 结构体"

#[derive(Clone, Debug)]
pub struct Row {
    // ... 字段定义
}

pub fn eval_expr(expr: &Expr, row: &Row) -> Value {
    // 实现细节
}

在真实实现里，引用可能以注释+静态检查工具的形式存在。重点是：让设计意图可追踪、可合并、可验证，而不是靠 Agent 在对话历史里记住。

关键机制 2：面向 Agent 的版本控制系统

传统 Git 在每小时 1000 次提交时还能撑，但 Cursor 的新蜂群峰值达到每秒约 1000 次提交。Git 的粗粒度锁和合并模型直接失效。

旧蜂群在 Grok 4.5 运行中，两小时内产生了 68,000 次提交，积累了超过 70,000 次合并冲突；最夸张的一个文件被 1,173 个不同 Agent 修改了 7,771 次冲突。新蜂群跑满四小时，冲突不到 1,000 次。

所以 Cursor 自己写了一套 VCS。它不只是为了提高吞吐量，更是把冲突协调机制下沉到版本控制层：

提交粒度足够小，能暴露冲突。
冲突一旦发生，调用中立第三方 Agent 解决。
臃肿文件被标记后，阻止新提交进入，由外部 Agent 拆分模块。

这给我们的启发是：如果你打算让多个 Agent 同时写一个代码库，先别急着上 Git 共享分支，先想清楚冲突发现、冲突解决、模块化边界这三件事。否则 Agent 越多，合并地狱越严重。

关键机制 3：破坏性变更也要被允许

在人类维护的代码库中，Agent 倾向于「不碰核心代码」。这会导致核心模块逐渐僵化。Cursor 的解法是：允许 Agent 主动引入带注释的破坏性变更。

流程如下：

某个 Agent 判断核心部分需要改动，提交一个补丁，并附带说明注释。
编译器把变更影响传导到整个系统，相关模块构建失败。
其他 Agent 读到注释，理解原因，更新各自负责的代码。

这相当于把「重构」从人类专家专属行为，变成 Agent 蜂群里的标准流程。关键前提是：变更必须带解释，失败必须可传播。

关键机制 4：用预留测试集做裁判，而不是优化目标

Cursor 用 SQLite 的 sqllogictest 作为评分标准。这套测试包含数百万条 SQL 查询，用来验证不同数据库引擎执行相同查询是否返回一致结果。

重点来了：Agent 事先不知道这套测试集的存在。每次运行后，团队还会人工审查代码和运行过程，确保 Agent 没有作弊或只针对测试做优化。

这对开发者做 Agent 项目非常重要。如果你让 Agent 自己写测试，它很可能只写自己过得去的；如果你用固定的、Agent 看不见的测试集，才能真正衡量它是不是在解决问题。

实践中你可以这样设置：

# 保留一部分测试用例不告诉 Agent
# 公开测试集：用于 Agent 自我迭代
public_tests/

# 预留测试集：只在最终评估时运行
held_out_tests/

# 评估脚本
python evaluate.py --engine ./target/minisqlite --tests held_out_tests/

预留测试集是避免「Agent 自我欺骗」的最简单手段。

模型经济性：规划器贵，执行者便宜

Cursor 测试了四种模型组合，结果都通过了测试集，但成本差异巨大：

配置	规划器	执行者	大致成本	结果
全前沿	GPT-5.5	GPT-5.5	~$10,565	通过
成本基线	Grok 4.5	Grok 4.5	中等	通过
混合方案 A	Opus 4.8	Composer 2.5	$1,339	100% 通过
混合方案 B	Fable 5	Composer 2.5	略高	通过

数据表明：

Worker 至少消耗 69% 的 token，多数情况下超过 90%。
但规划器 token 虽然少，却占了约三分之二的成本。
真正需要前沿智能的环节只有：任务拆解、设计决策、关键权衡。
一旦规划器把不确定性收敛成明确指令，便宜模型照着执行就行。

结论很直白：不要全链路用大模型。把不确定性高的部分交给强模型，把确定性高的部分交给快模型。

动手建议：怎么在自己的项目里复用这套思路

这套架构不是只有 Cursor 能玩。你在处理复杂代码任务时，可以按下面步骤逐步落地：

1. 从「任务分解」开始

不要直接让 Agent 写一个完整模块。先让强模型输出一个层级任务树：

目标：为现有 Django 项目添加 OAuth2 登录
├── 子任务 1：添加依赖并配置 settings
├── 子任务 2：实现 OAuth Provider 适配器
├── 子任务 3：实现用户绑定/创建逻辑
├── 子任务 4：添加登录路由和回调路由
├── 子任务 5：编写单元测试
└── 子任务 6：编写集成测试

2. 给每个任务加验收标准

每个叶子节点都要带明确的完成标准，比如：

能够通过 pytest tests/oauth/ 的公开测试集。
路由 /auth/callback/ 返回 302 并设置 session["user_id"]。
不引入新的未处理异常类型。

3. 用便宜模型做执行，强模型做审查

执行者：用 Claude 3.5 Sonnet / GPT-4o-mini / DeepSeek-V3 写代码。
规划者/审查者：用 Claude Opus 4 / GPT-5.5 / Kimi K3 做任务拆解和最终审查。

4. 保留预留测试集

把 20% 的测试用例藏起来，只在最终评估时跑。这能防止 Agent 过拟合到可见测试。

5. 别让多个 Agent 直接写同一个文件

如果必须并发，先按模块划分清晰边界。否则你会遇到旧蜂群那个「一个文件 7,771 次冲突」的噩梦。

资源链接

Cursor 官方博客：智能体蜂群与新的模型经济学
实验代码库：github.com/cursor/minisqlite
SQLite 测试工具：sqllogictest
早期实验：Self-Driving Codebases
相关讨论：InfoQ 报道

一句话总结

当任务复杂到单个 Agent hold 不住时，「强模型做规划、便宜模型做执行、共享设计文档做协调、预留测试集做裁判」这套组合，比单纯堆模型能力更划算，也更可控。Cursor 的 SQLite 实验已经把路线图画出来了，剩下的就是在你自己的代码库里照着拆。