Cursor 推出 Projects：协调者智能体调度数千个子智能体

Cursor 这次把「多智能体协作」从 PPT 搬进了真实的编辑器。Projects 的核心是一个协调者智能体（orchestrator），它把一张大需求拆成成百上千个可并行的子任务，再派给数量庞大的子智能体去各自改文件、跑测试、回写结果，最后由协调者汇总统稿。过去我们看到的 Agent 多是「一个模型单打独斗」，Cursor 想证明的是：复杂软件工程更像一场有调度的并行作战，而不是一个人的马拉松。

用法上的变化很直观。开发者不再逐行和模型对话，而是给 Projects 一个目标仓库加一个高层意图，剩下的拆解、分配、冲突合并交给框架。对大型遗留项目尤其友好——那种动辄几十万行、改动牵一发动全身的代码库，单智能体容易在上下文里迷路，而分治后每个小智能体只盯自己那块，出错面更可控。社区里有人拿它重构模块、批量补测试、跨文件改名，反馈是「第一次觉得 Agent 能碰真项目了」。

但分治也带来新问题。最典型的是冲突：几千个子智能体同时改同一片代码，合并时的语义冲突比 Git 的文本冲突更难解。Cursor 的解法偏向让协调者持有全局视图、子智能体只在局部动刀，并在汇合阶段做一致性校验。这思路对，但边界场景仍会翻车，尤其是涉及架构层面改动时，局部最优叠加未必等于全局最优。

对团队管理者，Projects 真正的价值不在「更快写完功能」，而在把工程任务结构化。当开发被拆成可观察、可回滚、可并行的单元，进度和质量的可见性都会提升。它也会重新定义「高级工程师」的工作——从写代码转向写意图、设约束、审汇合结果。人的判断从「怎么实现」上移到了「要对齐什么」。

提醒一点：并行智能体很烧钱也烧上下文，大规模跑之前先在小范围估算成本和失败率。把它当放大器用，而不是当黑盒许愿机，才不会被账单和混乱反噬。

成本这道坎得单独说。几千个子智能体并行，烧的是真金白银，也是真上下文。大规模跑之前，先在小范围估算每轮的成本曲线和失败率，设好预算上限和熔断条件，别让「自动化」变成「自动烧钱」。更现实的用法，是把 Projects 当放大器而不是许愿机：它擅长把已经结构化的工程任务提速，却不擅长替你想清楚「到底要建什么」。人的判断从「怎么实现」上移到「要对齐什么」，才是这套工具真正的价值所在，而不是指望它凭空交付一个正确架构。

落到协作流程，建议给并行智能体加质量闸门：每个子智能体的产出先过小范围测试再合并，汇合处设人工抽检而非全信协调者。对涉及架构变动的任务，更要保留「全局评审」环节，因为局部最优叠加常不等于整体最优。说白了，多智能体放大了效率，也放大了错误传播速度——闸门设得密一点，比事后回滚整片代码省心得多。工具再酷，节奏仍该握在人手里。

安全上别忘了隔离。数千子智能体并行，意味着攻击面也被并行放大；给每个子智能体最小权限、限定向外通信，出问题才不至于烧穿整库。并行带来效率，也带来同等量级的风险面。