Cursor 用一群 Agent 重造 SQLite：智能体编排比模型能力更重要

核心实验

Cursor 工程团队公布了一项实验：一群智能体仅凭一份 835 页的 SQLite 手册，用 Rust 从零实现了一个数据库引擎。这些智能体没有源代码、没有测试套件、没有二进制文件、无法访问互联网。最终交付的数据库实现通过了全部预留的 SQL 结果一致性测试（sqllogictest，数百万条 SQL 查询）。

关键是采用了"预留测试集"（held-out test suite）——智能体集群事先不知道测试集存在，运行后还人工检查确认没有走捷径。

最值钱的发现：编排 > 模型

四种配置测试：

1. GPT-5.5 全前沿：规划+执行全用强模型 → 花费 $10,565
2. Grok 4.5 全前沿：成本较低的前沿基准
3. Opus 4.8 规划 + Composer 2.5 执行：前沿判断 + 便宜执行 → $1,339
4. Fable 5 规划 + Composer 2.5 执行：观察次级规划模型的效果

成本分布的关键洞察：在 Opus + Composer 组合中，规划器 Opus 只产生了很少 token，却占了约 2/3 成本；执行器 Composer 处理了绝大多数 token，只占 1/3。所有运行中 worker 至少消耗 69% token，多数组合超过 90%。

GPT-5.5 全前沿方案中仅执行者成本就达 $9,373；而 Opus 规划 + Composer 执行的整个执行者集群成本仅 $411。

结论：大型任务中真正需要前沿智能的环节不多（任务拆解、设计决策、权衡取舍），一旦前沿规划器把不确定性收敛为明确指令，更便宜的模型照着执行即可。

架构演进：从扁平到根规划者

迭代 1：扁平结构

所有智能体共享协调文件，主动认领任务，通过锁机制或乐观并发协同。结果陷入锁竞争，反复执行低风险重复任务，回避困难工作。

迭代 2：规划与执行分离

规划智能体探索代码库、递归创建任务；工作智能体专注边界明确的具体任务；裁判智能体判断是否继续迭代。但持续运行的执行者承担了过多工作（规划+研究+修改+合并+审查+判断完成）。

迭代 3：根规划者架构（最终方案）

• 根规划者掌握完整目标，递归委派任务为范围狭窄的工作单元，自身永远不参与具体实现
• 工作智能体完成后只向委派者返回一次交接结果
• 上下文隔离：规划器上下文不被底层细节塞满，worker 上下文全投入具体工作

Cursor 推测，swarm 的可扩展性很大一部分来自这种上下文效率，未必主要来自并行性。

新增机制：高吞吐软件生产线

• 定制版本控制系统：新蜂群产出峰值达每秒 ~1000 次提交（旧蜂群 Git 峰值每小时 ~1000 次），传统粗粒度锁无法应对
• 中立第三方智能体解决冲突
• 设计决策写入共享文档，代码通过可编译校验的引用追溯决策
• 观察角度有意错开的评审智能体
• 共享 "Field Guide"：智能体共同维护，供后续智能体继承使用

旧蜂群踩过的坑 vs 新蜂群

脑裂问题

两个规划器在不同区域各自实现同一功能，彼此不知情 → 冲突。新蜂群让规划器自己承担设计决策，不委派出去，确保不会让两个子树决定同一问题。

更棘手的是两个规划器明知对方存在仍围绕同一批文件博弈。新蜂群把决策记录在共享设计文档里，代码附带可编译校验、可追溯的引用。协调器合并矛盾文档时，引用将解决结果传递到下游。

文件膨胀

所有智能体不断向少数文件塞代码，无人主动精简。新蜂群允许执行者标记臃肿文件，暂时阻止新提交进入，由外部智能体负责拆分。

核心代码僵化

智能体从历史模式学会"不要触碰核心代码"。新蜂群允许智能体主动引入带说明的破坏性变更，编译错误将影响传导至整个系统，构建失败的智能体根据说明完成后续更新。

软件工程正在变成什么

AI 每次跃升都提高了工程师可工作的抽象层级：

• 自动补全 → 单行代码
• 早期模型 → 代码块
• 智能体 → 文件/功能层面
• 本次实验 → 规格说明：给 835 页手册，得到能通过测试的数据库实现

Cursor 认为，真正稀缺的资源是对意图进行准确描述的能力。当开发者只需设定目标、附上规范、定义评估器，剩下交给编排系统——软件工程正在变成一门定义目标的学问，而非实现目标的手艺。

现在的编程工具开始像编译器：通过中间步骤把源代码翻译成机器代码。区别在于编译器每一步保留语义，而 Agent 每一步都是概率性的，意图与执行之间始终存在裂缝。缩小这道裂缝正是 Cursor 过去一年反复解决的核心问题。

我的 take

这篇文章对 Rainsho 这样的前端工程专家有几个直接相关的启示：

1. 编排分层是工程思路，不是 AI 黑话：根规划者不碰实现、worker 不碰规划，本质就是关注点分离——前端团队里的架构师 vs 业务开发分工，只是对象从人变成了 Agent。这个分层思路可以直接迁移到前端工程化场景（比如设计 token 系统：架构层决策 + 自动化执行层）。

2. 成本分布数据很有实操价值：worker 消耗 90% token 但只占 1/3 成本，说明在 AI 辅助开发中，把"判断决策"和"机械执行"分给不同级别的模型/工具是真实可落地的成本优化策略。团队引入 AI 工具时，不应该一刀切用最贵的模型干所有事。

3. "规格说明成为工作基本单位"这个趋势对前端尤其成立：组件库的设计 token、API schema、Storybook stories 本质都是"规格说明"。如果 AI 能从规格生成实现，前端工程师的核心竞争力就从"写组件"转向"定义设计系统和接口契约"——这恰好是资深前端的强项。

4. 8 倍成本差距的警示：不是模型不够强，而是用法不对。这和团队管理一个道理——让最贵的人干所有事不一定产出最好，关键是分工编排。