9 月 10 日，Cursor 正式推出 Projects（beta）。这个功能的野心写在官方那句描述里：让你能承接”一项功能、一次迁移、或一个完整的应用”这种量级的工作——它能在长达数月的周期里保持上下文，把任务委派给成千上万个子智能体，还能在没有提示的情况下自动执行周期性工作。
一周前 Cursor 刚发布自托管机器，回答的是”Agent 在哪跑”；Projects 回答的是另一个更麻烦的问题：Agent 怎么记住、怎么编排那些活了几周还没干完的活。
一、核心机制：协调者不写代码，只负责调度
Projects 的架构分三层，理解清楚这三层，后面就不会被宣传语绕晕。
第一层：协调者智能体与执行智能体分工。 协调者本身不写代码，它做的是拆解工作、创建并管理执行智能体、按需要并行跑任意多个、最后把成品交回给你审查。这是对默认 IDE 模式的刻意拆分——过去是一个 Agent 在同一个会话里既规划又改文件，Cursor 赌的是：面对大工程，编排质量比单线程写代码的速度更重要。
第二层：云端默认运行，按需回到本地。 每个 Project 跑在独立的云端计算机上，所以合上笔记本电脑也不会中断，也才撑得起海量子智能体并行——这是本地算力做不到的。当某个任务必须在你的机器上测试时，协调者会自动启动一个本地智能体在本机执行。
第三层：共享上下文文件。 官方原话是”你不应该每次开始任务都得给智能体重新上手介绍一遍”。每个 Project 维护一组文件，并在它用到的每台云端与本地机器之间同步；智能体会不断往里补充研究成果、artifacts、对代码库的理解，以及你的偏好。举个具体例子：一旦某个智能体摸清了某项服务怎么测试，之后每个智能体都能直接复用这套说明。
值得注意的是，这是文件形态、项目级、会随时间累积的记忆，而不是打开新对话就清空的上下文窗口。对一直靠第三方 MCP 记忆服务器或手写 rules 文件来补这个缺口的团队来说，Cursor 相当于把这一层做成了原生能力。
二、怎么上手：从一次迁移开始最稳
Projects 目前在 beta，正在逐步向所有用户开放。上手路径建议这样走：
- 在左侧导航栏打开「项目」，新建一个 Project。
- 先别上大工程。挑一个边界清楚、可验证的任务起步，比如”把某个组件库的旧 API 全量替换掉”或”给某个模块补齐回归测试”。
- 让协调者先做研究、建立共享上下文，再产出计划给你确认。
- 计划确认后让它分派子智能体并行实现与测试；本地测试环节它会自动起本地 Agent。
- 前期严格人工审查 PR，等方案成熟后再逐步放开，让协调者自主推进。
官方还提到一个容易被忽略的入口——Subscriptions：你可以让协调者监听某个 Slack 频道、按计划运行，或跟踪你的所有 PR，检测到信号就主动行动，不用等你发提示。把 Slack 接到缺陷上报频道，之后每来一个 bug，它会自动开始分派任务。这一步很关键，它把”你要记得喊它”变成了”它自己会醒来”。
三、三大落地场景
Cursor 官方把 Projects 的适用面归纳为三种模式，基本覆盖了大团队最痛的几件事：
- 功能开发。 智能体先研究并建立共享上下文，协调者制定计划、指派子智能体并行实现与测试；上线后还能持续监控日志、处理 bug。
- 代码迁移。 框架大升级、样式全量替换这类”开始容易收尾难”的活，能在数百个 PR 中逐步推进。前期人工严格审查，后期方案成熟后由协调者自主持续跑。
- 持续性”园艺”维护。 代码质量监控、回归测试这类长期事项，比如自动提取设计系统组件并在线生成规则，把治理变成常态化自动流程。
官方透露，内部团队已经深度测试数月，并把 Projects 用在涉及数百个 PR 的迁移与功能发布中。数据是：新用户合并的 PR 数量增加 30%，而主要依赖 Projects 的用户，合并 PR 数量达到平时的 6 倍。
四、局限与提醒
热闹归热闹，有几件事得说清楚：
- “数千个子智能体”是并行上限，不是承诺。 你下一个 bugfix 不会真的开出上千台 VM。把它理解成协调者能铺开的最大规模即可。
- 它解决的是”大工程”，不是”小改动”。 如果你只是改几行代码，Projects 的编排开销反而多余，普通对话模式更顺手。
- 共享上下文会累积，也会带偏。 Agent 自己往文件里写的研究笔记和偏好，如果早期写错了，后面每个智能体都会继承。定期回看这些文件，比什么都重要。
- 它是 Cursor 边界内的记忆。 如果你的工作流同时横跨编辑器、CLI 和 Claude Code，需要跨工具记忆，Projects 不一定能替代现有的 MCP 记忆方案。
- 安全边界仍然要自己守。 云端并行跑大量子智能体，权限范围、密钥隔离、可回滚策略都得提前定好——恶意 Git 仓库攻破 7 款 AI 编程工具那件事提醒我们，Agent 拿到的执行权越大，入口的检查就越不能省。
五、影响分析：多智能体从”研究演示”走向”工程日常”
把时间线拉长看会更清楚。2026 年这一路是这么走过来的：Goal 模式给了单次对话一个完成条件（智谱 ZCode 的 Goal 模式 + 子智能体），事件订阅让云端 Agent 能被 PR 或 Slack 唤醒，Agent 集群在科研尺度上验证了”规划者—工作者”的经济性（1 万个 AI Agent 花 88 小时解千禧年难题）。Projects 做的事，是把这些原语堆进一个以周为单位、能持久存活的工作容器里。
而”协调者不写代码”这个设计选择，其实在呼应吴恩达说的 Coding Agent 五项能力——能不能让 Agent 连跑几小时不是本事，能不能在长周期里保持方向、把活拆对、把结果收回来，才是。当编排层被产品化，团队里最稀缺的能力就从”会写 prompt”变成”会定义任务边界和验收标准”。
对国内开发团队，我的判断是：Projects 这类功能真正的门槛不在工具，而在你有没有一份能被拆解的工程规范。没有清晰的任务边界和验收标准，协调者再聪明也只是把混乱放大数千倍。
六、老达点评
Cursor 这一步踩得很准，也很现实：它没有去卷模型，而是去卷”工程组织”。
- 如果你在带一个多人团队、常年背着框架升级和技术债，Projects 值得申请 beta 认真试一次——先从一次真实的迁移入手，用”数百个 PR 能不能收尾”来验证它，而不是用 demo。
- 如果你是个人开发者，别被”数千个子智能体”吓到，那是给大工程的规模。你要练的其实是子智能体拆分那套基本功——把一个任务切成人能验收的小块，这个能力在 Cursor、Claude Code 还是别的工具里都通用。
- 如果你在做 AI 副业或接外包，这类工具会直接改变你的报价逻辑：过去按”人力天”算的活，现在要按”能并行推进多少条 PR”来重估。
一句话：Cursor 把”一个人指挥一支 AI 工程队”从演示变成了可以按月跑的产品。接下来真正拉开差距的，不是谁的工具更强，而是谁能把工程规范写得更清楚。
相关阅读
- Cursor 发布自托管机器：企业代码从此不用出内网——Projects 的互补面，一个管”在哪执行”，一个管”记住什么”。
- 智谱 ZCode 用户破百万：Goal 模式 + 子智能体——国产工具对”目标 + 子智能体”的同类探索。
- Claude Code Subagents 怎么用——子智能体拆分的实操入门，与 Projects 的编排思路一脉相承。
- 吴恩达：Coding Agent 用得好不好，看这 5 项能力——长周期 Agent 的评判标准。
专题入口：
