做大功能时，Cursor 的数千 Agent 要过四关

一项功能拆到十几个 PR，最难收尾的常常不是哪段代码写不出来，而是没有人还说得清第七个改动为什么存在。

Cursor 刚发布的 Projects，就是冲着这种活来的。它把一个功能、一场迁移，甚至持续数月的维护工作，放进一个长期运行的 Project。你不必逐个管理执行 Agent，而是和一个协调者对话，由它拆任务、派活、收结果。官方的说法很猛，协调者能管理数千个子 Agent。

好家伙，看到数千这个量级，很多人脑子里大概已经有画面了，今天把积压的迁移丢进去，明天醒来仓库就自己长好了。

Cursor 官方发布图，Projects 用一个长期任务容器汇总持续推进的工作。

我觉得先别急着把它当成更大的聊天窗口。Projects 真正把一件事推到你面前，代码生成越来越像可扩展的工时，验收和约束却不会自动扩展。你开得越久、派得越多，这四关越该写在第一条任务前面。

本文没有独立实测 Projects。下面对产品能力的描述来自 Cursor 的发布说明和更新日志，四关是基于这些公开能力做的工程判断。

第一关，别把一个模糊愿望当成 Project

Projects 最适合的是一次 chat 结束不了的工作。Cursor 给出的典型场景是大功能、跨数百个 PR 的迁移，以及持续盯着回归和代码质量的维护任务。

这几个场景有个共同点，它们都能被切成可验证的阶段。迁移有目标版本、受影响目录、回滚点。功能有接口、数据变化、用户路径和验收结果。维护有触发信号和明确的修复范围。

如果你给它的是「把老项目整理一下」「顺便把体验做漂亮」，那不是任务，是一团很贵的雾。协调者会努力把雾切碎，子 Agent 也会很勤快地改文件，但它们无法替你决定什么算完成。结果出来一串 PR，看着热闹，审起来像在翻一个陌生人的行李箱。

所以启动前先把任务压成一个能判定成败的句子。不是「迁移到新框架」，而是「把支付域的三个服务迁到新框架，保留现有接口，核心流程测试通过，出现支付差异就停止推进」。这句写清楚后，Agent 才有边界，人也有叫停的理由。

Cursor 的协调者不直接写代码，这个设计我很认同。它把规划和执行分开，协调者不会因为卡在一条命令上失联，仍能回到你这里收新的约束。但别误会，协调者不写代码，不代表它不需要被管理。它更像一个不会下班的项目经理，方向错了会把错误放大得很有纪律。

第二关，让上下文变成文件，不要变成聊天记忆

Projects 的核心卖点之一是共享上下文。官方说明里，每个 Project 会维护一组文件，在云端和本地机器间同步。执行 Agent 学到的测试方法、代码库习惯和研究产物，会被后续 Agent 复用。

这很关键。大任务最怕的不是单个 Agent 忘记，而是每个新 Agent 都从「这个仓库怎么跑」重新猜一遍。猜一次没事，猜五十次，CI、目录边界和命名约定就会被各自理解出五十种版本。

不过共享上下文不是自动变成团队知识库。谁来写测试命令，谁来标识不可改的公共接口，谁来记录一个失败方案为什么被放弃，这些内容仍然需要人定格式。文档模糊时，Agent 会非常擅长地复用模糊。

我会把 Project 的起点控制在四个小文件里，短一点反而更有用。

goal.md       目标、非目标、停止条件
architecture.md  不可破坏的边界与关键依赖
verification.md  必跑测试、人工检查项、回滚方法
decisions.md  已确认的取舍，以及哪些问题必须升级给人

这不是多写文档，是给后续每个 Agent 一张不容易走丢的地图。Cursor 也提到，一个 Agent 摸清某项服务怎样测试后，后来的 Agent 可以继续使用那份说明。前提是说明真的被写下来，而不是藏在某次聊天的第 43 轮里。

协调者负责分派，边界、上下文、权限和验收仍要有人提前画清。

第三关，云端持续跑，权限别跟着持续放大

Projects 默认跑在云端的独立机器上，合上笔记本也不会停。需要本机测试时，协调者可以启动本地 Agent。这个能力解决的不是「能不能多开」，而是让长期任务不再受你的屏幕和睡眠时间限制。

厉害了，也因此更该把权限当成产品的一部分，而不是安装时随手点掉的弹窗。

一个能监听 Slack、按计划运行、追踪 PR，并且能在本地或云端执行命令的系统，接触到的是你日常最敏感的几层东西，代码、构建环境、密钥、内部讨论和部署路径。权限开得越广，错误路径也越长。

我自己的判断是，先把 Project 放在低风险、可回滚的区域。先让它做测试补齐、样式迁移、文档同步、CI 故障归类。涉及生产数据、付费链路、密钥轮换和删除操作，仍然要求人确认，或者放进隔离环境。

Cursor 早先关于长时间运行 Agent 的研究文章也写得很坦诚，长期协作仍会遇到漂移、任务运行过久和需要重新启动的问题。多 Agent 不是让这些问题消失，只是让它们发生时更有规模感。不是哥们，权限一旦和规模绑在一起，复盘时可没有撤销键。

第四关，把验收放到每一段，不要拖到收尾

Cursor 提到，他们内部用 Projects 做过数百个 PR 的迁移，也用它维护设计系统。官方还给出一组内部数据，新用户合并 PR 数提高 30%，主要使用 Projects 的用户达到原来的六倍。这个数字值得关注，但它是官方自报，发布页没有给出样本范围和对照方法，方向可以参考，幅度别当成预算表。

真正该盯住的是 PR 还在不在可审的大小。一次迁移被拆成几百个 PR，并不自动等于风险被拆小了。若每个 PR 都缺少测试结果、变更说明和回滚办法，你只是把一个大坑铲成了几百个小坑，轮到人验收时照样没法下脚。

可以给协调者一条很朴素的规则，任何 Agent 提交前都要回答四件事，改了什么，为什么现在改，跑了哪些验证，失败时怎么撤回。回答不全就不进入下一批任务。这个规则不会让系统显得多酷，却能在第 80 个 PR 出现时，帮你找回最开始那条线。

启动 Projects 前，我会照着下面这张清单过一遍。

范围是否能在一个验收句里说清
共享上下文是否已经落成目标、边界、验证和决策文件
云端与本地 Agent 分别拿到了哪些最小权限
每个 PR 是否都有验证结果、负责人和回滚路径

这四项里只要有一项是「以后再补」，就先别让数千个 Agent 出发。多 Agent 最迷人的地方，是它让小团队也能推动以前不敢碰的大工程。它最容易骗你的地方，也是进度条会跑得比判断力快。

Cursor Projects 目前还是逐步开放的 beta。要不要用，不取决于你手上有没有足够大的需求，而取决于你是否已经能把大需求拆成可验证的边界。边界立住了，协调者才是助手。边界没立住，它只会把模糊执行得很勤奋。

你手上有没有一种总是开头很快、收尾却拖到没完的工程活？如果要交给长期运行的 Agent，你最不愿意放掉的那一关是什么？