Cursor 派 1000 个 Agent，先查三笔账

9 月 10 日，Cursor 发了 Projects（beta）。官方原话是：一个协调者 agent，自己不写一行代码，把活派给几千个子 agent 并行干，你合上笔记本它也不停。

我读完公告的第一反应不是"好强"，是想起两个月前那张 $3,538.86 的账单——那次是计费系统把 subagent 的模型算错了。这一次，Cursor 把"subagent"从一个功能变成了一整套工作方式：bug 进 Slack，协调者自动派单，PR 开出来，CI 挂了自动修，你没点过任何一个按钮。

新鲜的不是技术。Claude Code 的 subagent、OpenAI 同天发的 Agents API，架构上都长得像。真正改变规则的是默认姿势：它鼓励你把"要不要启动 agent"这个决定，从你手里交出去。

官方给了一个很漂亮的数字：重度使用 Projects 的用户，merge 的 PR 量是对照组的 6 倍。新用户整体多 merge 30%。

我盯着 6 倍看了很久。如果 agent 开的 PR 多了 6 倍，你的团队多出来的工作量在哪？不在写代码——在审代码。瓶颈从"写"整体迁移到了"审"，而 Cursor 没有公布任何关于 review 质量的数字。

第一笔账：成本不是订阅费，是按 API 价计费的并行 token

Projects 没有单独定价。它跑在 Cursor 的 Cloud Agents 上，按你选的模型的 API 价计费。eesel 的实测文把这个说得很直白：5 个子 agent 并行，token 消耗大约是 1 个 agent 的 5 倍。

听上去是废话，但你把这个乘进 subscriptions 模式就不一样了。协调者盯着你的 PR 列表和 Slack 频道，来一个触发一次派单——这不是"你用多少花多少"，是"外面发生多少事你花多少"。一个热闹的 repo、一个活跃的 bug 频道，烧钱速度和你的使用强度无关。

有三个具体动作值得做：

1. 开 Projects 之前，先去 Settings → Billing 设美元额度告警。Cursor 今年 6 月重建过这套告警，不用白不用
2. 第一个 Project 别挂 Slack 订阅，先手动触发，跑一周看 token 曲线，再决定哪些信号值得自动派单
3. Teams/Enterprise 套餐注意 Cursor Token Rate 那笔每百万 token $0.25 的附加费，量大的时候它不是零头

第二笔账：上下文是文件，不是记忆——跨 Project 的决策会丢

Cursor 说的 "shared context over months" 有精确的边界：同步的是一组文件，跨这台 Project 的所有云机器和本地机器生效。而子 agent 每次启动都是"clean context"——它拿不到父 agent 的对话历史，只能靠 prompt 里带的那些。

这个设计的含义是：凡是没落进文件的东西，下一个 agent 就完全不知道。

MemoryLake 的分析里有一刀切得很准：把 Project 里积累的东西分两类。"怎么起 payments 服务的测试环境"是工件（artifact），属于这个 Project，放 Project 文件里没问题。"我们不加没有 owner 的依赖"是决策（decision），它在下一个 Project、在 code review、在三个月后依然成立——但 Cursor 的架构里没有任何一层负责把它带过 Project 边界。

意味着你现在就该立一条团队规矩：每个 Project 开工时，协调者的 context 文件里必须有一份"决策清单"指针，指向一个跨 Project 的地方（哪怕只是个 repo 根目录的 DECISIONS.md）。否则你会在四个月后开第五个 Project 时，发现自己在给第五个协调者重新解释同一套规矩。

第三笔账：并行不等于安全，隔离要自己画

Cursor 官方文档有一句不太起眼的警告：多个子 agent 共享默认 checkout 时会互相覆盖。解法是给每个子 agent 独立 worktree 或云分支。

但"不被覆盖"只是隔离的最浅一层。社区评测（aireiter 的迁移实测文）给了一个更完整的"安全派单边界"清单，一个任务要能被放心派给子 agent，至少要满足五条：

• 有明确的 owner 和文件范围
• 有写下来的输入/输出契约
• 有能跑的 build + test 命令
• 有独立分支或 worktree
• 有一句人能看懂的 definition of done

少一条，并行度越高，事故复制得越快。这跟我写过的工程信任三件套是同一个逻辑：计费、权限、运行，任何一层没有验证路径，放大 1000 倍就是把事故放大 1000 倍。

另外还有个小信号值得留意：Cursor 论坛已经有人在报 multitask mode 下 forked subagent 挂起的 bug（transcript 只存了注入的 user 消息就冻结）。beta 期的并行派单，稳定性还没到可以闭眼信的程度。

读者动作清单

如果你打算这周开第一个 Project，按这个顺序做：

1. 先写环境，再写目标。 Cursor 自己说"不给云 agent 配开发环境，就像不给工程师配电脑"。用 Dockerfile 或 snapshot 把环境钉死，再用一段对新工程师级别的 onboarding 文字描述目标。模糊目标产出模糊 PR，这是官方都承认的
2. 拿绿色地当试验田。 第一个 Project 选一个非核心服务或积压迁移，别上来就怼主产品。跑一周，记录三件事：token 花多少、你花在 review 上的小时数、逃逸出去的 regression 有几个
3. 给"自动派单"画一条白名单线。 把 subscriptions 触发器分成两类：观察类（出报告、出摘要，可以自动）和动手类（开 PR、改代码，必须人工确认第一次）。跑一个月再合并

做到第三条之前，别让协调者在无人值守时拥有"直接开 PR"的权限。一个新工具最大的风险从来不是它不行，是它能跑而你还没决定让它跑多远。

这不是"又一个 agent 功能"

去年底到今天，coding agent 的主线一直是"让单个 agent 更能干"。Cursor Projects 拐了个弯：它承认单 agent 的天花板，把产品力押在"协调"上。

这个弯拐得对不对，赌注不在 Cursor 的 6 倍 PR 数据里，在你的 review 队列里。写代码的成本在 token 化，审代码的成本还在人肉化。这个剪刀差一天不闭合，"1000 个子 agent"就一天是账单功能，不是生产力功能。

怎么闭合，目前没有现成答案。但至少有一件事是确定的：在你想清楚"派出去的每个子 agent 出错了谁能发现"之前，先别让 1000 个同时跑。

—— 完 ——