最近一个月深度体验了 Cursor Projects 之后，我非常的喜欢，而且认为它应该是 Coding Agent 的下一个形态。
可惜目前 AI 产品的风刮到了 Personal Agent。各家都在力推自己的 Personal Agent，Cursor Projects 反倒被自家的 Grok Bot 给压了下去，颇为可惜。
虽说 Grok Bot 体验不错，也自带的一台配置不错的云端电脑。但是如果是开发使用的话，它的交互方式还是让人不太习惯，毕竟是设计给普通人使用的，想精细控制总有些难度。平时在 Codex 和 Grok Bot 之间切换的话，两者的风格差异有点过大。
如果你也有类似的感受，那么我很推荐去尝试一下 Cursor Projects。
什么是 Cursor Projects
Cursor 在介绍它的 Projects 功能的时候，是这么说的：
Projects 让您能够承接更大规模的工作，比如一项功能、一次迁移，或是一个完整的应用。它能在长达数月的工作中维持上下文，向成千上万个子智能体委派任务，并无需提示就自动完成周期性工作。
换句话说，你不需要像传统的 Coding Agent 那样，去精细化地指挥具体的 Agent 对话了，而是直接指挥工作内容，Projects 会自己指挥 Agent 去完成工作。
Cursor Projects 用起来，很像是 Coding Agent 和 Personal Agent 之间的过渡形态。让我们来比较一下：
| Codex | Cursor Projects | Grok Bot | |
|---|---|---|---|
| 工作位置 | 本地 | 云端 + 本地 | 云端 |
| 对话数量 | 多个对话 | 单个对话 | 单个对话 |
| 对话上下文 | 本地目录 | 工作项目 | Bot |
传统的 Coding Agent（例如 Codex），它的使用形态其实是非常单纯的：我们把配置好的开发环境都放在本机，Agent 也运行在本机。我们想做什么的时候，就开一个会话去告诉 Agent。这个会话你可以随意开启多个，每个会话你都可以自己去编辑、压缩、分叉。
而 Cursor Projects 则是一个多 Agent 架构：你只会跟 Orchestrator 进行对话，再由它去分配合适数量的 Agent 执行任务。当需要做第二件事情的时候，你也并不是新开一个对话，而是继续在原有的基础上让Orchestrator 继续去完善。它也会记住你的一些做事方法和要求，然后不断推进工作事项。
可以看到 Cursor Projects 的自由度介于 Coding Agent 和 Personal Agent 之间，把交互收到了单个对话，不再让你去操纵会话，但是又比 Grok Bot 更适合开发使用。
它和 Codex 之间最大的差异点在于你关注的层级不同。用 Codex 的时候，你关注的是一个任务。用 Cursor Projects 的时候，你关注的是一个项目，这也就是 Projects 这个词的由来。
Cursor Projects 适合什么工作
在遇到合适的场景的时候，Cursor Projects 会发挥特别大的作用。我目前的经验是：需要长期跟进的、不断调整改进的工作，非常适合用 Cursor Projects 来做。
最近我在用 Cursor Projects 开发 Beacon，一个 Loop Engineering 框架。我用一个 Cursor Project 跟进 Beacon 的开发、部署，以及 5 个以上的 Loop Engineering 任务（我称为 Profile）的运行、观测、调整。整个过程非常繁琐，因为我需要先开发 Beacon 的代码，代码合并之后打包 CLI，再在另一台 Mac mini 上面部署 Beacon 和 Profile，有各种配置文件。遇到问题的时候，还需要去 Mac mini 上面看 Pi session。
可以想象如果我用 Codex 的话这一切会有多么狼狈：我需要每次告诉 Codex 我的 Beacon 和 Profile 的部署位置，改完之后手动触发打包和部署，还要记住 Mac mini 上的各种 Profile 的位置……
Cursor Projects 则可以完美帮我吃下这一切的琐碎事务。
首先，Cursor Projects 运行在云端，也可以支持接入自己的机器作为 worker。我就把 Mac mini 接成了 worker。这样在开发 Beacon 代码的时候可以在 Cloud 环境，在部署的时候则换到 Mac mini 环境。环境的选择是 Orchestrator 自动做的，我不需要任何干预。
其次，Cursor Projects 可记住各种工作进度和工作流程。当我发现它的工作模式不符合预期的时候，我会纠正它并说「记住这个」。这样它做事的方式就能越来越符合我的偏好。例如我让它每次改完代码之后给我审批 PR，PR 合并之后则自动部署到 Mac mini。这样每次迭代我既能把关，又不需要费心运维。也不需要每次敲一个「PR 合并之后自动部署」的 Prompt。
现在这个项目已经运行接近 4 个星期了。在一开始，我对 Cursor Projects 能做什么还不是很清楚，所以小心翼翼地使用。现在它的职责范围和 SOP 都已经比较清晰了，我便可以当起「甩手掌柜」—— 平时只要是 Beacon 和 Profile 相关的事情，都丢给 Cursor Project，然后就把它放在后台不管了。等到想起来的时候，再过来验收结果。
这个过程非常的省心。不需要想着下一步该控制它做什么——我只需要把事情交给他就好了；也不会因为它的回复打扰到自己——我只需要有空的时候去看结果就好了，它肯定能做好的。
Cursor Projects 的使用技巧
我用 Cursor Projects 搭配的是 Grok 模型。Grok 模型在训练的时候估计专门针对这种场景做了优化，我改用其他的模型，比如 Claude Sonnet 5.5 或者 GPT 5.6 Sol，体验上都远远比不上 Grok。
使用 Cursor Projects 的时候最重要的思路是要转变思路，不要用传统的微操法。比起「应该做什么」，你更应该去描述「目标是什么」，这样才能够让自己省心。既然名字叫 Projects，你应该为一个工作项目开启一个 Project，而不是只用它做一件临时的事情。运行时间越长，Projects 越能发挥它的威力。
当然，一个 Project 刚建立的时候还是要适当地细致指导一些，先让它记住一些 SOP 和你的偏好，然后再逐渐放权。
一个复杂琐碎、需要长期跟进的任务，非常值得用 Cursor Projects，它可以持续跟进任务进展，你可以轻松地从上次中断的地方继续，而不需要在一堆历史会话中翻找，也不需要一遍遍地给它强调做事的流程。
什么情况下不适合用 Cursor Projects
当然，Cursor Projects 也不是万能的，很多场景我会更推荐用 Claude Code 或者 Codex，甚至是 Cursor 自己的对话模式。
- 当你的任务单次需要消耗大量的 Token。Cursor 的订阅并没有那么耐用， 我一般会在一个项目开始的时候先让 Codex 搭好架子（这个阶段需要大量 token），再转成用 Cursor Projects 长期维护。或者你也可以让 Cursor Projects 只负责统筹，具体执行调用 Codex 来做。毕竟真正要干重活，还是 Codex 订阅量大管饱。
- 当你的任务一两天就能搞定。Cursor Projects 的价值在于长期的任务进度和任务流程跟进。用完即弃的任务还没来得及积累就结束了，体现不出它的价值。
- 当你很着急的时候。例如排查告警、处理用户反馈。你可能需要马上要结果。Cursor Projects 作为云端多 Agent，整体产出的速度并没有那么快，可能会给你火上浇油。
- 当你的任务吞吐量比较高。例如需要开 5
8 个会话，同时处理一个任务的多个分支。Cursor Projects 里只有一个主会话，你当然可以同时下发 58 个事项，但是所有的回复都会混在一起，很难处理。 - 非常流程化、固定化的任务。例如「每天定时扫描」或者「当告警出现的时候排查」，虽然是长期任务，但是流程过于固定，用 Cursor Projects 属于大炮打蚊子，还容易浪费额度。这种任务建议交给 Loop Engineering 系统。
等到下次你需要适合用 Cursor Projects 的任务时，不妨一试，它有可能带给你全新的工作思路。