05 · 子 Agent 的成本账

隔离不是甩活。五要素 brief 是生命线。

开场比喻

对前端开发者，子 Agent 最贴切的类比是 Web Worker：

Web Worker 的黄金法则同样适用：只在"真能回本"时才开。

Claude Code 的子 Agent 种类

你环境里常见几种：

每个 agent 都是独立冷启动的，不继承主对话的 context。

成本账：开一个子 Agent 的真实代价

每开一个子 Agent，你付五项成本：

相比之下，主对话自己干：上下文已有，直接用 Read / Grep / Bash，即时反馈，可中断。

什么时候值得开

开子 Agent 的三个条件（满足其一就考虑）：

什么时候不开

并行 vs 串行

规则：一条消息里发多个 Agent 工具调用 = 并行；要等前一个结果再起下一个 = 串行。

并行的好场景

完全独立的任务同时跑：

并行发出：
  - Agent(Explore): 找所有用了 useEffect 的组件
  - Agent(Explore): 找所有 API route handler
  - Agent(general-purpose): 检查依赖是否有 deprecated 的

三个 agent 同时干活，总耗时 ≈ 最慢的那个。

串行的好场景

后一步要前一步的结果：

串行：
  1. Agent(general-purpose): 调研这个库的 API 设计
  2. [读完结果] → Agent(Plan): 基于调研出方案
  3. [读完方案] → 自己实现

常见误用：能并行的硬串行（慢 2-3 倍），或依赖关系的强行并行（后一个拿不到前一个的结果，白跑）。

Brief 的艺术

子 Agent 冷启动，它看到的 prompt 就是它的全部世界。Brief 好不好，直接决定结果有没有用。

五要素公式

[背景] + [具体位置] + [明确任务] + [输出形式] + [长度限制]

对比

❌ 太笼统：

帮我看看 checkout 流程有什么问题

子 Agent：什么流程？什么问题？看哪些文件？多长的回答？…… 乱猜一通，交付模糊。

✅ 完备 Brief：

检查 src/app/checkout 下的提交流程是否有重复提交保护。

背景：QA 报告用户双击 Pay 按钮会重复扣款，我怀疑 handleSubmit 没 debounce。

具体位置：src/app/checkout/page.tsx 的 CheckoutForm 组件，
        和 src/actions/payment.action.ts 的 submitPayment。

任务：
  1. 确认 handleSubmit 是否做了 debounce 或 loading 锁
  2. 确认 server action 是否有幂等检查

输出：
  - 问题确认 ✓ / ✗
  - 根本原因 1-2 句
  - 建议修复方向 3 条以内
  - 不要改代码

长度：300 字以内

子 Agent 有路径、有关键函数、有边界（"不要改代码"），不会跑偏。

常见 Brief 错误

信任但验证

子 Agent 回来的总结是它认为自己做了什么，不等于实际做了什么。

特别要警惕：

• 子 Agent 说"已修改 5 处" → 你自己 git diff 看
• 子 Agent 说"全部测试通过" → 你自己跑一遍 pnpm test
• 子 Agent 说"没有相关代码" → 它可能搜错关键词，自己 grep 一次确认

反模式六连

一句话总结

子 Agent 是"隔离 + 扩展"，不是"甩活"。

开销在那里，Brief 不写到位就是浪费；真正用得好，一条消息里并行三个 agent，能把你从 15 分钟干到 5 分钟。

判断速查

任务来了
  ↓
能在主对话 1-2 步搞定？      ── 是 → 自己干
  ↓ 否
要大范围搜索、独立视角、或 2+ 独立任务？
  ↓ 是
  ↓
2+ 独立任务？                 ── 是 → 一条消息并行多 agent
  ↓ 否
  ↓
能写完 5 要素 brief？         ── 否 → 先想清楚再开
  ↓ 是
开！
  ↓
结果回来，看 diff / 跑验证（不看总结）

← 04 · Plan → Execute → Review 的协作节奏 | 目录 | 06 · Hook 与自动化 →