Cursor 在2026年9月10日发布 Projects 测试版，尝试把编程智能体从“一次解决一个问题”扩展为持续数周甚至数月的软件项目。其核心是一个协调器：它本身不直接写代码，而是理解目标、拆分工作、维护项目状态，再把具体任务分配给大量子智能体。官方称，该系统可协调数千个智能体。
协调器为什么不亲自写代码
当任务只有一个修复点时，单个智能体读代码、修改和测试就足够。但大型迁移、长期维护或跨模块重构包含许多相互依赖的步骤，如果同一个执行者既要规划又要处理每处细节，上下文很快会拥挤。Projects 将计划与执行分开：协调器保留项目级目标和进度，子智能体分别处理功能开发、代码审查、测试或维护工作。
云端为默认，本地用于必要场景
Projects 默认在云端调度任务，以便长时间运行和扩大并行规模；当工作必须依赖本地环境或内部资源时，也可以转到本地执行。这种混合方式更贴近真实研发流程，但同时要求团队明确代码、构建产物和凭据可以进入哪些环境。并行数量越大，分支冲突、重复修改和测试资源争用越需要由系统治理。
订阅让项目持续获得新任务
官方展示的“订阅”机制可以监控 Slack 消息、按计划运行，或跟进代码仓库中的拉取请求。这意味着 Projects 不必只靠人工逐次启动，而能在新需求、评审意见或固定巡检出现时继续工作。对于安全扫描、依赖升级、测试维护和大规模代码迁移，这类持续触发可能比一次性提示更有价值。
规模不是唯一指标
- 协调器拆出的任务是否边界清楚，验收条件是否可自动检查；
- 多个子智能体修改同一代码区时如何避免冲突；
- 长项目能否保留关键决策，而不是只累积聊天记录；
- 失败、偏离目标或成本异常时，团队能否及时暂停和接管。
Cursor Projects 的方向，是把编程智能体变成一种项目级执行基础设施。官方正从9月10日起逐步开放测试。对准备试用的团队，最适合的起点不是直接追求“数千个智能体”，而是选择可拆分、测试充分的项目，先验证十几个并行任务能否稳定合并并产生可审计结果。
