Cursor蜂群实验：AI用Rust从零复刻SQLite的成本启示

一场颠覆认知的AI协作实验

Cursor最近公布了一组内部蜂群（Swarm）实验，结果或许会改变我们对「如何让AI更会写代码」的固有认知。实验设定极为苛刻：让多批AI智能体在拿不到SQLite源码、测试套件、可执行文件和互联网的情况下，仅根据一份835页的官方文档，用Rust从零实现一个数据库引擎。

值得先厘清「蜂群」这一概念的来源。蜂群（Swarm）是多智能体系统（Multi-Agent System）的一种形态，灵感来自蚂蚁、蜜蜂等群居生物的集体行为——单个个体的能力极其有限，但通过局部信息交换与协调，群体层面涌现出远超个体的复杂能力。在AI工程中，蜂群通过角色分工（规划器、执行器、审查器等）让数十甚至数百个智能体并行处理任务，从而突破单个大模型上下文窗口和推理深度的固有限制。这与单纯把一个巨型模型「喂」更多信息，是两条截然不同的技术路线。

这不是一个普通的CRUD应用。SQLite是一个完整的关系型数据库引擎，需要处理查询解析、查询优化、事务管理、并发控制等复杂环节。更严苛的是，Rust以编译检查严格著称，代码要成功编译必须满足所有权、借用和生命周期规则，而业务逻辑正确性还需另行通过测试验证。

之所以选择SQLite作为试金石，是因为它是全球部署最广的数据库引擎，被嵌入到几乎所有智能手机、浏览器和操作系统之中，遵循ACID事务特性，并以「单文件、零配置、无服务器」的架构著称。它的源码虽然只有约15万行C代码，却包含了完整的SQL编译器、字节码虚拟机（VDBE）、B-Tree存储引擎和页面缓存管理器。让AI在看不到源码的情况下重建这样一套系统，等于强迫它真正理解数据库理论，而不是靠模式匹配去抄袭现成实现——这正是这场实验的含金量所在。

最终，两种不同配置的AI团队都通过了Cursor保留的SQL Logic Test。但真正值得关注的，不是「AI能不能写数据库」，而是不同模型分工造成的巨大成本差异——这背后藏着AI工程化的经济学逻辑。

7.9倍成本差：AI模型分工的经济账

实验对比的核心，是同一套蜂群框架下的两种模型分配方式：

• 全GPT-5.5配置：所有环节都用前沿模型，总花费高达 10,565美元
• 混合配置：由Opus 4.8负责规划，Composer 2.5负责执行，仅花费 1,339美元

两者成本相差约7.9倍，但都通过了同样的测试。这组数据的关键在于Token消耗与成本的错配。

在混合配置中，Worker（执行者）消耗了大部分Token，但成本只有411美元，约占模型成本的三成；而规划器虽然用的Token更少，却花费了928美元。对比全GPT-5.5配置，仅Worker环节就花费了9,373美元。

这说明一个反常识的结论：把昂贵的前沿模型部署到所有执行环节，未必是经济上最合理的选择。 在大规模软件工程中，真正需要前沿智能的环节其实非常少——最初的任务分解、架构设计和权衡取舍。一旦这些不确定性被消除、变成明确的指令，后续的执行工作完全可以交给便宜快速的模型完成。

这背后其实是大模型定价机制的直接体现。目前主流大模型按Token计费，前沿模型（如顶级推理模型）的单价往往是轻量级模型的数倍到数十倍。同时，推理密集型任务（如架构规划）会触发更长的思维链和更高的输出Token消耗，这解释了为什么规划器用了更少的Token反而花了更多的钱——它调用的是最昂贵的「大脑」。把智能按需分配，本质上是在做一种算力的成本优化。

AI团队协作的三大灾难

很多团队都在做agent，希望让AI自动把需求变成代码。但只要任务变复杂，AI就容易胡言乱语或陷入死循环。大家的普遍做法是拼命扩大上下文窗口、让模型处理更多任务。但Cursor这次实验提示：方向可能搞反了。

当几百个AI像团队一样同时开工时，Cursor发现AI团队的失效模式与人类完全不同，并遭遇了三大灾难。

脑裂与规划器征用

第一个问题是「脑裂」：两个互不知情的规划器会在不同位置重复设计同一个概念。Cursor主要通过提示约束解决——关键设计必须由规划器自己决定，且被委派的子树不能重复决定同一个问题。

更棘手的是「规划器征用」：两个规划器明明知道彼此存在，却仍在同一批文件上来回修改。为此Cursor引入了共享设计文档、带编译检查的引用，以及负责协调冲突的Reconciler。

合并冲突

AI写代码很快，但处理合并冲突极差：要么直接覆盖别人的代码，要么把自己的改动全扔了。Cursor的解决方案是引入一个中立的第三方AI，它不写业务代码，唯一的工作就是处理合并冲突——相当于人类团队里全自动化的「Merge管家」。

巨无霸文件

总有些核心文件被所有人往里塞代码，最后变成几万行的怪物。人类工程师会本能地绕开，但AI不会害怕，会继续往里塞直到系统被拖垮。Cursor给Worker加了权限：可以给臃肿文件打标签，一旦打上标签系统就锁死该文件禁止提交，再派专门的AI将其分解成小模块。

从Git到每秒千次提交的基础设施

支撑这套协作的，是全新的基础设施。此前基于Git的浏览器蜂群峰值约为每小时1000次提交，而Cursor新系统的峰值提高到约每秒1000次。为了承载如此惊人的写入密度和实现专用协调机制，团队重新开发了内部版本控制系统（VCS）。

这里需要理解为什么Git扛不住。Git采用内容寻址存储和快照式提交模型，是为人类开发者的低频、异步协作而设计的——即便在最繁忙的开源项目中，提交也是以分钟乃至小时为单位。当写入频率骤然跃升到每秒千次时，Git的文件锁机制、引用（ref）更新的串行化，以及后台垃圾回收（GC）都会迅速成为致命瓶颈，甚至引发数据竞争和索引损坏。这正是Cursor不得不抛弃Git、从零自研VCS的根本动因——现有工具链的设计假设，已经无法匹配AI群体的工作节奏。

框架改进的价值同样惊人：在Opus 4.8加Composer 2.5配置下，新版框架以**4,645行引擎代码达到100%通过率；而同样的模型组合在旧版框架中，需要19,013行代码才只获得97%**的分数。这清晰地说明——提升更多来自蜂群框架的改进，而非某个单一模型的绝对能力。

需要注意的是，这次实验同时改变了VCS、提示词、审查和冲突处理等多项机制，因此还不能把全部提升简单归因于认知分工。

让AI自己写「排坑指南」

实验中还有个有趣的细节——Cursor称之为「Field Guide（野外指南）」。这是一份由智能体自主编写、在启动时自动注入给每个智能体的文档。

原因在于：模型的权重是冻结的，它们在运行中遇到的坑如果不记录下来，下一个智能体还会掉进同一个坑。这相当于让AI自己给自己写排坑指南，而真正值得记录的，恰恰是那些出乎意料的情况。

这个机制实际上触及了当前大模型的一个根本局限——推理阶段的模型是「无状态」的，它的参数在训练完成后就被固化（即权重冻结），无法在使用过程中从经验里学习。业界通常通过外部记忆来弥补，例如向量数据库、检索增强生成（RAG）或持久化的上下文文档。Field Guide正是这种「外挂记忆」思路的体现：它把群体在实践中踩过的坑沉淀为可复用的显性知识，让整个蜂群系统在单个模型不更新参数的前提下，也能实现某种意义上的「集体经验积累」。

在错误审查上，Cursor发现没有任何单一审查视角能发现所有问题：有的看对话记录，有的看输出结果，有的看代码库。但彼此低相关的视角叠加后能覆盖更多错误——就像自动驾驶不依赖单一雷达，而是融合激光雷达、摄像头、超声波的数据。由于审查成本远低于被审查的工作，投入在审查上的算力回报极高。（不过这些机制目前尚无公开的独立消融实验或量化收益。）

AI不是在写代码，而是在做「编译」

从工程视角看，最深刻的洞察是：Cursor的蜂群本质上是一个「概率性编译器」。

传统编译器（如GCC、LLVM）把确定性的高级语言翻译成机器指令，过程严格且语义不变。而Cursor的智能体蜂群：

• 输入：自然语言写成的需求文档（835页SQLite手册）
• 规划器：做「前端编译」，把自然语言解析成任务树和架构设计
• Worker：做「后端编译」，把架构设计翻译成具体代码
• 冲突解决、代码审查、文件拆分：相当于编译器里的各种优化Pass

这个「概率性」的定语点出了它与传统编译器的本质分野。GCC、LLVM这类编译器是确定性的：同样的源码在同样的配置下，永远产出完全一致的机器码，语义严格守恒。而基于大模型的蜂群则是概率性的——同样的需求文档，两次运行可能产出结构不同的代码，甚至可能出错。这既是它的弱点（不可复现、需要大量测试和审查兜底），也是它的独特能力（能处理模糊、不完整、自然语言表述的输入，而这恰恰是传统编译器完全无能为力的领域）。

这个类比也呼应了经济学家科斯的「企业性质」理论：企业之所以存在，是因为内部协调成本低于市场交易成本。当几百个AI一起工作时，它们之间的协调成本（合并冲突、脑裂、审查）急剧上升，而共享设计文档、决策引用、中立冲突agent等机制，本质上都是在降低这个多智能体系统的内部通信开销。

给agent开发者的启示

这给所有做agent开发的人提了个醒：别光盯着模型的「智商」，多想想怎么降低智能体之间的沟通成本。

软件工程的协作方式也在快速演进：从一行一行写，到Copilot时代一块一块写，再到agent时代一个文件一个文件地写。而Cursor描绘的未来是——工作的基本单位变成了「需求文档」。

Cursor预期，准确描述意图将成为越来越稀缺的能力。高级工程师的重心可能从亲自处理每一处语法细节，逐渐转向明确目标、边界条件、架构约束和验收标准。但架构能力不会消失，因为一份高质量的规格本身就依赖这些知识。

最后需要客观说明：通过SQL Logic Test只代表查询结果正确性，它不评估性能、索引效率、磁盘和内存消耗、事务行为或并发。因此这个成绩不能等同于完整复制了生产级SQLite的全部功能、兼容性和可靠性。

用一句话总结：AI没有终结软件工程，它只是把人类协作的规则，用代码重新写了一遍。

核心要点