实测Cursor Projects:1个协调者Agent带数千子代理,PR合并量翻6倍
你是否也遇到过:让AI写个功能,聊到第4小时它开始改错目录,第二天新开会话又要从头解释一遍架构?大任务垮在上下文上,几乎是所有AI编程工具的共同死穴。Cursor在9月10日上线的Projects(beta),正面回应了这个问题。
Projects是什么:协调者只派活,不写代码
一个Project就是一条长期运行的工作线程。你对话的对象是协调者智能体(coordinator),它本身不写一行代码,只负责规划、拆分任务、派给子智能体执行,再把结果汇总交回你审查。官方内部数据显示:重度使用Projects的工程师PR合并量达到平时的6倍,新用户也多合了30%。它面向的是功能开发、大规模迁移和长期代码治理这类”一次聊天装不下”的工作。
三大机制:云端执行、共享上下文、订阅触发
云端执行:每个Project跑在自己的云主机上,合盖下班照常干活;需要真机验证时,协调者临时拉起一个本地Agent接上,两端共用同一套上下文。
共享上下文:全项目共用一组同步文件,子Agent把调研结论、代码库理解、测试方法、你的偏好全部落盘。下一个Agent冷启动第一件事是读档案,而不是重新摸索——一个Agent搞懂某个服务怎么测,后续所有Agent直接复用。
订阅触发:协调者可以盯Slack频道、按日程运行、跟踪PR的创建与合并。CI红了自动修,同一个错误见两次自动加lint规则——”人找活”被翻转成”活找人”。
上手七步:从建项目到开订阅
- 左侧导航栏进入Projects,新建一个Project;
- 连接GitHub、GitLab、Azure DevOps或Bitbucket,选择仓库;
- 描述一个持续多轮的目标,比如”完成XX框架迁移”;
- 用
.cursor/environment.json和Dockerfile固定云端环境的依赖、install和start命令; - 让Agent先调研代码库,把架构、约束、测试方法写入共享上下文;
- 审核任务拆分后,让子Agent在隔离分支中并行实施;
- 通过PR、测试日志验收,前几个PR逐个严审,风格稳定后再增加并行度和订阅。
具体到三类场景的节奏:功能开发是”研究→计划→并行实现/测试→上线后盯日志”;大迁移(几百个PR量级)前期严审、后期放手;维护自动化(官方叫gardening)可以让协调者扫每个新PR,一天触碰20-100个PR,人只出现在判断点。
成本实测:并行是便利,也是账单
Projects没有单独定价,跑在Cloud Agent上按所选模型的API价格计费。套餐方面Pro($20/月)、Pro+($60)、Ultra($200)、Teams($40/用户/月)均可使用,首次使用必须设置支出上限。Cursor官方给出的消费参考:每天重度使用Agent常见为每月60-100美元,大量并行的用户普遍在200美元以上。
| 维度 | Projects | 普通云端Agent | 单聊天会话 |
|---|---|---|---|
| 上下文 | 跨月共享档案,越用越厚 | 单任务内有效 | 单对话,跨天易遗忘 |
| 并行能力 | 数千子代理并行 | 单个执行 | 无 |
| 触发方式 | Slack/PR/定时自动触发 | 手动发起 | 手动发起 |
| 执行位置 | 云端为主+按需本地 | 云端VM | 本地 |
| 适合任务 | 迁移/大功能/持续维护 | 一次性中等任务 | 小改动、快速问答 |
要记住一个算术:5个子代理并行约等于5倍token消耗;订阅自动化按模型最大上下文计费,后台运行没有上下文开关。一个没有支出上限的gardening项目,月底账单可能比订阅费贵好几倍。
优缺点分析:值不值得开
优点:协调者不写代码,所以永远不会被长任务阻塞;共享上下文让新Agent的冷启动成本趋近于零;订阅触发是目前AI编程工具里最完整的无人值守方案。对比之下,GitHub HydraFusion的多模型编排仍停留在单任务层面,Projects是把”协调者不写代码”做成一等公民的第一个产品。
缺点:仍在beta,多个子Agent改相邻模块时接口和依赖可能冲突;审查是新的瓶颈——50个子代理各改一个文件,谁来review?官方6倍PR合并量的统计口径未披露,需要打个问号;成本模型奖励克制,不设上限容易失控。社区也有疲劳声音:上线推文的热评第一条是”能不能先把subscriptions做好,别急着加新功能”。
适用人群:有跨数周框架迁移、持续修CI、设计系统治理需求的团队;一次性小修小补,用普通Agent或搭配Gemini 3.8 Flash这类低成本模型更划算。
一句话总结:如果你手上有”一周都做不完”的大活,Projects是目前最接近”AI工程团队”的方案;如果只是改个bug,别为它多付token。