Cursor 测试了一个升级版智能体集群，并将其与早期系统对比：两者都被要求仅使用文档、在无法访问源代码或互联网的情况下，用 Rust 重建 SQLite。新系统的每一种配置最终都在测试套件上达到 100%，而旧集群则因大量合并冲突和重复工作而放慢进度。

在 Cursor，智能体集群已经从研究项目转变为核心产品。借助 Cursor 3，开发者可以并行运行成组的 AI 智能体。Cursor 背后的公司 Anysphere 最近被 Elon Musk 的 SpaceX 以 $60 billion 收购。

该系统将智能体分为两种角色。由前沿模型驱动的规划智能体会递归地把目标拆分为更小的任务。使用更快、更便宜模型的执行智能体则完成这些任务。这个过程会生成一棵任务树，并可随着工作推进而变化。

Cursor 表示，这种分工主要是为了解决上下文管理问题。单个智能体必须在完整任务树中移动，同时保留总体目标和当前任务，这有助于解释为什么智能体在长时间任务中会发生偏移。在 Cursor 的集群设计中，规划者不写代码，执行者不做规划。

Git 无法跟上每秒 1,000 次提交

早期的 Cursor 浏览器集群在 Git 上达到约每小时 1,000 次提交。该系统使用执行智能体、评判智能体以及负责解决冲突的集成器。集成器最终更多地成为瓶颈，而不是解决方案。

新集群达到每秒 1,000 次提交。因此 Cursor 构建了自己的版本控制系统，并表示，以这种速度运行的智能体会产生人类工程团队通常不会遇到的故障模式。由此看来，该实验不仅关乎原始代码生成能力，也关乎软件开发基础设施能否协调数千次自动化编辑，而不陷入重复工作的崩溃状态。

其中一个问题是 Cursor 所称的“split-brain design”。在这种模式下，两个规划者会在不知情的情况下，在代码库的不同区域构建同一个概念，并以不同方式实现。当规划者彼此知晓、并用相互竞争的编辑阻塞对方时，争用会更加难以管理。

为减少这些问题，Cursor 让智能体在共享设计文档中记录决策。与某项决策相关的代码会通过编译时检查的引用链接回相关文档。

当出现合并冲突时，一个中立智能体会介入解决。执行智能体还会标记过大的文件，以便外部智能体将其拆分为更小的模块。由于智能体在已有、由人类监督的代码库中工作时学会了避免触碰核心代码，Cursor 有意允许它们破坏内容。智能体可以修补其分配区域之外的代码，编译器则会将变更传递到整个系统中。

Cursor 测试了多种审查者和由智能体维护的现场指南

Cursor 评估了几种审查方法。一名审查者收到执行智能体的完整记录，另一名只看到执行智能体的输出，第三名只看到代码库。没有单一视角能发现所有问题，但 Cursor 发现，结合互不相关的视角可以提高可靠性。

该公司还测试了一个“field guide”，即由智能体自行维护、设有固定行数上限的知识文件夹。每个智能体在启动时都会收到该文件夹的内容。由于模型权重在训练后是固定的，Cursor 表示，记录意外发现是有用的，这样后续智能体就可以走捷径。

在基准测试中，Cursor 向集群提供了 835 页的 SQLite 手册，并要求其构建一个 Rust 实现。智能体没有获得 SQLite 源代码、测试套件、SQLite 二进制文件或互联网访问权限。基准测试是 sqllogictest，这是一个包含数百万条 SQL 查询及已知答案的测试套件。集群并不知道该基准测试的存在。这一设置使任务成为对遵循规格和系统集成能力的测试，而不是源代码翻译或针对基准的调优。

Cursor 测试了四种配置：GPT-5.5 单独运行、Grok 4.5 单独运行、Opus 4.8 作为规划者搭配 Composer 2.5 作为执行者，以及 Fable 5 作为规划者搭配 Composer 2.5 作为执行者。新系统在每一种配置中都超过旧系统。四小时后，新系统运行得分在 73% 到 85% 之间，而旧系统运行得分为 11% 到 77%。新系统的每一种配置后来都达到 100%。

旧集群生成的工作量多于完成的工作量

Grok 4.5 的运行结果显示了早期系统落后的原因。旧集群在两小时内产生 68,000 次提交，约为新系统的 70 倍。Cursor 表示，其中大部分活动都是浪费。旧运行累计超过 70,000 次合并冲突，而新运行在整个测试期间始终低于 1,000 次。

旧运行中争用最严重的文件记录了涉及 1,173 个智能体的 7,771 次冲突。新运行中的可比数字为 47 次冲突。同样的 split-brain 问题也出现在包布局中。旧运行将项目拆分为 54 个 Rust crate，并创建了三个独立的 SQL 包，而新运行很早就稳定在九个 crate。

在 Fable 5 配置中，旧集群需要 64,305 行引擎代码，而新系统需要 9,908 行。在 Opus 配置中，旧系统生成了 19,013 行代码，得分为 97%。新系统用 4,645 行代码达到 100%。对 Cursor 来说，更少的代码行和更少的冲突属于同一个结果：改进后的集群在达到更高测试表现的同时，减少了冗余实现工作。

更便宜的执行模型带来了最大的成本差异

总成本从 Opus 混合配置的 $1,339 到 GPT-5.5 单独运行的 $10,565 不等。执行智能体在每次运行中都占至少 69% 的 token，通常超过 90%。由于规划者 token 更贵，成本分布与 token 分布并不相同。在 Opus 混合运行中，规划者只产生了一小部分 token，却占总账单的三分之二。

执行模型的选择带来了最大的成本差距。在 GPT-5.5 运行中，仅执行智能体就花费 $9,373。在使用 Opus 和 Composer 的运行中，整个执行智能体集群在可比质量下花费 $411。Cursor 将这种差异几乎完全归因于定价。Composer 2.5 的基准表现达到 Opus 4.7 和 GPT-5.5 的水平，但每百万输入 token 仅需 $0.50，每百万输出 token 仅需 $2.50。根据 Cursor 创始人 Michael Truell 的说法，该模型基于 Kimi K2.5。

Cursor 认为，大型任务中只有某些部分需要前沿模型的智能，包括任务分解和关键设计决策。一旦前沿规划者解决了歧义，更便宜的模型就可以遵循计划。不过，混合运行也显示规划者质量仍然重要。Fable 5 规划者使用的规划 token 少于 Opus，但其执行智能体需要多得多的 token 才能完成工作，使 Fable 运行总体成本更高。

Cursor 将集群描述为一种概率编译器，逐步把意图转换为可执行工作。该公司表示，实验中的主要约束是准确描述这种意图。Cursor 已将 Opus 单独运行生成的代码库以 minisqlite 的形式发布在 GitHub 上。

文章称，这类运行不再局限于实验室实验。Fable 5 的预发布版本承担了 Bun 从 Zig 重写为 Rust 的大部分工作。64 个实例在 11 天内编写了超过一百万行代码，成本约为 $165,000。生产使用仍然不同：2025 年底发布的一项研究发现，生产中使用的智能体有 68% 在人类介入前完成不超过十个步骤。对于 47% 的智能体，这一上限少于五步。这种对比留下了一个关键实践问题：Cursor 这种受控的高并行工作流，有多少能够迁移到人类仍会很快中断大多数智能体运行的生产环境中。