Cursor 上线 Projects：一个不写代码的智能体，指挥千军

是什么

Cursor 今天推出 Projects，一个用来承接大体量、长周期工作的新功能，比如一项完整的功能开发、一次跨越数百个 PR 的框架迁移，或者一整个应用的搭建和维护。

核心是一个协调智能体。它本身不写代码，只负责把工作拆解开，派发给真正动手写代码的子智能体。因为只做委派不做执行，协调智能体永远不会被某个具体任务卡住，随时能回应你的新指令。

支撑这套机制的是三项能力。默认在云端跑，每个 Project 占用自己的一台计算机，合上笔记本也不影响它继续工作，需要在本地测试时协调智能体会临时拉起一个本地智能体。上下文在整个 Project 生命周期里持续积累并跨云端和本地机器同步，一个智能体摸清了某个服务怎么测试，这份经验后续所有智能体都能直接用上。还可以订阅事件，协调智能体能监听 Slack 频道、按计划运行、或者跟踪 PR 的开合和合并状态，不用等你发提示就能自己动手。

这台云端机器具体什么配置，直接问协调智能体就能问出来。实测结果是 Ubuntu 24.04.4 LTS，x86_64，KVM 虚拟化，4 核 Intel Xeon vCPU，16 GB 内存不带 swap，磁盘约 252 GB。运行用户是 ubuntu，工作区挂在 /workspace，出站网络不受限。默认没有关联 Cloud Environment，也没有 .cursor/environment.json，属于即时启动，没有预构建的 snapshot 或 build，所以也不会跑 install、start、terminals 这些环境层的钩子。

镜像自带的工具链覆盖得比较全：Node 22.14（用 nvm 另外装了 22.22.2）、npm、pnpm、yarn 都在，Python 3.12、Rust 1.83、Go 1.22、Java 21 也是装好的，编译链有 gcc、clang、cmake、git，Chrome 也预装了，但没有 Docker、uv、bun 这几样。仓库刚建好是空的，协调智能体会主动问要不要配一份 environment.json，配好之后 install、start、terminals 这些环境层的钩子才会生效。

这是 Cursor 今年 2 月提出的"软件开发第三时代"构想（由成群智能体承接完整工作）的具体落地。

为什么

Cursor 内部已经用 Projects 跑了数月，做的事情包括数百个 PR 规模的迁移、维持设计系统一致性，以及 Projects 本身的开发。官方给出的数据是新用户合并的 PR 数量提升 30%，重度使用 Projects 的用户合并量提升到原来的六倍。

它把开发者从管理智能体这件事里解放出来，抽象层级往上提了一级：不再需要盯着某个智能体有没有卡住、下一步该给谁分配任务，而是直接对着协调智能体描述你想要的结果。

怎么用

Projects 现在是 beta 阶段，从今天起逐步向所有用户开放。入口在左侧导航栏，Project 旁边有个 + 号，点开会弹出 Create Project 对话框。

对话框中间的输入框是关键：要把你想要的结果、范围、边界写具体，别写"帮我加个功能"这种含糊话，协调智能体规划得准不准，全看这段话写得细不细。下面还有两个选项，Workspace 决定这个 Project 从哪起步，项目是从零开始就选 Start from scratch，已经有仓库要接就在下拉里切过去。Model 决定协调智能体和它派出去的子智能体用什么模型跑，档位越高能力越强也越贵，日常任务用默认档位就够。

点 Create Project 之后别急着丢真实任务，先跟协调智能体随便聊几句，比如问它现在跑在什么机器上、能看到项目里哪些东西，摸清它的能力边界再动手。摸完底给一个具体目标，观察它是不是先做调研、怎么规划、拆成几个子智能体分头干，这一步能看出它到底怎么工作。它做完不会自己推到 main 分支，交回来的东西要你自己审查决定合不合并，这是刻意的信任设计，不是能力限制。熟悉了之后可以让协调智能体盯 Slack 频道、跟踪 PR、按计划自动跑，不用每次都手动开新任务。

具体怎么用，取决于你要处理的是哪一类工作。

功能开发的用法是先让智能体调研系统，把调研结果沉淀成共享上下文，再由协调智能体做规划，派出多个智能体并行实现和测试不同部分。前几轮你需要给反馈，Project 会逐渐摸清你的架构和偏好。功能能试用的时候，协调智能体可以在你自己的电脑上拉起一个本地智能体跑起来。功能上线之后不用关掉这个 Project，同一个 Project 继续监控日志、处理缺陷报告，并且完整保留当初各项决策背后的上下文。

迁移的用法是先和协调智能体一起把方案定稳，再让它在整个代码库里逐步落地。开头这段你要认真审查每一个 PR，等修复方式经过反复验证、你确认没问题之后，审查可以逐步放松，交给协调智能体自己把剩下的迁移推完，不用你逐个盯着。

园丁式维护的用法是让协调智能体长期挂着，跟进新 PR、监听 Slack 里的缺陷报告，或者按固定计划运行，出现新工作它自己接手，不用你手动触发。Cursor 内部一个设计系统 Project 就是这么起步的：最开始工程师要审查每处修复并纠正错误，跑到现在协调智能体已经能自己扫描每个新 PR、提取出属于设计系统的组件，同一个错误第二次出现时自动加一条 lint 规则，这个 Project 有望做到每天处理 20 到 100 个 PR，工程师只在需要人判断的环节介入。

判断要不要用 Projects，看这件事一次 chat 能不能说完。涉及多个 PR 的功能开发、一次迁移、或者希望你离开电脑时也能自动推进的任务，都适合建一个 Project。单次小改动、或者一句话能交代清楚的任务，直接在普通对话里做就够了，不用建 Project。

拿在做的内容流水线项目举个例子会更直观。这个项目要把素材收集、调研、选题、写作、配图、分发六个阶段串成一条自动流水线，说白了就是喂进一堆原始素材，流水线自己去检索资料、想选题、写初稿、配图，最后把成品发出去。目前还在搭建阶段，属于从零开始建一整个应用。

新建 Project 的时候，初始描述要把这六个阶段各自具体做什么讲清楚，比如调研阶段要检索哪些资料源、写作阶段用什么风格、配图阶段要什么调性，讲得越具体，协调智能体派出去的子智能体做出来的东西越靠谱，含糊的目标只会换来含糊的结果。Workspace 选 Start from scratch，因为项目本身还没有代码库可以接。

协调智能体会先摸清整套流水线要接的几个外部服务分别怎么调，比如调研阶段用来做语义检索的数据库、写作阶段要调用的大模型接口、配图阶段要调用的生图接口，这些调研结果沉淀成 Project 的共享上下文，六个阶段各自负责实现的子智能体都能直接复用，不用每个子智能体都重新摸索一遍。规划完之后，六个阶段边界清晰，可以并行派给不同的子智能体分头实现和测试，谁负责调研阶段的代码、谁负责写作阶段的代码，互不干扰。涉及真实调用这些外部接口的部分需要用到真实密钥，协调智能体可以在你自己的电脑上拉起一个本地智能体跑，你能实时看到调用结果，方便联调。

流水线跑起来之后，这个 Project 不用关掉，可以继续盯着运行日志，某个阶段抓取失败或者接口报错时处理缺陷，这是园丁式维护的延续。另外还有一块单独的工作，是想蒸馏出一个更小的模型专门做语音转文字后的清洗和输入法候选词消歧，这个方向跟主流水线要解决的问题不是一回事，边界清楚，更适合单独开一个 Project，不要塞进主流水线这个 Project 里，保持每个 Project 的上下文聚焦。

评价和看法

这个方向不是 Cursor 一家在做。Claude Code 有 Agent Teams，让多个 session 互相协调，新出的 Dynamic Workflows 一次能拉起几十到上百个并行 subagent。OpenAI 的 Codex 有 Codex Cloud，跑云端沙盒任务，PR 出来能自动审查，本地 CLI 也靠 git worktree 跑并行 agent。GitHub 的云端 agent 能直接把一个 issue 变成 PR，跑在 Actions 里不用人盯着。Cognition 的 Devin 走得最彻底，任务丢进去，在自己的云基础设施里跑完再拿回来给你。

这几家共同的动作，都是从"你在场时配对写代码"，挪到"你不在场时也有东西在跑"：云端执行、可并行、可离线推进，卡的位置几乎一样。Cursor 不是在开创这条路，是在同一条赛道上加了个专职调度、自己不写代码的协调智能体，把这套机制做得更完整。

把视野挪出编程范围，还有一个更贴近的参照。Projects 发布前一个月，xAI 上线了 Grok Bot，同样是给每个智能体配一台专属云电脑，同样能跨会话保留记忆和偏好，同样支持多个智能体互相协作。两边看起来像在做同一件事，实际瞄准的是两个完全不同的战场。

Grok Bot 直接操作屏幕，用你本人的账号登录 CRM、邮箱、供应商后台，像员工一样点界面、填表单，官方把它定位成能顶替具体岗位的数字同事，卖的不是写代码的能力，是销售、招聘、财务这类岗位本身，个人版每月 200 美元，团队版每席位每月 120 美元，走的是企业软件的定价逻辑。Cursor 和 xAI 会走到一起并不意外，SpaceX 今年 6 月以 600 亿美元收购 Cursor 后，两家公司正在合并。

Projects 的可靠性有 PR 和 CI 兜底，智能体干错了能直接回滚。Grok Bot 没有这层安全网，业务世界里发错一封邮件、改错一条 CRM 记录，没有 revert 键，只能靠人工审批兜底。这是两条产品路线最本质的差别：代码世界天然自带撤销机制，业务世界不带。

也是为什么 Projects 今天就能大规模铺开用，Grok Bot 还得先把信任问题解决掉。Cursor 选择先把智能体群在代码这种有安全网的场景里跑熟，再考虑往岗位这类没有安全网的场景扩展，顺序上是谨慎的。对做 AI 员工方向的开发者来说，这个顺序值得参考：先在能回滚的场景把智能体群跑稳，验证过协作和调度机制之后，再往不能回滚的场景扩，而不是反过来。