Cursor Agent Swarm 通过树状分解用 Rust 构建 SQLite，测试通过率达到 80%

Cursor 表示，其 agent swarm 在四小时内用 Rust 构建 SQLite，测试通过率达到 80%。该系统采用树状分解，将规划和实现任务分配给不同的 agent。此前的 swarm 陷入冲突，并在运行未满两小时时被终止。

这一结果之所以重要，是因为 Cursor 并非只是将更多 coding agent 放进同一个代码仓库。它改变了这些 agent 分工、保留架构决策、解决冲突以及审查累积代码的方式。因此，这项实验对编排能力的检验并不亚于对模型智能的检验。

Cursor 早期的 swarm 已经从零构建了一个浏览器引擎。该项目产出了可运行的软件，但 Cursor 承认其距离完善仍相去甚远。SQLite 实验提出了一个更尖锐的问题：当数百个 agent 同时修改一个紧密耦合的系统时，结构化 swarm 能否保持一致性？

这个问题仍未有定论。实验由 Cursor 自行实施并评分，尚无独立审计确认其核心结果。在一套 SQL 测试中获得 80% 的分数，也不能证明其具备完整的 SQLite 兼容性、生产环境安全性或同等性能。

尽管如此，这一对比仍为 AI 软件开发中日益突出的一个问题提供了异常具体的证据。增加 agent 会提高产出，但也会成倍增加分歧。Cursor 的解决方案是在受控层级结构中，为规划、执行、协调和审查分别设置明确的位置。

Cursor 的 Agent Swarm 用 Rust 构建 SQLite，完成度达到 80%

关键变化并不是 swarm 规模更大，而是通过组织 swarm，防止局部决策压倒整个项目。

Cursor 于 2026 年 7 月 20 日公布了实验结果，再次挑战此前系统未能完成的任务。该任务要求以数据库文档作为规范，用 Rust 重新构建 SQLite。

根据 Cursor 的 swarm 实验，agent 获得了长达 835 页的 SQLite 手册，但没有获得 SQLite 的源代码、可执行二进制文件、测试套件或互联网访问权限。Cursor 表示，这种隔离措施防止了直接复制，也减少了针对可见测试进行优化的机会。

团队使用 sqllogictest 评估最终生成的数据库。该框架会在多个数据库引擎上运行 SQL 语句，并将结果与已知答案进行比较。该测试框架包含数百万条查询，覆盖广泛的 SQL 行为。

swarm 并不知道 Cursor 将使用哪些测试。Cursor 表示，每次运行后，研究人员都会检查代码和 agent 活动，确认其中是否存在投机取巧的行为。他们还会检查实现工作是否广泛覆盖整个系统，而非专门针对可能出现的测试用例。

在这些条件下，一个新的 Grok 4.5 swarm 在四小时后达到了 80% 的 SQL 测试通过率。旧版基于 Grok 的 swarm 则因协调故障不断加剧，在运行未满两小时时便被终止。

四小时并非最终上限。在四种模型配置中，新系统截至该时间点的得分介于 73% 至 85% 之间。Cursor 表示，所有新配置最终都在保留测试套件上达到了 100%。

这些后续结果表明，标题中的 80% 是一个进度节点，而非实验报告的最高分。该数字仍具有参考价值，因为它比较了同一模型在固定时间内使用两种编排系统时的表现。

Cursor 测试了四种组合。其中两种使用同一个模型完成规划和实现，另外两种则将前沿规划模型与速度更快的工作模型搭配使用。

在所有测试组合中，新 swarm 的表现都优于旧 harness。这种一致性支持了 Cursor 的核心主张：除模型选择之外，系统设计也会影响性能。

不过，这些证据来自 Cursor 自己的基准测试流程。该公司已通过 MiniSQLite 仓库发布了一个生成的实现，但尚未将每次运行都作为完整的可复现套件公开。

该仓库让外部开发者至少可以检查一个输出结果，但无法复现完整实验，包括基础设施、prompt、模型快照、隐藏评分数据以及人工审查决策。

这一区别很重要。Cursor 报告的是一项引人注目的内部结果，而不是一个经独立验证、可取代 SQLite 的方案。

树状分解改变了协调模型

树状分解为 swarm 建立了一条责任链，将全局判断与范围狭窄的实现工作分离开来。

Cursor 的设计从一个根目标开始。规划 agent 将该目标划分为更小的分支，再递归委派每个分支。工作 agent 位于叶子节点执行任务，此时任务范围应足够狭窄，可以直接实现。

规划 agent 不编写生产代码，其上下文始终聚焦于需求、依赖关系、架构选择和任务边界。工作 agent 不重新设计整个系统，而是接收一项有限任务，并将上下文用于完成该任务。

这种结构针对的是长期运行 agent 中常见的一种失败模式。单个 agent 必须在处理越来越多实现细节的同时牢记最初目标。随着上下文被填满，它可能会失去局部精度或全局方向。

并行 agent 并不会自动解决这一问题。如果缺乏协调，它们可能会重复实现同一功能、选择互不兼容的接口，或覆盖彼此的工作。更多并行任务反而会产生更多修复工作。

树状分解限制了哪些 agent 可以作出哪类决策。Cursor 要求规划 agent 解决共享设计问题，而不是将其分别委派给独立的工作 agent。它还要求规划 agent 避免将同一个架构决策分配给多个分支。

这种分工将一个无组织的群体转变为层级结构。系统仍然使用大量 agent，但它们并不都对项目的每个部分拥有同等权限。

新的 swarm 还会在共享设计文档中记录重要决策。依赖这些决策的代码包含经过编译检查的引用，指向相应文档。当两个规划 agent 相互矛盾时，协调 agent 可以合并这些决策并传播解决方案。

这一机制解决了 Cursor 所称的脑裂设计问题。当不同规划 agent 在同一代码库中实现同一概念的不同版本时，就会发生脑裂。每个版本在局部看来都可能合理，但会导致整个系统不一致。

SQLite 的运行结果揭示了二者的差异。旧版 Grok swarm 扩展到了 54 个 Rust crate，其中包括三个独立的 SQL 包。crate 是 Rust 的包单元，通常代表一个库或主要组件。

新 swarm 很早就确定使用九个 crate，此后没有继续增加。这种更精简的结构并不必然意味着软件质量更高，但它表明规划 agent 就一套架构达成了共识。

Cursor 认为，上下文效率比原始并发量更重要。每个规划 agent 保留更高层次的视角，而每个工作 agent 都获得足够的上下文来执行一项有明确边界的任务。该层级结构让上下文随任务复杂度同步扩展。

这类似于编译器流水线。高级规范经过多层中间表示，最终转化为可执行输出。Cursor 的 swarm 将意图转化为任务树、实现任务、协调后的变更以及经过审查的代码。

与编译器不同的是，每次转换仍具有概率性。规划 agent 可能误解规范，工作 agent 可能误读任务，审查 agent 也可能批准错误的实现。

外围控制机制旨在减少这些错误，但无法使整个过程变得确定。

对工程团队而言，实际启示并不局限于这项基准测试。agent 的表现取决于需求、决策和例外情况能否在适当的范围内持续可用。可搜索的知识库在人类主导的工作中发挥着类似作用。

Cursor agent swarm 能够用 Rust 构建 SQLite 并达到 80% 的测试通过率，是因为层级结构缩小了每个 agent 所需掌握的信息范围。这一结果表明，编排正成为自主编码领域的一项核心工程学科。

旧版 Swarm 产生的是活动量，而非稳定进展

Cursor 的对比颠覆了一种常见假设：更高的 agent 活动量可能意味着协调失败，而非生产力提升。

旧版 Grok 4.5 在运行的前两小时内生成了 68,000 次提交。Cursor 报告称，这一速度约为新版本的 70 倍。从表面的仪表板来看，旧版 swarm 的活跃程度似乎高得多。

但其他证据呈现出不同的情况。旧系统在 Cursor 将其终止前累积了超过 70,000 次合并冲突，而新版本在四小时内记录的冲突不到 1,000 次。

旧版本中的冲突频率也在不断加快。agent 面对的并非固定的集成积压，而是随着代码仓库变化，以越来越快的速度制造分歧。

其中一个文件成为了特别严重的瓶颈。Cursor 表示，共有 1,173 个 agent 修改过该文件，产生了 7,771 次冲突。相比之下，新版本中争议最严重的文件仅出现了 47 次冲突。

这些数字反映的是协调崩溃。工作 agent 在缺少共享所有权、稳定边界或高效吸收并发变更机制的情况下，反复进入同一区域。

普通 Git 工作流并非为这种速度而设计。人类团队依靠 pull request、代码所有权、审查队列和沟通来协作。当自动化工作 agent 持续生成变更时，这些机制就会变得不切实际。

Cursor 表示，其早期浏览器 swarm 使用 Git 时的峰值接近每小时 1,000 次提交。新基础设施的峰值可达到每秒约 1,000 次提交。为处理如此高的负载，该公司从零构建了专用的版本控制系统。

该系统不仅用于存储补丁，还成为冲突显现以及专用 agent 介入的层级。

当两个工作 agent 编辑重叠代码时，Cursor 不要求其中任何一个工作 agent 吸收另一个的完整上下文，而是由中立的合并 agent 代表双方解决冲突。它负责的是集成，而非功能所有权。

swarm 还会监控“巨型文件”，即吸引过多工作 agent 修改的文件。一旦 agent 将某个过度膨胀的文件标记出来，系统便会阻止更多提交，同时由另一个 agent 将其拆分为更小的模块。

这种响应非常重要，因为文件结构本身会成为协调基础设施。模块化边界不仅能提升可读性，还能减少相互争夺同一产物的工作 agent 数量。

Cursor 还发现，agent 往往会避免修改核心代码。coding model 学习到的惯例倾向于进行小规模、非破坏性的补丁，尤其是在现有代码仓库中。

这种谨慎可能会保留有缺陷的基础。因此，当核心设计需要修改时，Cursor 允许 agent 在其分配范围之外进行一次有针对性的破坏性变更。

agent 会在变更旁留下说明。随后，编译器错误会将受影响的工作 agent 引导至该说明，使它们能够更新依赖代码。

这种方法将 Rust 的类型系统用作协调通道。编译器能够迅速暴露不兼容的接口，并提供可操作的错误信息。这些错误有助于智能体发现全局决策在哪些地方使局部假设失效。

一篇针对早期智能体群实验的独立架构评析指出了这一确切挑战。能力出众的智能体各自可以做出局部合理的选择，但这些选择在全局层面可能无法协同运作。共享的模型行为会产生相关性，而非协调性。

Cursor 的新架构似乎正是为回应这一批评而设计。它引入了全局决策权、持久化设计记录、专门的协调机制以及自动化约束执行。

这使得“智能体群”这个术语略显误导。该设计并非一组通过自发涌现实现协调的独立对等个体，而是一个具备层级、规则、记录和执行机制的受管理组织。

这种区别并不会削弱该实验的意义，反而解释了它为何表现更好。

审查与共享记忆防止错误不断累积

树状分解能够产生清晰的任务分配，但持续推进取决于能否在其他智能体基于错误继续构建之前发现问题。

长期软件开发会放大早期错误。一个错误的接口可能扩散至数十个模块。临时变通方案可能逐渐被当作既定需求。薄弱的抽象可能吸引越来越多的代码，直到替换它的成本变得高昂。

Cursor 使用了多个从不同视角审查工作的智能体。一些审查智能体会收到工作智能体的对话记录，另一些则只查看其输出，或在不了解工作智能体推理过程的情况下检查周边代码库。

没有任何单一视角能够捕捉所有缺陷。对话记录可以解释意图，但也可能使审查者偏向原有方案。仅审查输出能够保持距离，却可能忽略某项决策背后的原因。

Cursor 表示，结合去相关的审查视角提高了持续质量。该公司认为，审查所消耗的算力是值得的，因为检查现有工作比重新创建失败的分支成本更低。

这一说法仍然很难与其他变化分离开来。Cursor 同时改变了任务分解、版本控制、合并处理、架构记录和审查行为。该实验并未说明每个组件分别贡献了多少改进。

该智能体群还维护了一份共享的 Field Guide。这个由智能体管理的文件夹存储着未来工作智能体应当了解的经验。每个智能体启动时，其上下文中都会插入这份指南的索引。

Cursor 设置了行数限制，迫使智能体进行筛选整理，而不是把所有内容都积累下来。该系统优先保留那些能够缩短后续工作智能体探索路径的意外发现。

这是一种共迹机制，即通过改变共享环境来实现协调。蚁群会留下影响后续行为的信号。Cursor 的智能体则会留下文档、代码引用、编译器错误和操作说明。

Field Guide 解决了基于模型的智能体所面临的一项基本限制：模型权重在运行期间保持不变。如果没有外部记录，一个工作智能体的发现会随着其上下文结束而消失。

持久化笔记并不能保证记忆准确。智能体可能记录错误结论、保留已过时的变通方案，或过度重视罕见情况。因此，这份指南与其他共享产物一样，需要维护和审查。

人类工程组织也面临同样的挑战。团队需要记录架构决策、实现约束和意外行为，否则每位贡献者都会重复相同的调查工作。

专为工程工作流设计的工具可以帮助人类保留这些上下文。Cursor 的实验表明，自主团队需要更严格的版本，因为其中的成员会持续更替。

代码指标表明，这些控制措施影响了系统的一致性。在一种模型组合中，旧智能体群需要 64,305 行引擎代码才能通过完整测试套件，而新智能体群仅用 9,908 行便通过了测试。

另一种组合在旧运行框架下生成了 19,013 行代码，得分为 97%。据报告，新运行框架仅用 4,645 行便达到 100%。

代码行数更少并不总是意味着软件更好。紧凑的代码可能掩盖缺失的保护措施、狭窄的假设或不完整的功能。然而在这里，测试表现与架构集中度同时朝着相同方向改善。

不同策略下，智能体群的输出也有所不同。有些运行先构建广泛的基础，得分连续数小时处于低位，随后迅速提升。另一些则较早实现有限的 SQL 功能，之后在填补缺口的过程中进入平台期。

这种差异说明，单一时间点的单个分数可能会产生误导。Cursor 建议关注整体曲线，而不要把每个中间百分比都视为直接的生产力排名。

因此，Cursor 智能体群使用 Rust 构建 SQLite 并达到 80% 的测试通过率，反映的不仅仅是并行实现。审查与持久化共享记忆帮助防止早期错误演变为永久性的架构问题。

80% 的 SQL 得分并不意味着 SQLite 已达到生产可用水平

该基准测试支持了有关协调能力的论断，但并不能证明所生成的数据库具备与 SQLite 相当的可靠性、兼容性或安全性。

Sqllogictest 会检查数据库引擎针对大量查询是否返回预期结果，因此适合衡量广泛的 SQL 语义。但它并未涵盖生产用户对 SQLite 所期待的每一项特性。

SQLite 自身的测试体系包括多套测试框架、广泛的边界检查、故障模拟、模糊测试以及长期回归基础设施。查询结果正确只是该保障流程的一部分。

数据库还必须在崩溃期间保护数据、维持事务保证、安全处理损坏文件，并在不同平台上保持一致行为。它必须妥善处理并发、资源限制、异常编码和格式错误的输入。

性能同样重要。一个逻辑上正确的查询引擎，如果消耗过多内存或在真实工作负载下表现不佳，仍然可能无法使用。

Cursor 并未声称其生成的项目已经可以取代 SQLite。其文章将这项工作定位为一场有关智能体群组织方式和模型经济性的实验。现有证据更符合这种较为有限的解读。

80% 的得分也来自四小时检查点。Cursor 表示，每种新配置后来都在留出测试套件中达到 100%，但通过一个测试套件也可能引出新的问题。

有多少次独立运行能够产生相近的结果？成功的架构能否适应规范变化？智能体群能否扩展自己的实现，而不再次引入脑裂行为？

可复现性尤其重要。模型输出会随着提示词、采样、基础设施和模型更新而变化。一次成功的基准测试无法告诉团队这种方法失败的频率。

Cursor 使用相同的模型配置和时间预算对比了新旧运行框架，这控制了多个变量。然而，该公司尚未提供足够的公开材料，让外部人员能够独立复现整个评估过程。

人工检查也带来了另一层不确定性。Cursor 表示，研究人员检查了作弊、走捷径和实现不均衡等问题。这些检查很有价值，但未公开的审查标准难以评估。

该实验还受益于 Rust。它的编译器和类型系统能够在运行前发现不兼容的接口。Cursor 明确利用编译器错误，将架构变更传播至相关组件。

如果类似的智能体群使用动态语言工作，获得的即时反馈可能更少。一些分歧只会在运行时浮现，另一些则可能直到出现罕见的生产输入时才会暴露。

SQLite 还拥有极为完善的规范。智能体群获得了数百页描述预期行为的文档，并且可以使用成熟的外部测试框架为输出评分。

许多商业系统并不具备这些优势。需求散落在工单、对话、仪表盘以及未记录的运维知识中，其成功标准可能带有主观性或彼此矛盾。

这意味着，该实验揭示的可能是智能体群有效运作的一个前提条件，而非通用方案。规范和验证环境越完善，系统就越能安全地委派实现任务。

安全性值得单独保持谨慎。Cursor 表示，它已经使用这种架构发现开源项目中的漏洞。这只是该公司报告的应用案例，并不能证明智能体群生成的安全补丁始终可靠。

数据库引擎会处理不受信任的输入并保护持久化状态。一个细微的解析器错误、整数边界情况或事务缺陷，即使经历数百万次普通查询也可能始终不被察觉。

正确的结论应当有所克制。Cursor 报告称，其智能体群在受限基准测试中使用 Rust 构建 SQLite，并达到了 80% 的测试通过率。现有证据不足以支持将其输出称为生产级 SQLite 实现。

模型选择不如角色分配重要

Cursor 的结果表明，前沿智能主要在决策节点上发挥最大价值，而实现工作消耗了大部分总体资源。

该公司测试了由一个先进模型同时负责规划和执行的系统，也测试了混合系统：由前沿模型进行规划，再由速度更快的模型实现由此产生的任务。

全部四种新配置最终都取得了相近的测试结果，但其资源消耗存在显著差异，尤其是在规划者和工作智能体角色之间。

在每次运行中，工作智能体生成的 token 至少占 69%。在大多数配置中，这一比例超过 90%。这种分布符合预期，因为实现工作包含许多重复且局部化的操作。

规划所需的 token 较少，但杠杆效应更大。规划者需要选择架构、拆分规范、分配所有权，并在工作智能体开始修改代码之前消除歧义。

该层级上的一个错误决策可能产生数千项不必要的后续操作。一个良好的决策则可以把不确定的设计问题转化为若干明确的实现任务。

这种模式对“每个智能体都需要使用能力最强的可用模型”这一观点提出了挑战。如果规划者能够有效减少歧义，许多工作智能体只需遵循边界明确的指令，并根据编译器反馈作出响应。

混合系统的结果还表明，不能孤立地评判规划者的效率。一个规划者可能使用较少的 token，却产生迫使工作智能体经历更长实现路径的任务分配。

因此，团队需要衡量完整的推进轨迹。规划者的质量也包括其决策所产生的后续工作量、冲突和修订。

Cursor 的实验将模型选择转变为一个组织设计问题。最适合架构判断的模型，可能不同于最适合重复实现、合并、测试或审查的模型。

专业化也可以改善评估。合并智能体可以根据集成是否干净来评价，审查智能体可以根据发现的缺陷来评价，规划智能体则可以根据分支独立性和后续稳定性来评价。

由一个通用智能体承担所有角色会使反馈更加模糊。当项目失败时，团队难以明确区分究竟是规划有误、实现薄弱，还是审查不足。

新系统较低的活动频率进一步强化了这一解读。它产生的提交次数少于旧智能体群，但这些提交遇到的冲突显著减少，并促成了更加集中的架构。

因此，产出指标应当是得到认可、稳定的功能，而不是智能体的活跃程度。即使提交次数、token 用量和并发 worker 总数都在增加，有效进展仍可能下降。

这一原则给编码智能体供应商带来了压力。当编排决定产出能否组合成可维护的软件时，仅凭模型访问能力将越来越难以形成差异化优势。

它也迫使企业买家改变评估标准。简短的演示可以证明智能体能够编写代码，却无法证明多智能体系统能否在数小时的并发工作中持续维护既有决策。

买家应询问系统如何表示架构、分配所有权、记录推理、解决冲突并验证已完成的分支。他们还应询问，当规范在执行过程中发生变化时，系统会如何应对。

Cursor 的树状模型给出了一种具体答案。它将成本高昂的判断置于根节点附近，将大批量实现工作置于叶节点附近。协调与审查则在这些层级之间进行。

这种设计类似于软件组织，但以机器速度运行。最引人注目的并不是智能体取代了工程层级，而是 Cursor 因为不受约束的并行协作失败了，所以重新构建了层级结构。

Cursor 的 SQLite 实验之后应关注什么

下一个考验是，Cursor 能否将一次受控基准测试转化为在持续演进、接受外部审计的代码库上可重复实现的表现。

第一个信号是独立复现。开发者需要获取提示词、测试框架行为、模型标识符、评分流程以及多个生成的代码仓库。重复运行可以揭示单次成功轨迹无法呈现的差异。

复现并不需要完全重建 Cursor 的专有基础设施。它应测试在可比工作负载下，分层规划是否能够持续减少冲突和架构重复。

公开的 MiniSQLite 代码提供了一个起点。外部审查者可以检查 SQL 覆盖范围、不支持的行为、不安全的假设以及模块设计。他们还可以在保留测试套件之外，将其行为与 SQLite 进行比较。

即使发现严重故障，也不会否定其协调成果，但会将其主张从数据库实现缩小为基准测试驱动的功能合成。

第二个信号是在不断变化的规范下的表现。Cursor 的实验始于一份庞大且稳定的手册，而真实项目的需求会在开发者实现过程中发生变化。

一个有价值的后续实验是在长时间运行期间修改需求。智能体集群需要修订共享决策、作废过时任务，并更新相关分支，同时避免重新陷入冲突频发的反复折腾。

这项测试将对系统的设计文档和 Field Guide 构成压力。只有当智能体集群能够识别哪些记忆已经过时时，持久记忆才有帮助。

第三个信号是对更多语言和代码仓库的覆盖。Rust 提供强大的编译时反馈，而 SQLite 拥有成熟的规范和可衡量的输出。

一个可信的通用系统应当能够在动态语言服务、混合语言应用以及文档不一致的现有代码仓库中保持一致性。它还应当能够处理无法简化为查询正确性的运维需求。

Cursor 表示，它已经将这种架构应用于浏览器构建、漏洞修复、测试覆盖率、GPU 优化、数学和合成数据生成。对这些任务的详细评估将表明树状分解是否具备通用性。

最有价值的报告应当包含失败的运行。团队需要知道层级结构在什么情况下仍会失效、哪些冲突会逃过协调，以及审查者批准局部正确但整体有害工作的频率。

另一个有用的衡量指标是人工干预。即使研究人员反复调整提示词、停止循环、重新解读需求或修复基础设施，智能体集群仍可能显得具备自主性。

Cursor 披露，它暂停了之前的 Grok 运行，并手动审查了输出。未来的评估应量化成功和失败运行中的人工干预情况。

维护将提供最严峻的证据。构建新的代码仓库可以避开遗留约束、向后兼容承诺以及多年积累的设计决策。

如果 Cursor 的系统能够在数月后对其生成的数据库进行重大修改，同时保持行为和架构不变，其论据就会更有说服力。如果它必须重新生成大部分内容，那么这种方法看起来更像是合成，而不是可持续工程。

对开发者而言，眼下的启示并不是部署数千个编码智能体，而是将编排、规范、共享上下文和自动化验证视为智能体开发的一等组成部分。

对工程负责人而言，关键问题同样实际：你的组织能否足够精确地表达意图，让层级化的智能体在行动时不会自行产生彼此不兼容的假设？

根据 Cursor 的实验，该公司的智能体集群通过树状分解使用 Rust 构建 SQLite，测试通过率达到 80%。这一结果挑战了这样一种观念：仅靠更强的编码智能体就能解锁更大规模的自主项目。

正在浮现的制约因素是协调。值得关注的是，独立审查者能否复现这一结果、智能体集群能否适应不断变化的需求，以及它能否在 Rust 和异常完整的规范之外发挥作用。这些信号将决定 Cursor 构建的是一个持久可靠的工程系统，还是一台令人印象深刻的基准测试机器。