前沿模型规划、廉价模型执行，代码库缩减85%

Cursor 的母公司 Anysphere 设计了一套分层智能体集群架构，将智能体明确划分为两类角色：规划者智能体使用 GPT-5.5、Grok 4.5、Opus 4.8 或 Fable 5 等前沿模型，递归地将目标拆解为更小的子任务；执行者智能体则使用速度更快、价格更低的 Composer 2.5 模型，负责实际编写代码。这种分工的核心逻辑在于解决上下文管理难题——单一智能体在处理长任务时需要同时追踪整体目标与当前子任务，极易产生「漂移」，而分层架构让规划者专注决策、执行者专注实现，各司其职。

实验选取了一个极具挑战性的基准任务：在不提供 SQLite 源码、测试套件、二进制文件及互联网访问权限的条件下，仅凭835页官方文档，用 Rust 语言完整重建 SQLite。测试标准为 sqllogictest，这是一个包含数百万条 SQL 查询及已知答案的测试套件，且智能体事先并不知晓其存在。实验共测试了四种配置：GPT-5.5 单独运行、Grok 4.5 单独运行、Opus 4.8 规划搭配 Composer 2.5 执行，以及 Fable 5 规划搭配 Composer 2.5 执行。

在版本控制层面，新系统遭遇了人类团队从未面对过的挑战。早期的 Cursor 浏览器集群每小时约产生1000次提交，而新集群达到了每秒1000次提交的速度，Git 完全无法应对，Cursor 因此自行开发了版本控制系统。旧系统在 Grok 4.5 配置下两小时内产生了68000次提交，积累了超过70000个合并冲突，且冲突速率持续加速；新系统在整个测试过程中冲突数始终低于1000次。旧系统中被争用最多的文件来自1173个智能体的7771次冲突，新系统同一文件仅有47次。

为解决「分裂脑」问题——即两个规划者在不知情的情况下在不同位置以不同方式实现同一功能——Cursor 让智能体将决策记录在共享设计文档中，代码通过编译时检查的引用与文档关联。当合并冲突发生时，由中立智能体介入解决；当文件过于臃肿时，由外部智能体将其拆分为更小的模块。此外，Cursor 还测试了多角度代码审查机制：一名审查者获得执行者的完整操作记录，另一名只看输出结果，第三名只看代码库。单一视角无法捕捉所有问题，但多个不相关视角的组合显著提升了可靠性。

成本数据揭示了架构选择的巨大经济价值。执行者模型在所有配置中消耗了至少69%的 token，通常超过90%。在 GPT-5.5 全程运行的配置中，仅执行者部分的花费就达9373美元；而在 Opus 搭配 Composer 2.5 的混合配置中，整个执行者集群的花费仅为411美元，质量相当。Composer 2.5 的基准性能与 Opus 4.7 和 GPT-5.5 相当，但输入价格仅为每百万 token 0.5美元，输出价格为2.5美元。Cursor 创始人 Michael Truell 透露，该模型基于 Kimi K2.5 开发。代码规模方面，新架构在 Fable 5 配置下将引擎代码从64305行压缩至9908行，在 Opus 配置下从19013行压缩至4645行，测试通过率反而更高。

Cursor 将这套集群系统描述为一种「概率编译器」，负责将人类意图转化为可执行代码。这一实验的核心启示在于：大型编程任务中，真正需要顶级模型智能的环节——任务拆解与关键设计决策——只占整体工作量的一小部分，一旦前沿规划者消解了模糊性，廉价模型便能高效跟进执行。不过实验也表明，规划者的质量仍然举足轻重：Fable 5 规划者使用的规划 token 少于 Opus，但其执行者需要消耗更多 token 才能完成任务，导致整体成本反而更高。随着 Cursor 3 将智能体集群纳入核心产品，这套架构思路或将深刻影响 AI 辅助编程的未来走向。

要点

• 新的分层架构将规划与执行分离，所有配置最终均在 SQLite 重建测试中达到100%通过率，而旧系统因合并冲突失控而落败
• 采用廉价执行者模型（Composer 2.5）可将成本压缩至使用 GPT-5.5 全程运行方案的约1/15，且代码质量相当甚至更优
• 新架构在取得相同或更好测试成绩的前提下，代码库体积最多缩减85%，代码更简洁、结构更清晰
• 每秒1000次提交的速度使 Git 彻底失效，Cursor 被迫自研版本控制系统，揭示了超大规模智能体协作的全新工程挑战
• 规划者模型的质量仍不可忽视：规划质量不足会导致执行者消耗更多 token 弥补，反而推高整体成本