你不缺更好的 coding agent。你缺一个不会被堵死的协调者
真正的瓶颈不是单次输出的智商。是你的工作体，已经活不过一次聊天窗口。
大多数人还在问：怎么让 agent 写得更聪明一点。
问错了。
真正的瓶颈不是单次输出的智商。
是你的工作体，已经活不过一次聊天窗口。
功能要跨几周。迁移要跨几百个 PR。设计系统要天天修。
而你仍把这一切塞进会遗忘的会话里。
合上电脑，上下文就断。
第二天，你又在给新窗口重新讲一遍故事。
这不是杠杆。
这是 psychic entropy：注意力被反复用来重新开机。
2026 年 9 月 10 日，Cursor 博客正式推出 Projects。beta，当日开始向全部用户滚动。
它承接的是更大工作体：功能、迁移、整应用。
跨数月保持上下文。
把任务委派给大量子 agent。
还能在无人提示时做周期性工作。
2 月他们谈过「第三纪元」：舰队式 agent 承接整块工作。
Projects 是那套愿景的落地，不是又一个会写代码的对话框。
默认陷阱：你以为自己在指挥，其实你在执行
看看你现在怎么用 AI 写软件。
开一个 chat。
描述需求。
等它写。
改。
再开一个 chat 修 CI。
再开一个 chat 做迁移的下一块。
再开一个 chat 盯设计系统漂移。
你以为自己是导演。
其实你是调度台本身。
窗口越多，你越忙。
你越忙，越像一个被 agent 反雇佣的人。
这就是 99% 的默认路径：
把「agent 数量」当成进步。
把「更会写的模型」当成战略。
把「我还在线」当成系统可用性。
结果是：
你的注意力被切成碎片。
项目记忆散落在十几个线程里。
任何活过单次对话的工作，都在你合盖那一刻失忆。
这里有一个不舒服的事实：
当执行变便宜，稀缺的不是执行者。
稀缺的是不会被堵死的协调层。
第一性原理：抽象必须上移一层
软件工具史上，每次真正的跃迁，都不是把旧动作做得更快。
而是让人退出那个动作。
编译器出现后，人不再手写机器码。
云出现后，人不再天天搬服务器。
现在 agent 能写代码了。
下一步不是「再雇一个更会写的 agent」。
下一步是：你不再亲自管理一堆 agent。
Cursor 内部已经把这层抽象用了数月。
数百 PR 级迁移。
设计系统一致性。
甚至用 Projects 自己把 Projects 做出来。
官方博客给出的效果数字：
新用户合并 PR 约多 30%。
主要用 Projects 的用户，合并量约 6×。
（以上为官方博客数字，非第三方审计。）
数字本身不神秘。
神秘的是机制：谁在写代码，谁在指挥，谁在保存记忆，谁在等信号。
把这四件事拆开，你才会看见 Projects 真正卖的是什么。
不是又一个 coding agent。
是项目级的操作系统：协调者 + 共享上下文 + 订阅。
反转：协调者不写代码，所以它不会被堵死
你和 Project 的交互，是跟它的 coordinator agent 对话。
关键一句：
coordinator 自己不写代码。
它指挥其他 agent 去写。
因为委托而非执行，它不会被堵死，始终能响应你的方向。
这句话听起来像产品文案。
其实是身份设计。
执行者一旦下场写代码，就会被编译、测试、网络、等待卡住。
卡住的瞬间，整个指挥链失联。
协调者如果坚持只做指挥，指挥链才活着。
这正是 doers 与 directors 的分界，落到工程里的物理形态。
你要的不是「更勤奋的执行者」。
你要的是「始终在线的导演席」。
Projects 把导演席做成了产品默认。
三块能力：云、记忆、信号
Projects 能成立，靠三块能力咬合。不是功能清单，是一套物理约束。
1) 默认在云上跑
Project 默认跑在自己的机器上。
合上笔记本，它不停。
需要本机试跑时，coordinator 再拉起本地 agent。
含义很直接：
你的缺席，不再等于项目停机。
并行度也不再被你的笔记本风扇定义。
2) 共享上下文文件同步
你不该每次开任务都重新 onboard 一个 agent。
每个 Project 维护一组文件，在云与本机之间同步。
agent 往里写入研究、产物、测法、偏好。
一个 agent 摸清了某服务怎么测，后续 agent 直接复用。
上下文跟着项目生长。
coordinator 因此越来越像「懂你这盘棋的人」，而不是每次都要自我介绍的陌生人。
这是对 psychic entropy 的工程解法：
把重复解释，从人的注意力里挪进系统记忆。
3) Subscriptions：让信号替你敲门
coordinator 可以盯 Slack。
可以按日程跑。
可以跟全部 PR：修 CI，在开合时行动。
它不等你每次提示。
它等信号。
多数人把 agent 用成「我喊一句，你动一下」。
Subscriptions 把关系改成「世界动一下，你该动的时候再动」。
前者是聊天。
后者是制度。
三种用法：功能、迁移、园艺
Cursor 工程师的用法，大致落在三种模式。
你可以当成可执行模块，而不是励志口号。
1) Feature work：让项目学会你的偏好
大块功能单独开一个 Project。
通常先让 agent 研究系统，把学到的东西写入共享上下文。
coordinator 再出计划，把实现与测试并行派下去。
每轮反馈，Project 更懂架构与你的偏好。
该本机试了，再起本地 agent。
上线后，同一 Project 还能盯日志、接 bug，带着当初决策的完整上下文。
重点不在「一次写对」。
重点在：记忆跨过了对话边界。
2) Migrations：先定安全路径，再批量推 PR
迁移最容易开始，最难收尾。
Cursor 内部用它做过框架采用、样式系统替换，规模到数百 PR。
你先和 coordinator 定安全路径。
再增量推到代码库。
早期你细审每个 PR。
后期修好了，你审得更少，它继续自己推。
这是信任曲线，不是盲信。
也是 director 的工作：早期校准标准，后期抽查边界。
3) Gardening：一天动 20–100 个 PR 的那种活
有些工作永远不会结束。
代码质量。回归。设计系统漂移。
你可以让 coordinator 跟新 PR、听 Slack bug、按日程跑。
有新活就动。
官方提到团队里有人这样跑设计系统 Project：
先审每个修复，纠错。
后来 coordinator 扫描每个新 PR，抽出该进设计系统的组件，同类错误出现两次就加 lint。
该 Project 目标是一天动 20–100 个 PR。
人只在需要注意力的地方出现。
Gardening 这个词很准。
不是冲刺。
是持续修剪，让熵不再堆积。
入口很简单。身份切换很难
左侧导航开 Project。
描述你要建的东西。
coordinator 接着干。
官方说：它最适合活过单次 chat 的工作——多 PR 功能、迁移、或你离开时仍要处理的事。
入口不难。
难的是你愿不愿意改身份。
如果你仍把自己定义成「写得最快的那个人」，Projects 会让你不安。
因为系统在逼你上移：
从敲代码，到定标准。
从追会话，到设订阅。
从记得一切，到让共享上下文记得一切。
从被执行堵死，到保持可指挥。
这不是鸡血。
这是分工。
冷静收尾
Cursor Projects 不是又一个 coding agent 介绍。
它是把「舰队式 agent」收成可指挥的项目层：
一个不写代码的协调者。
一套会生长的共享上下文。
一组会响应 Slack、日程与 PR 的订阅。
你可以继续在聊天窗口里当全能执行者。
也可以开始当导演：定路径、校准早期 PR、把重复劳动交给会呼吸的项目。
模型名字会换。
窗口皮肤会换。
不变的是这个问题：
当工作体已经活过单次对话，你有没有一个不会被堵死的协调者，配得上那几个月的上下文。
出处：https://cursor.com/blog/projects
来源：Cursor：Introducing Projects（2026-09-10）。效果数字为官方博客数字，非第三方审计。