2026 年 9 月 10 日，AI 编程工具 Cursor 的开发方 Anysphere 推出 Projects，正式进入 beta 阶段，并从当天起逐步向所有用户开放，入口位于编辑器左侧导航栏。这不是一次模型升级，也不是价格调整，而是把 AI 编程从”帮你写完这段代码”推进到”替你管住一整摊活”。
协调者不写代码，只管派活
传统 AI 编程助手的形态是：打开一个对话框，描述任务，智能体改文件，检查，结束。关掉标签页，上下文随之消失。对于二十分钟能修完的缺陷，这没什么问题；对于一场持续三周的迁移，用户就得一遍又一遍地向新智能体重述代码库的结构、约定和此前的决策。
Projects 针对的是后者。官方将其描述为承接”一项功能、一次迁移或一个完整应用”这类规模工作的容器，可以在长达数月的时间里保持上下文，把任务委派给成千上万个子智能体，并且在没有提示的情况下自动完成周期性工作。
其中真正的变化是角色拆分。项目中的协调智能体本身并不编写代码，它负责规划工作、把工作委派给具体实现的智能体，并将完成的成果交回给用户检查。Cursor 的更新日志明确写道：”项目中的协调智能体本身并不编写代码，而是负责规划工作、把工作委派给具体实现的智能体，并将完成的成果交回给你检查。”
这种设计带来一个直接好处：因为协调者从不亲自动手改代码，它永远不会被某个长任务卡住，用户随时可以打断、改方向，而不必等它把手里的编辑做完。
默认跑在云上，上下文会自己长
Projects 默认运行在云端。每个项目都跑在一台属于自己的计算机上，合上笔记本也不会中断，因而能并行运行远超本地机器承受能力的子智能体数量。当某项任务确实需要在用户本机上测试时，协调智能体会另外启动一个本地智能体执行。
真正让这套系统产生复利的是共享上下文。每个项目维护一组文件，并在其智能体所使用的每一台云端和本地机器之间保持同步。智能体会持续往里补充研究成果、中间产物、对代码库的了解以及用户偏好的工作方式。官方举的例子很直白：一旦某个智能体摸清了如何测试某项服务，之后的每个智能体都能直接复用这些说明。
这与常见的做法有本质区别——它既不是外挂的记忆服务器，也不是手工维护的规则文件堆，而是与协调者绑定的、文件形态的项目级记忆。
订阅机制：不等指令就自己动
Projects 还引入了一项叫”订阅”的能力。协调智能体可以监听某个 Slack 频道、按计划定时运行，或者跟踪用户的全部拉取请求，并在请求打开或合并时自动修复持续集成问题。换句话说，把订阅指向缺陷上报频道之后，每当有新缺陷提交，系统就会自动开始分派任务，无需人工发出提示。
内部已经跑了几个月，数据怎么看
Cursor 的工程师已经内部使用 Projects 数月，场景包括涉及数百个拉取请求的迁移、设计系统维护，以及用 Projects 开发 Projects 本身。其中一个设计系统项目会扫描新提交的拉取请求、抽取可复用组件，并在遇到同样的错误两次之后自动创建一条 lint 规则；Cursor 预计这套流程每天会触及 20 到 100 个拉取请求，由一名工程师负责审核。
官方同时给出了两组生产力数据：新用户合并的拉取请求数量提升 30%，以 Projects 为主要工作方式的用户合并量达到六倍。不过这两组数字均为内部自报，未提供样本量、测量窗口与基线，其中六倍的说法更是以”是否重度使用 Projects”来划分人群，属于产品分组指标，而非因果证据。2025 年 METR 的随机对照研究可作参照：16 名资深开源开发者在允许或禁止使用 AI 工具的条件下完成了 246 项任务，结果显示工具带来的提速并不总能兑现。
成本这道坎绕不过去
Projects 底层复用的是 Cursor 已有的子智能体机制。每个子智能体在独立的上下文窗口中运行，从干净状态开始自主工作，完成后把结果返回给父智能体；自 Cursor 2.5 起，子智能体还能启动自己的子智能体，但层级到此为止。在隔离模式下，每个子智能体拥有独立的 Git 工作树或专用云虚拟机和仓库副本，并行时不会互相覆盖，改动在父智能体合并之前停留在各自分支上。
代价同样写在了官方文档里：并行运行五个子智能体大约消耗单个智能体五倍的 token，且对于简单任务反而更慢，因为每个子智能体都要从零开始。用户买到的收益是上下文隔离，不是速度。数千个子智能体的消耗如何计入用户额度，目前仍是这项功能能否真正被用起来的关键问题。
从更长的脉络看，Projects 是 Cursor 联合创始人 Michael Truell 在 2 月 26 日提出的”第三个时代”论述的落地版本——AI 编程正从自动补全，走向同步智能体，再走向可长时间、低干预运行的智能体集群。一周前，Cursor 刚让云端智能体能够跑在用户自有的机器上；Projects 解决的则是另一件事：当一摊活要干几周之后，智能体到底能记住什么。
