Cursor 9 月 10 日上线 Projects 功能，目前是测试版，向所有用户开放。它瞄准的是跨多个 PR、持续几周甚至几个月的工作：新功能开发、框架迁移，或者从零搭一个完整应用。
结构分两层。上层是一个协调者智能体，自己不写代码，只给下面的智能体派活。按 Cursor 的说法，协调者只委派不执行，所以它从不会被某个任务卡住，随时能接人的新指令。下层是写代码的子智能体，官方给出的规模是一个项目可以指挥数千个。
“It doesn’t write code itself but directs other agents that do.” （它自己不写代码，只指挥那些写代码的智能体。）
三个底层能力
Projects 靠三件事撑起来：
- 云端优先：项目跑在专属服务器上，合上笔记本也不会中断；
- 共享上下文：文件在云端和本地机器之间同步，前面的智能体摸清的东西，后面的可以直接复用；
- 订阅：项目可以盯一个 Slack 频道、按计划定时运行，或者跟着 PR 状态自动响应。
Cursor 给了三种典型用法。做新功能时，多个智能体先并行调研现有系统，再分头实现不同组件；做迁移时，团队用它在几百个 PR 里逐步换掉框架和样式系统；做维护时，协调者持续盯着代码质量和回归。
设计系统那个例子
博客里写得最具体的是设计系统维护：协调者扫描每一个新 PR，把应该收进设计系统的组件抽出来，同一个错误见到第二次，就加一条 lint 规则。按 Cursor 的预估，这类项目一天要处理 20 到 100 个 PR。
粗算一下这个量落到人身上是什么概念。假设认真审一个中等规模的 PR 要 15 到 30 分钟，一天 20 个就是 5 到 10 小时，一个人勉强顶住；一天 100 个就是 25 到 50 小时，按每人每天 8 小时算，要三到六个人专职审查。机器产出的速度上去以后，卡脖子的环节会挪到审查，除非团队接受一部分 PR 只过自动检查就合并。Cursor 没有说明 Projects 产出的 PR 里有多少是人工审过再合并的。
六倍从哪来
Cursor 给出的效果数字有两个：公司内部，新用户合并的 PR 多出 30%；主要靠 Projects 干活的用户，合并量是原来的六倍。两个数都来自 Cursor 自己的员工，衡量的是合并 PR 的数量，没有涉及 PR 大小、返工和回滚，30% 对比的基线是什么也没写。外部团队的数据目前拿不到。
定价方面，博客没有提 Projects 是否单独收费，也没说数千个子智能体跑起来按什么口径计量。在云端长时间挂着成百上千个智能体，开销不会小，这部分要等 Cursor 补充计费说明。
两步接成一条线
放回 Cursor 这半年的动作里看，Projects 是往下接的一环。4 月发布 3.0 时，Cursor 把 IDE 重新定位成管理 Agent 的界面；9 月初又让云端 Agent 能跑进企业自有的机器。Projects 把这两步接上了：人管协调者，协调者管执行者，执行者可以在云上，也可以在公司自己的服务器上。
同一天 OpenAI 上线的 Agents API 也支持主智能体拆任务给子智能体，两家的切口不同：OpenAI 卖的是给开发者搭智能体的底座，Cursor 卖的是直接替团队干活的成品。Projects 的入口在左侧导航栏，官方建议只在跨多个 PR 或持续较长的工作上用它。
参考来源：Cursor 官方博客、CocoLoop、MarkTechPost；Cursor 博客核验子智能体规模、PR 合并增幅口径与案例细节。