Cursor智能体蜂群：从文件级到spec级的协作革命
当数十甚至上千个AI智能体协同开展大型软件开发任务时，如何高效协调进度、避免代码冲突、控制运行成本，成为了智能体蜂群技术落地的核心难题。近期公开的智能体协作研究，为这一领域提供了极具参考价值的实践思路。
当前的代码智能体已经可以独立完成单个文件或功能模块的开发，但当任务规模扩大到完整的软件项目时，开发者依然需要承担项目经理的角色：拆分需求、划定边界、同步决策、处理各类冲突。相关团队希望将这部分管理工作也交给AI，让智能体蜂群直接从一份完整的需求规格说明书出发，自主完成全流程的任务拆解、代码实现和最终验收。
年初的首次实验中，这套蜂群系统成功从零构建了一个浏览器，证明了大量智能体协同完成大型项目的可行性，但最终成品距离成熟软件仍有明显差距。随着智能体数量增加，缺乏统一协调的系统导致项目陷入混乱，团队越努力推进，项目反而越容易失控。
为了验证改进后的协同机制，研究团队设计了一组严格对照的实验：给新旧两套蜂群系统提供835页的SQLite官方手册，不提供源码、测试套件、二进制文件或外部网络访问，要求用Rust语言重新实现一个完整的数据库，任务要求、模型配置和时间预算完全保持一致。
实验结果对比极具说服力：使用Grok 4.5的新版蜂群仅用四小时就通过了80%的保留SQL测试；而旧版蜂群没能撑过第二小时就因运行失控被强制暂停。最直观的差异来自冲突数据：旧版运行中单个文件最多被1173个智能体修改，累计冲突超过7万次；新版运行中冲突最多的文件仅出现47次冲突。研究的核心验证目标非常朴素：让智能体蜂群像专业工程团队一样有序协作，而非各自为战、互相干扰。
研究团队的核心验证目标非常朴素：让智能体蜂群像专业工程团队一样有序协作，而非各自为战、互相干扰。
先明确职责，再启动协作
新版蜂群系统仅设置两种核心角色：规划者和执行者。规划者负责拆解整体任务、做出关键设计决策，并将边界清晰的子任务分配给执行者；执行者则使用更快、更经济的模型，专注完成分配到的具体工作。两者围绕统一的任务树开展协作，且任意两个子任务都不会重复决策同一设计问题。
这一规则借鉴了现代组织管理的思路，解决了具体的代码冲突隐患。如果两个规划者互不知情，可能会在代码库的不同位置各自实现一套SQL解析方案，单独看都能正常运行，但合在一起就会形成两套完全独立的系统，导致项目彻底混乱。任务树本质上划分了“决策权”：谁负责定义接口、谁负责设计数据结构、谁只负责按照既定方案实现代码。明确了决策权后，执行者就不需要每次开工都重新理解全局意图，避免了重复的上下文消耗。
研究团队认为，智能体蜂群的扩容关键在于上下文效率：规划者不涉及底层实现，始终保持全局视野；执行者不需要负责规划，可以将全部上下文用于当前的具体任务。多智能体的价值不再是“同时开启多少个工作窗口”，而是“每个窗口中保留了多少有用的上下文信息”。
高速协作下的版本控制难题
任务树只能规范设计边界，代码层面的碰撞还需要专门的机制处理。新版系统的峰值提交速度可达每秒约1000次，针对人类团队设计的Git锁、代码评审和合并队列，在这个速度下会成为严重的性能 bottleneck。因此研究团队从头开发了一套专属的版本控制系统：所有代码修改都会先经过这套系统，冲突会在这里被提前暴露；当两个执行者同时修改同一处代码时，会由中立的第三方智能体负责合并，避免双方互相覆盖代码或直接放弃修改。
设计决策不能只存在于某个规划者的聊天记录中，智能体会将所有决策写入共享设计文档，依赖这些决策的代码会带上可编译检查的引用。当不同规划者出现决策矛盾时，系统会先合并文档，新的决策会沿着引用同步到对应的代码中。此外，还有一套由智能体自主维护的Field Guide，其index.md文件会在每个智能体启动时自动注入，仅受行数预算限制。智能体需要自主判断哪些踩坑经验值得所有成员记住，哪些细节只需要保留在局部任务中。
如果将这套系统比作一家公司，任务树就是组织架构，设计文档就是会议纪要，专属VCS就是冲突处理现场，第三方智能体就是合并调解员，而Field Guide就是不断更新的新员工手册。这一机制带来的改变非常具体：旧版实验最终膨胀到54个Rust crate，其中仅SQL相关的包就有三个；新版实验很早就稳定在9个crate，之后没有再增加。旧版蜂群看似异常忙碌，但实际上大量算力都被浪费在重复决策、争抢文件和返工上。
贵模型做决策，便宜模型做执行
当智能体蜂群学会高效协作后，另一个现实问题随之而来：如何控制大规模智能体集群的运行成本？研究团队测试了四种模型组合方案：有些让前沿模型同时包办规划和执行，有些让强模型担任规划者，搭配更快更便宜的执行者模型。最终各方案的测试结果相近，但总成本从1339美元到10565美元不等。
成本差距主要出在执行层。所有运行中，执行者至少消耗了69%的token，多数时候超过90%。其中，让GPT-5.5同时负责规划和执行的运行中，仅执行者部分就花费了9373美元。这组数据给出了一个实用的成本控制思路：昂贵的模型负责减少歧义、做出关键决策，而便宜的模型负责处理大量token消耗的执行工作。架构设计、边界定义和关键取舍需要更强的判断能力；当需求足够明确后，再让低价模型完成大量具体的执行任务。
当然，这并不是通用的万能方案：如果便宜的执行者频繁返工、制造冲突或无法通过测试，节省下来的推理成本会以工程返工的形式重新消耗。真正需要比较的，是完成同一份需求文档的总成本，而非单一模型的单价高低。
最终的交付单位，是一份需求文档
研究团队在研究中提出了一个颇具野心的判断：代码自动补全让工程师以“一行代码”为单位开展工作，早期的AI模型将工作单位提升到了代码块，coding agent进一步将单位提升到单个文件或功能，而智能体蜂群希望继续向上提升，最终让工作单位变为一份完整的需求文档。
SQLite实验正是对这一未来的模拟：团队只需要提供835页的文字说明，蜂群需要将这些意图逐层“编译”为任务树、设计决策和最终代码。普通编译器的每一步都必须保持严格的语义一致性，而智能体蜂群的每一步都带有概率性，任务树、共享文档、专属VCS、评审机制和测试流程，正是在填补这一可靠性差距。
不过现在还不急于将大量智能体投入实际项目。这仍是早期内部实验，不同的实验运行还使用过不同的测试框架，部分代码质量也没有经过深入的人工审核。它证明了一条值得继续探索的技术路线，但并没有证明任何团队都可以直接照搬成功。
目前真正可以落地的，其实是几条朴素的协作原则：先为关键设计决策找到唯一负责人；让共享文档成为后续实现的唯一依据；用测试进度和冲突趋势衡量团队产出；最后按照规划者和执行者的实际贡献拆分成本。归根结底，一群智能体想要真正高效地协同工作，首先需要建立一套不会互相冲突的组织机制。
