一天开 16 个 AI 子代理 · Cursor 里的战场

那天下午做了个统计。

从两点到晚上八点 · 六个小时里 · 我在 Cursor 里开了 16 个子代理。分成 4 波 (W48/W49/W50/W51) · 每波 4 个 · 全部并行跑。加起来产出的文档 · 500 KB 左右 · 相当于一本中长篇小说。

产品那边 · 一个 Cloudflare Worker 从只支持 Stripe · 变成同时支持 Stripe + Creem 双通道 · 4 个真实产品在生产环境 · 12 种 webhook event 全部端到端测过。

这一切都是我一个人对着屏幕做的。但我不是一个人做的。

什么是子代理

Cursor (还有 Claude Code · Cline · Aider 之类) 有一个能力 · 主 agent 可以派生若干个 subagent · 每个 subagent 拿一份独立的 task prompt · 独立的 context window · 独立的 model 实例 · 可以调工具、读文件、写文件。

它们跑完把结果返给主 agent · 主 agent 整合。

关键在于并行。四个 subagent 同时开 · 每个 30 分钟 · 主 agent 30 分钟拿回 120 分钟的产出。

为什么那天要开这么多

datenix 那个项目 · 主线是把 Creem 集成到 Cloudflare Worker 里。这是一个非常具体的技术任务 · 我一个人边写边测就够了。

但同时我需要做的还有:

• 研究 Creem 完整 API (43 个 endpoint · 12 种 webhook event · 各种 payload shape)
• 对比 Creem 和 Stripe · 决定哪个作主
• 分析 datenix 现有代码 · 决定集成点
• 设计定价 (Free / Starter / Pro / Business / CSV)
• 写完整的 test suite
• 写 admin CLI
• 写 monitor 脚本
• 写 landing v4 (加 Trust & Safety 区块 · 加 About/Contact 页 · 加 refund 徽章)
• 研究 KYC 通过率最高的写法 (Creem 的公开案例 · 拒绝案例)
• 写 launch runbook (Post-KYC 的 6 步命令)
• 写 SESSION_HANDOFF (给下个 agent 接手)
• 判断有没有 fleet 层可复用的抽象
• 判断是否需要 TypeScript 重写

这些如果我全部亲手做 · 得三天。如果我全部交给一个 subagent 做 · 它 context window 会爆炸。

分而治之。每个 subagent 拿一份聚焦任务 · 用 4.7-fast 那个模型 · 30-40 分钟跑完。同时开 4 个 · 一个小时之内我拿到 4 份 4000-5000 字的深度报告。

Wave 是我们的时间粒度

我把 subagent 组织成 wave · 每 wave 4 个。原因是:

• 4 个刚好不太挤 · Cursor 界面能同时展示 4 个 subagent 的状态
• 每 wave 结束 · 我看结果 · 决定下 wave 做什么 · 有反馈
• 4 波做完是一次完整的 iteration (探明 → 设计 → 实作 → 收口)

那天四波:

• W48 · 探明 Creem (API 完整参考 / Stripe 对比 / 集成计划 / 定价)
• W49 · 实作 (TypeScript providers / admin CLI + monitor / landing v4 / test suite)
• W50 · 收口 (launch runbook / refactor 计划 / bootstrap 增强 / SESSION_HANDOFF 归级)
• W51 · KYC 深挖 (approval patterns / 产品可允许性 / landing 精修 / CN payout 策略)

每 wave 之间我大概花 15-20 分钟做归级 · 把 4 个 subagent 的产出 stage 到项目里 · 判断有没有互相冲突。

Prompt 是 subagent 唯一的方向盘

subagent 是没有短期记忆的 · 每次 spawn 是一次全新的 context。它只有 prompt 里给的信息。

prompt 写不好 · subagent 就跑偏。

我写 subagent prompt 的模板大概是这样:

Context (verified facts) · 5-10 行 · 告诉它现在已经确认的事实是什么 · 哪些代码在哪 · 哪些环境变量已经在了。这一段防止它去猜。

Sister-project asset · 3-5 行 · 告诉它可以复用哪些兄弟项目的资产。这一段防止它重新发明轮子。

Goal · 1-2 段 · 明确的产出目标。

Deliver · 分节列出应该交付什么 · 每节几百字。

Constraints · 列出禁忌 · 例如「never touch this file」「compact return 500-800 words」「no fabrication」。

Budget · 30-40 min。让它知道时间。

Write to · 明确的输出路径。

按这个模板 · subagent 跑偏率大概 10%。跑偏的常见原因是我 Context 那一段没把真相说清楚 · 它就用了自己脑子里的猜测。这跟外包给一个新员工是一模一样的道理。

Reality check 是我付出的最大代价

subagent 的一大风险是它自信地编造事实。

那天 W52 那波 4 个子代理 · 3 个都在返回时给了我一份 「reality check」 部分 · 明确指出「你 brief 里说的和实际磁盘上的不一致」。

• W52-2 说「KL 不是 kitchen 品牌 · 是 pickleball · 因为 kitchen = pickleball non-volley zone」
• W52-3 说「SleepGuard SPEC 里其实早就选定 DTC 硅胶封口贴订阅 · brief 里让选 SaaS/DTC/content 三选一 是过时的」
• W52-1 说「DocStruct 22 files 齐 · 但业务层全 stub · checkout 指向假 product_id · webhook 4 个 TODO · lib 目录空」

每个 reality check 都值 · 因为它防止我按错误的假设做下一步 · 避免下游几十个小时的浪费。

我写 prompt 时明确要求「先读磁盘 · 别信我 brief 里说的话 · 有出入立刻指出」。这行字算是 subagent 工作流里最重要的一行。

Task 拆分的经验

一波 4 个 subagent 应该做互补而不是竞争的事:

互补: 一个探 API · 一个对比竞品 · 一个看代码 · 一个设计定价。这 4 个方向完全不重叠 · 4 个报告可以直接拼起来。

竞争: 4 个都被让写「集成方案」。4 份方案回来 · 我要合并 · 冲突要判 · 时间成本反而高。

大部分我踩过的坑都是给 subagent 派了「竞争」类任务。今后我 wave 里的 4 个位置 · 尽量按 「探明 / 对比 / 实作 / 归级」 或 「A 功能 / B 功能 / C 功能 / D 归纳」 分。

主 agent 的责任

主 agent 不是 orchestrator 那么简单 · 它有几个必须做的事:

一 · 每 wave 结束把结果 stage 到项目里 · 检查有没有语法错、路径错、命名冲突。subagent 写的东西 · 主 agent 必须真的读一遍。有一次 W49-2 写的 admin CLI 里有个 async wrapping 的小 bug · 主 agent 立刻发现 · 5 分钟补上。

二 · 更新 handoff / TODO / DECISIONS · 让下 wave 的 subagent 能读到最新的现实。这个是长期项目最容易忽略的。

三 · Compact 每 wave 的产出。subagent 报告是 3000-5000 字 · 全塞给下 wave · context window 顶不住。主 agent 要把每份报告压缩成 200-500 字的 summary · 只把关键 decision 传给下 wave。

四 · 判断哪些 subagent 的建议我要采纳 · 哪些不采纳。W50-2 的 subagent 建议 「defer TypeScript 重写到 Y1」· 我采纳。W49-2 的 subagent 建议 「加一个 KV cache 层」· 我暂时不采纳 · 因为流量还没到需要缓存的量。

一天开 16 个是不是太多

其实那天做完之后 · 主 agent 的 context 也接近满。再多可能就要开新会话重新 resume 了。

粗略的估算是:

• 每个 subagent 的 compact return 大概 500-1000 token
• 主 agent 处理 · 加上自己代码修改 · 加上 tool call · 每个 subagent 加起来占主 agent 大概 3000-5000 token
• 16 个 subagent 就是 50000-80000 token 在主 context 里

如果模型 context 20 万 token · 那还能再开 20-30 个。但主 agent 越挤 · 输出质量越差。

我现在的经验是 · 一个会话开 12-16 个 subagent 差不多是极限。超过就要开新会话 · 让新的主 agent 从 handoff 文档 resume。这也是我每次会话结束都强迫自己写 SESSION_HANDOFF 的原因。

一个反直觉的结论

主 agent 做的实际编程越少 · 整体产出越多。

那天我自己敲代码大概只有 1000 行 · 其他都是 subagent 写的。但我的时间大量花在:

• 写 subagent prompt (每个 500-800 字 · 4 个就 2000-3000)
• 读 subagent 的返回 (每个 500-1000 字)
• Stage 文件、check 语法、跑测试
• 决定下 wave 做什么

这更像是一个 tech lead 的工作 · 而不是一个 developer。

我原来一直以为 AI 工具的价值是替我写代码。那天做完 · 我重新想 —— AI 工具真正的价值可能是替我 「同时思考多件事」。一个人的大脑一次只能想一件事 · 但一个人可以同时监督 4 个 subagent。这就是 orchestration 那部分产生的真正价值。

后来的一个用法

现在我碰到复杂任务 · 会主动想「这个是不是可以拆成 4 个并行 subagent」。

例如客户反馈 「datenix 有 3 个 bug」· 我以前的做法是逐个 fix。现在的做法是开 3 个 subagent · 每人 fix 一个 · 主 agent 归级测试。三倍速度。

例如市场调研 · 「datenix 定价应该是 X 还是 Y」· 我开 3 个 subagent · 一个查竞品定价 · 一个查用户吐槽 · 一个算 unit economics。主 agent 合成决策。

这个模式对我这种一个人做产品的场景太契合。以前我做产品 · 单线程 · 快 · 但覆盖不广 · 容易漏。现在多线程 · 覆盖广了 · 决策质量高了。

一件慢慢冒出来的担忧

有点担心自己会越来越依赖 subagent · 自己动手写代码的能力会退化。

写代码本身还是要写的 · 关键的核心逻辑 (那个 12 event webhook dispatcher · 那个 HMAC 校验 · 那个 D1 migration) 主 agent 亲手写。只有周边配套 (test / doc / admin CLI / research report) 交给 subagent。

以及 · 主 agent 必须自己读 subagent 写的每一行代码。签字盖章。不然到时候上线出 bug · 你不知道从哪开始查。

一个人做产品 · 最大的资产是自己那颗脑子。工具再好 · 也是替脑子扩容 · 不是替代脑子。

那天开完 16 个 subagent 之后 · 我关电脑之前把整个 session 的时间线写成了一份 30 KB 的 handoff 文档。因为我知道 · 明天早上打开 · 我脑子里 60% 的今天的细节都会忘。但 subagent 不会忘 · 因为它就是那份文档。