Cursor Agent Swarm 通过了 80% 的 SQL 测试套件，但其架构更为重要

Cursor 表示，其新型 agent swarm 在四小时内通过了一个留出 SQL 测试套件的 80%，而此前的系统在运行到第二小时之前就已失败。这一结果来自一项极具挑战性的实验：仅使用数据库文档，以 Rust 重新构建 SQLite。

Cursor agent swarm 之所以重要，是因为它改变了 AI 编程的竞争单位。竞争不再局限于哪个模型能写出最好的代码，还包括哪个系统能合理分配工作、保护上下文、解决冲突、审查变更，并高效配置昂贵的推理能力。

这给单 agent 工作流带来了压力，其中包括将单个高能力模型置于长期运行的编程循环中的方法。它也对由相同 agent 组成、协调松散的群体提出了挑战。Cursor 的核心主张是，带来最大改进的是架构，而非单纯的并行化。

这一结果仍是由公司自行开展的实验，而非独立基准测试。Cursor 控制了任务、测试框架、模型组合和评估流程。即便如此，该测试仍让我们得以深入观察多 agent 软件开发中新兴的经济模式。

Cursor Agent Swarm 测试中发生了哪些变化

Cursor 用一个将战略规划与专注执行分离的分层系统，取代了协调松散的 swarm。

Cursor 在其 7 月 20 日发布的关于 agent swarm 经济性的研究文章中介绍了这项实验。该公司重新挑战了一个曾暴露出早期 swarm 弱点的任务：使用 Rust 从零实现 SQLite。

agents 获得了长达 835 页的 SQLite 手册。Cursor 表示，它没有向 agents 提供 SQLite 的源代码、可执行二进制文件、测试套件或互联网访问权限。因此，swarm 必须将书面规范转化为可运行的数据库实现。

Cursor 使用 sqllogictest 评估生成的软件。它是一个最初为 SQLite 创建、与数据库无关的测试系统。官方 SQL 测试文档解释称，该系统会将数据库输出与已知的正确结果进行比较。

该套件可以包含数百万条生成的查询。它衡量数据库能否在不同语句、连接、筛选条件和数据状态的组合下计算出正确答案。

这一目标比重现 SQLite 的所有特性更为有限。Sqllogictest 不会评估性能、内存使用情况、索引效率、事务行为、锁机制或完整兼容性。

不过，该基准测试仍然要求实现广泛且相互关联的功能。一个数据库可能可以编译并执行简单语句，却在连接、类型行为、表达式、聚合或状态变化方面表现糟糕。

Cursor 表示，新 swarm 在每一种受测模型配置中都优于旧系统。当 Grok 4.5 同时负责规划和执行时，新系统在四小时后达到了 80% 的通过率。

旧版 Grok 4.5 swarm 在最初两小时内生成了 68,000 次提交。Cursor 在第二小时结束前暂停了该次运行，因为其行为已经陷入破坏性循环。

这种对比才是真正的新闻。旧系统产生了更多可见活动，却得到了一致性更差的结果。其庞大的提交数量代表的是无效折腾，而非有效进展。

在同一对比时段内，新测试框架生成变更的速度较慢。它保持了稳定的架构，并在留出测试中持续取得改进。

四种新配置在四小时后的结果均介于 73% 至 85% 之间。Cursor 还表示，四种新配置最终都在四小时对比窗口结束后通过了完整套件。

这些后续结果需要谨慎解读。Cursor 表示，代码经过了人工审查，以检查是否存在走捷径和不均衡地针对特定测试进行优化的情况，但这项审查由该公司自行开展。agents 也没有面对独立的复现团队。

因此，这项实验支持的是一个具体结论：Cursor 针对这项任务构建了一个更有效的内部编排系统。它并不能证明 agent swarm 能够独立重现生产级 SQLite。

这一区别非常重要，因为数据库不仅仅意味着查询正确性。生产软件还依赖可预测的性能、持久性、安全性、兼容性、可维护性，以及多年的对抗性测试。

尽管如此，Cursor agent swarm 仍跨越了一个具有意义的门槛。它将一份长篇规范转化为一个具备大量可用功能的系统，同时协调了众多并行贡献者。

为什么规划者和工作者角色胜过单纯的并行化

swarm 的改进源于每个 agent 接收到的无关上下文更少，而不只是因为同时工作的 agents 更多。

Cursor 将任务组织成树状结构。根节点代表总体目标，而分支则包含逐步细化的设计和实现任务。

规划者 agents 负责拆分这棵树并作出决策。工作者 agents 负责处理叶节点，在那里进行具体的编码和测试。

规划者不会实现分配的组件。它会保留项目结构、主要约束和依赖关系，而不会让局部调试细节塞满其上下文窗口。

工作者不会重新设计整个系统。它接收一个边界明确的任务，并可以将可用上下文用于单个组件、测试失败或集成问题。

这种分工解决了长期运行的 agents 中反复出现的弱点。单个 agent 必须在全局规划和局部实现之间来回切换，同时承载不断扩大的历史记录。

随着历史记录不断增长，模型可能会遗忘先前的约束，或将注意力浪费在已经过时的尝试上。它可能会优化一个函数，却削弱其周围的系统。

规划者—工作者结构限制了这种冲突。战略上下文保留在规划者处，而战术上下文保留在工作者处。

Anthropic 在其多 agent 研究系统中记录了一种相关的编排者—工作者模式。一个主导 agent 制定策略，并将并行调查委派给专门的子 agents。

Cursor 将这种模式应用于软件构建，而在这一场景中，所有输出都必须共存于同一个不断变化的代码库中。与整合多个相互独立的研究摘要相比，这一要求让协调变得更加困难。

代码会创建共享状态。当数十项其他任务依赖既有设计时，一个 agent 可能会重命名某个类型、修改接口或改变存储行为。

Cursor 早期的 swarm 难以处理这种共享状态。agents 会覆盖变更、重复创建概念、争抢文件，并避免对核心组件进行高风险修改。

新系统为每种故障模式都增加了明确的处理机制。规划者将重要决策记录在共享设计文档中。依赖代码则包含由编译检查的相关决策引用。

当计划发生冲突时，协调流程会合并文档。修正后的决策随后通过编译失败和下游修复传播开来。

Cursor 还引入了中立的合并 agents。这些 agents 在解决冲突时不会偏袒任一贡献者的局部方案。

大型文件会得到特殊处理。工作者可以标记负载过重的文件，之后系统会阻止新的变更，直到另一个 agent 将其拆分为更小的模块。

swarm 还可以授权可控的破坏性变更。如果 agent 记录了原因，它可以修改其正常职责范围之外的核心代码。

依赖组件随后会构建失败。其他 agents 会看到相关说明，并围绕新决策更新各自负责的部分。

这一流程将编译器错误视为协调消息。环境能够传达设计变更带来的后果，而无须每个 agent 都掌握每一次对话。

Cursor 将这一理念与共迹协调联系起来，即参与者通过改变共享环境来进行协调。该公司的 Field Guide 将同一原则应用于积累的知识。

Field Guide 是一个经过整理的文件夹，其索引会提供给新的 agents。agents 会在固定的行数预算内记录意外发现的经验、反复出现的陷阱和实用惯例。

这一预算非常重要。无限扩张的共享笔记最终会重现分层架构原本旨在避免的上下文过载问题。

因此，agents 必须决定哪些发现值得长期保留。保留更有价值的知识应当能缩短后续工作时间，尽管 Cursor 尚未单独公布对此效果的衡量结果。

从上下文管理的角度解释，这个 Cursor agent swarm 与其说像一群人，不如说更像一个组织。角色、决策记录、审查、所有权和仲裁共同约束着个体行为。

单纯的并行化依然有用，但它并非主要机制。更多的工作者会同时放大有效工作和协调失误。

新设计试图让协调能力与实现能力同步增长。这是一个比启动更多 agent 会话更困难的工程问题。

Cursor Agent Swarm 的经济性更有利于专业化模型组合

Cursor 最重要的经济性发现是，大多数 token 被用于执行，而最困难的推理似乎集中在数量相对较少的规划决策上。

Cursor 测试了四种主要配置。其中两种使用相同的模型进行规划和工作，另外两种则将能力更强的规划者与速度更快的工作者模型相结合。

在这项实验中，最终的质量水平大致相近，但资源需求并不相同。

在每次公布的运行中，工作者消耗的 token 至少占 69%。在大多数配置中，这一比例超过了 90%。

这种分布改变了团队思考模型选择的方式。让能力最强的模型处理每项任务，会把昂贵的推理能力浪费在重复性实现工作上。

许多叶节点任务并不需要设计新架构，而是需要遵循明确的接口、添加边界清晰的功能、运行测试，或修正局部故障。

一个能力强大的规划者可以在这些任务到达工作者手中之前减少歧义。一旦规范变得具体，成本更低的模型就可以执行任务。

其结果类似于编译器流水线。一个高层目标会被逐步下沉为更小的指令，直到每个单元都可以直接执行。

这一类比存在局限。传统编译器应用的是确定性转换，而 agent swarm 在每个阶段使用的都是概率模型。

因此，Cursor 在规划树周围设置了审查和协调机制。这些系统试图检测含义是否在分解或实现过程中发生了变化。

据 Cursor 称，审查消耗了大量计算资源。该公司认为，审查仍然很高效，因为检查已经完成的工作比产出这些工作需要的精力更少。

Cursor 使用了多种审查视角，而不是依赖一个通用审查者。部分 agents 检查交互记录，另一些检查输出，还有一些仅评估不断演进的代码库。

不同的模型和提示词也提供了相关性更低的判断。一个审查者可能会发现接口偏移，而另一个则会识别出行为不完整或复杂性配置不当的问题。

这是对多 agent 编程常见想象的一项重要修正。真正有用的系统并不是一个挤满 agents、让它们尽可能快速编写代码的房间。

这是一条可控的生产线，包含规划、实施、审查、冲突解决、记忆和验证。每增加一个阶段都会消耗资源，但它可以防止下游出现更严重的故障。

OpenAI 通过 Symphony 编排介绍了另一种编排层。该系统将项目管理任务与持续运行的编码智能体及人工审查连接起来。

Symphony 专注于将问题队列转化为智能体工作。Cursor 的实验则更深入地探索了单个宏大项目中的任务分解和协同实施。

这两套系统都指向了相同的市场压力。编码产品之间的竞争将越来越侧重于编排、可观测性和审查，而不再只是模型访问能力。

模型提供商也面临着更复杂的购买模式。团队可能选择一个模型负责架构，另一个负责实施，第三个负责审查。

这削弱了“一个模型必须赢得所有类别”的假设。一个模型只要能够稳定地承担某种角色，就可以产生经济价值。

即使快速工作模型没有在通用编码基准测试中领先，也可能获得广泛使用。前沿模型则可以通过做出数量更少但影响更大的决策来保持价值。

这种架构还带来了新的优化问题。规划器稍微有所改进，并不会自动提高整个运行过程的效率。

Cursor 发现，规划器的行为会影响有多少工作流向下游。即使规划器使用的 token 更少，其生成的指令仍可能导致工作智能体消耗更多 token。

因此，团队需要系统级指标。单凭模型级速度、基准测试分数和 token 效率，无法预测一次多智能体运行的总成本。

真正有意义的单位变成了已完成且经过审查的任务。这个单位包括失败的尝试、合并冲突解决、重复测试、审查工作和人工干预。

这对工程负责人具有实际意义。如果规划产生重叠任务或不稳定接口，看似成本低廉的工作智能体集群可能会造成浪费。

高能力规划器也可能成为瓶颈。如果每项决策都要等待一个昂贵的模型，并行执行的规模可能会超出规划层的承载能力。

Cursor 尚未公布规划器与工作智能体组合的完整矩阵，也没有说明同样的排名是否适用于成熟代码仓库。

不过，该公司的结果仍为购买者提出了一个更明确的问题：他们应该判断昂贵的推理会在哪些环节改变结果，然后避免不加区分地使用它。

80% 的 SQL 结果无法证明什么

较高的测试通过率是功能取得进展的证据，但无法单独证明工程质量或生产就绪程度。

Cursor 选择了一项有价值的留出评估。智能体没有获得 sqllogictest 套件，而且该公司表示，每次运行后都进行了人工检查，以确认系统没有走捷径。

这些控制措施降低了直接针对基准测试作弊的可能性，但并未消除所有测量方面的疑虑。

Sqllogictest 检验的是引擎能否返回正确结果。其文档明确排除了性能、资源使用、事务行为、并发和锁定。

因此，一项实现即使得分很高，仍可能不适合实际应用。它可能使用缓慢的算法、发生内存泄漏、无法正确处理崩溃，或表现出不安全的并发行为。

80% 这个数字描述的也只是某个测试套件的通过比例。它并不意味着系统重建了 SQLite 的 80%，或达到了其生产能力的 80%。

这种表述会把不同性质的单位混为一谈。测试覆盖率取决于查询的分布，而产品完整性还包括评估器范围之外的行为。

最终达到的 100% 结果同样需要谨慎解读。通过所有已纳入的测试，意味着所有受测结果都能匹配，并不意味着复制了 SQLite 的完整语义和实际运行表现。

Cursor 承认了其中一部分局限。该公司将早期的浏览器项目称为概念验证，并表示它距离完善的软件仍然很远。

这项浏览器实验具有参考意义，因为它同时展现了大规模智能体群的吸引力和弱点。它们可以生成数量惊人的代码，却不一定能产出完整的产品。

SQLite 测试通过定义量化目标，改进了早期演示，但可维护性和实际运行适用性仍有待后续检验。

Cursor 发布了一项由单个智能体生成的实现，供公众检查。该公司还表示，目前只对该代码进行了初步审查。

独立维护者应检查其架构、未定义行为、测试缺口、不安全的 Rust 用法，以及与 SQLite 已记录行为之间的偏差。重复运行则可以揭示结果是否稳定。

评估研究提供了另一个需要谨慎看待的理由。Microsoft 的 AgentLens 研究分析了多个模型后端中的 2,614 条软件智能体运行轨迹。

在其评估子集中通过测试的轨迹中，研究人员将 10.7% 归类为“幸运通过”。这些运行通过回归循环、盲目重试、缺少验证或无序工作得出了正确结果。

这里的结论并不是 Cursor 的运行依靠运气。目前没有独立证据支持这一结论。

真正的启示是，最终通过率无法描述过程质量。两个系统可以获得相同的分数，但其达成结果的路径可能截然不同。

Cursor 的对比实际上强化了这一点。旧版智能体群生成了数以万计的提交，却陷入了破坏性循环。表面的活跃掩盖了不断恶化的协作状况。

新系统试图通过设计记录、审查和结构化协调来揭示流程健康状况。然而，Cursor 尚未发布足够的运行级数据，无法让外部研究人员全面评估这些机制。

可复现性是另一个悬而未决的问题。该公司报告的是四种配置的一轮对比，而不是包含置信区间的大规模统计样本。

由于模型会做出概率性决策，AI 智能体的运行结果会有所变化。后期出现的一个架构错误，可能使数百项下游任务偏离方向。

多次重复实验可以说明所报告的曲线代表典型表现还是有利轨迹，也能揭示不同规划器之间的差异。

成熟代码库会带来不同的挑战。Cursor 的智能体从空白仓库开始，并完全控制整个实施环境。

现有企业系统包含未记录的假设、迁移约束、外部服务、旧测试和人工所有权边界。智能体无法在不产生组织层面后果的情况下随意重构这些系统。

安全敏感型工作还带来了另一个问题。Cursor 表示，它已使用智能体群发现并修复开源软件中的漏洞。

这是一个前景可观的应用，但自动化漏洞处理需要谨慎的披露控制。更快发现缺陷的智能体群，也可能制造更庞大的审查队列或泄露敏感发现。

当故障影响用户时，生成的补丁需要由人类承担责任。中立的合并智能体可以解决代码冲突，但无法承担业务风险。

团队还需要可靠的组织背景信息。智能体必须理解以往的决策、事故历史、客户承诺和内部标准。

可搜索的工程知识库有助于保存这些背景信息，但它无法取代审查、访问控制或负责任的所有权。

因此，对 Cursor 结果最有力且准确的解读是：在一项范围受限的数据库构建测试中，一个分层且经过监测的智能体群，相较于 Cursor 早期的运行框架表现显著更好。

最站不住脚的解读，则是将这一分数视为自主智能体群可以取代生产工程团队的证明。已发布的证据并不支持这一说法。

三个信号将表明智能体群是否已准备就绪

下一阶段应通过可复现性、在现有代码仓库中的表现，以及真实生产使用的证据来评判。

第一个信号是对 SQLite 实验的独立复现。Cursor 已提供任务描述并发布了相关代码，为外部分析创造了条件。

可信的复现实验应针对每种模型配置运行多次，并公布得分曲线、资源消耗、失败分类和人工干预情况。

研究人员还应测试查询正确性以外的指标。性能、崩溃恢复、事务隔离、内存安全性和兼容性，可以揭示功能广度是否伴随着足够的工程深度。

如果重复运行能产生相似的曲线和可维护的实现，Cursor 的架构主张将得到加强。较大的结果差异或隐藏的人工干预则会削弱这一主张。

第二个信号是在现有代码仓库中的表现。从规格说明开始工作，避开了许多主导专业软件开发的历史约束。

更有力的测试，是让 Cursor 智能体群在成熟的开源项目中执行迁移任务或实现跨模块功能。维护者随后可以评估审查负担和集成质量。

有用的指标包括被撤销的变更、逃逸缺陷、合并冲突、审查时间，以及需要人工重新实现的工作比例。

关键指标并不是生成的代码量，而是被接受且经受住现有系统实际检验的工作。

这项测试还将揭示规划器—工作智能体层级能否尊重所有权。成熟项目在更改公共接口或基础抽象之前，通常需要先进行协商。

如果智能体群能够保留本地惯例并减少维护者的工作量，它将对单智能体编码产品形成压力。如果审查成本随智能体数量增加，其优势就会缩小。

第三个信号是持续的生产环境采用。Cursor 表示，该系统已经构建过浏览器、提高了测试覆盖率、修复了漏洞、优化了 GPU 内核，并生成了数十亿个合成 token。

这些例子均来自 Cursor，且缺少可比的外部基线。下一步有价值的证据，是将智能体群活动与稳定的工程成果联系起来。

团队应关注部署频率、事故率、回滚频率、安全问题发现数量，以及审查智能体变更所花费的时间。这些指标可以显示其速度优势能否延续到演示之外。

生产环境的使用还将检验模型专业化。组织需要了解一个规划器能否在数天而非数小时的时间跨度内，可靠地指挥由不同模型组成的工作智能体集群。

人类责任仍然至关重要。工程师必须决定系统可以更改什么、哪些测试定义验收标准，以及自动修复何时需要升级处理。

正在出现的新工作模式不再只是向一个编码助手输入提示词，而是要明确意图、设计评估、整理背景信息，并监督一个自动化组织。

这一变化赋予了 Cursor“以规格说明为工作单位”这一观点真正的分量。一份精确的规格说明会成为不断扩展的智能体层级所执行的输入。

然而，规格说明很少包含所有实际运行真相。重要知识通常存在于会议、事故记录、旧拉取请求以及与客户的对话中。

能够安全连接这些信息源的系统将获得优势。智能体群只能保留其能够访问、理解和验证的意图。

对开发者而言，眼前的启示非常实际。不要通过计算智能体数量、提交次数或生成代码行数来评估多智能体编码。

询问系统如何划分职责。研究它如何记录决策、解决冲突、检测回归、限制上下文并衡量已完成的工作。

对于企业买家而言，模型选择正逐渐仅成为决策中的一个层面。编排框架决定了模型能力如何转化为可靠的成果。

对于模型提供商而言，专业化创造了机会。最佳的规划者、执行者、审查者和协调者不必是同一个模型。

Cursor 的实验并未就智能体集群能否在没有持续人工判断的情况下产出生产级软件得出定论。但它确实表明，协调架构的影响可能超过单纯的模型活动量。

Cursor 智能体集群之所以能在四小时内完成其 SQL 目标的 80%，是因为系统明确限制了由谁规划、由谁实施，以及分歧如何传递。

现在的问题是，当规范不完整、代码仓库存在历史包袱、故障会影响真实用户时，这种结构能否继续奏效。关注复现结果，而不是提交次数。