2026年7月20日，AI编程工具公司Cursor发布了一项震撼业界的实验成果。他们让一群AI编码智能体接受了一个极端挑战：仅凭一份835页的SQLite项目手册，从零开始用Rust语言重写整个SQLite数据库。没有源代码参考，没有SQLite二进制文件，没有测试集，也不允许访问互联网。四小时后，新架构的智能体系统在隐藏的sql逻辑测试套件中，Grok 4.5版本通过了约80%的测试。更重要的是，在后续持续运行中，所有四种模型配置最终都达到了100%的通过率。这并非Cursor第一次尝试让AI智能体完成如此复杂的任务。此前他们的浏览器构建实验虽然证明了AI智能体的潜力，但也暴露了严重的协调问题。旧版的AI智能体集群在运行过程中产生了超过7万个合并冲突，最终不得不被人工叫停。而新系统在两个小时的运行中产生的冲突数量不到1000个，这是一个巨大的进步。通过重新设计多智能体的协调机制和专用的版本控制系统，Cursor成功地把一群各自为战的AI转变成了一个高效协作的团队。
Cursor新系统的核心设计理念是职责分离。整个智能体集群被划分为两个清晰的层次。Planner是规划者层，由当前最强的前沿模型如Opus 4.8或Fable 5担任。Planner的职责是拆解任务、制定架构决策、分配工作、并对整个项目的设计方向负责。Planner不写一行实现代码，它的所有输出都是决策文档、任务规范和验收标准。Worker是执行者层，由更便宜更快的模型如Composer 2.5担任。Worker接收Planner下发的明确指令，完成具体的实现工作。Worker不需要了解项目的全局架构，只需要专注于眼前的一个窄任务，完成后提交结果给审核机制。这种分工方式的核心优势在于上下文效率。一个独自工作的长程智能体需要同时维护整个任务树的上下文，随着任务推进，它的注意力会逐渐分散，决策质量会不断下降。而在Planner+Worker的架构中，Planner只负责决策不负责实施，Worker只负责实施不负责决策，各自的上下文用于各自擅长的领域。这种将认知负荷按职责切分的做法，就像一家公司里CEO负责战略决策、工程师负责编码实现，比一个全才从头管到尾更高效。Cursor的测试数据有力地证明了这种分工的经济价值。在同样的四小时时间预算内，使用Opus 4.8作为Planner搭配Composer 2.5作为Worker，总的推理成本为1339美元。而使用GPT-5.5同时担任Planner和Worker，总成本高达10565美元。前者仅为后者的13%，节省了87%的成本。更重要的是，两者在最终达到的代码质量上没有显著差异。Worker消耗了每次运行中至少69%的token，在大多数运行中超过90%。然而在Opus+Composer组合中，整个Worker阵列的成本仅为411美元。
让数百个AI智能体同时在一个代码库上工作是极为困难的。现有的Git和Cargo等版本控制工具是为人类开发者设计的，假设每次提交需要人类思考和审查。AI智能体的工作速度远超人类，旧版实验中的集群峰值只有约每小时1000次提交，而新版系统达到了每秒约1000次提交。提高的速度暴露了Git在处理AI智能体协作时的极限。Cursor为此构建了一套自定义的版本控制系统。这套系统能够处理大量智能体同时提交的代码变更，并实时检测和解决冲突。当两个Planner对同一个模块做出不同的设计决策时，系统会记录到设计文档中，后续由专门的裁决智能体来解决冲突。当Worker在同一文件上发生编辑冲突时，系统会将冲突路由到仲裁智能体处理，而不会简单地覆盖或放弃编辑。当某些文件吸引的智能体数量过多时，系统会自动拆分这些热区文件，防止它们成为永久的冲突热点。在旧版实验中，Grok 4.5的集群在两小时内产生了超过7万个合并冲突，最终项目结构膨胀到54个Rust包，包含三个互不兼容的SQL包。而在新版系统中，Grok 4.5在相同时间内仅产生不到1000个冲突，项目结构在早期就稳定在9个包上并保持到最后。代码质量也有了质的飞跃。旧版Fable 5完成全部测试时，引擎代码总量为64305行。新版Fable 5完成同样的任务仅使用了9908行代码。更少的代码并不自动意味着更好的软件，但当一个急造的数据库项目从54000行代码膨胀到64000行时，显然出现了严重的问题。
Cursor的群智能体实验揭示了AI编程领域正在经历的根本性变革。如果按阶段划分，AI编程的进化历程已经走过了四个阶段。第一阶段是自动补全，AI帮助开发者完成本行代码的续写。第二阶段是代码块生成，AI可以生成一个函数或一个类的完整代码。第三阶段是AI Agent，AI可以完成一个独立的任务如实现一个功能模块。第四阶段是AI Swarm，一个智能体集群可以完成一个完整的大型项目。Cursor的SQLite实验是Swarm模式的一个有说服力的验证。在Swarm模式下，开发者不再需要编写每一行代码甚至不需要拆解每一个任务。开发者只需要提供需求规格说明书，AI智能体会自动将规格转化为项目规划和任务分解，然后由智能体集群协作完成编码、测试和代码审查的全过程。当然Swarm模式也有其需要注意的局限性。Cursor自己坦承，Swarm系统目前是一个概率性的系统，输出的代码质量依赖于规格说明的精确性和协调机制的有效性。在实验报告中他们特别强调：Swarm的翻译过程不是编译器那样的精确翻译，而是在每一步都带有概率性。相关的协调修复方案主要就是为了缩小这个概率偏差的差距。工程团队在选择群智能体编程平台时应该关注的比较点，正在从哪个供应商的模型写出更好更便宜的代码，转向哪个供应商的编排层能够更好地防止智能体在大规模协作中破坏自己的工作成果。