深入浅出Claude Code 的 Subagent 与 Fork Agent —— 多 Agent 协作的两种分身术主 Agent 的上下文是稀缺资源。Subagent 用新建一个干净的专家来省它Fork 用复制一份自己来延续它。同样叫派个 Agent底层是两种完全不同的策略。目录一、为什么一个 Agent 不够用二、Subagent一次性的专家三、Fork Agent父会话的分身四、核心差异对比五、自定义一个 Subagent六、并发与隔离的工程细节七、总结一、为什么一个 Agent 不够用1.1 三个绕不过去的瓶颈瓶颈症状后果上下文污染为了找一行代码读了 30 个文件噪音永久留在主上下文挤掉真正重要的信息单线程执行只能一个工具接一个工具跑三个独立子问题要串行做完慢视角单一写方案的和评方案的是同一个人自己审自己盲区照不到1.2 两种解法解法 A新建一个干净的专家 → Subagent上下文隔离 解法 B复制一份当前的自己 → Fork Agent上下文继承核心观点Subagent 解决的是别把噪音带回家Fork 解决的是别丢掉已有的背景。方向正好相反。二、Subagent一次性的专家2.1 它是什么Subagent 是主 Agent 通过Agent工具拉起的独立子任务执行体关键特征只有一个 ——独立的上下文窗口。主 Agent 上下文 ┌────────────────────┐ │ 用户需求 │ │ 讨论过程 / 关键决策 │ │ 少量摘要 │◀── 只有 final message 回得来 └─────────┬──────────┘ │ Agent 工具只传一个 prompt 出去 ▼ ┌──────────────────────┐ │ Subagent 上下文 │ 全新的、空的窗口 │ ├ 自己的 system 提示 │ │ ├ 自己的工具集 │ │ ├ 读 30 个文件的噪音 │ ← 噪音到这里为止 │ └ 产出结论 │ └──────────────────────┘2.2 四个自己的维度Subagent 的行为上下文全新不继承父会话历史系统提示词来自 agent 定义不是主 Agent 那份工具集定义里声明可以是子集如只读模型定义里的model或调用时覆盖2.3 内置的几种 Subagent类型定位工具Explore广撒网搜索只读只读类Plan设计实现方案排除编辑类general-purpose通用、多步、可写全部claude-code-guide回答 Claude Code / SDK / API 用法只读 联网statusline-setup配置状态栏受限核心观点Plan拿不到写工具、Explore拿不到写工具 ——能力靠工具集裁剪不靠提示词嘱咐。这是权限优于禁令在 Agent 层的又一次体现。三、Fork Agent父会话的分身3.1 它是什么Fork 是通过subagent_type: fork拉起的 Agent。它和 Subagent 最大的不同Fork 是父会话的一个分支 —— 继承父的上下文与模型。主 Agent 上下文已跑了 50 轮 ┌────────────────────────────┐ │ 需求 → 调研 → 方案 A 讨论 │ │ 读过的文件 / 踩过的坑 │ └──────┬──────────────┬──────┘ │ fork │ fork ▼ ▼ ┌─────────┐ ┌─────────┐ │ 分支 1 │ │ 分支 2 │ ← 带着完整背景分头推进 │ 方案 A │ │ 方案 B │ └─────────┘ └─────────┘3.2 一条暴露设计的硬约束Agent 工具的参数说明里有一句很值得玩味的话model: 可选覆盖该 Agent 的模型。 若省略用 agent 定义的模型否则继承父。 ⚠️ 对 subagent_type: fork 无效 —— fork 永远继承父模型。为什么 fork 偏偏不许换模型原因说明前缀相同fork 带着父的完整上下文前缀缓存命中同模型 同前缀 → prompt cache 直接命中换成别的模型前缀优势归零等于白 fork核心观点Fork 继承模型不是没做这个功能而是为了 prompt cache。上下文一旦复制模型就必须跟着复制否则缓存失效 —— 这条限制是性能设计不是功能缺失。四、核心差异对比维度SubagentFork Agent起点上下文空白只有传入的 prompt继承父会话全量历史系统提示词自己的 agent 定义与父相同模型可独立指定 / 可覆盖强制继承父不可覆盖工具集定义里声明的子集与父相同缓存友好度低前缀不同高前缀相同易命中典型用途搜索、审查、隔离噪音并行试方案、延长当前思路回传内容只有 final message只有 final message能否续聊SendMessage可续SendMessage可续4.1 一句话选型要干净的专家隔离噪音、独立视角、省 token → Subagent 要另一个我保留全部背景、分头并行推进 → Fork五、自定义一个 Subagent5.1 Agent 定义文件自定义 Subagent 就是一个带 frontmatter 的 Markdown 文件--- name: code-reviewer description: 审查代码变更找出 bug 与安全风险。提交前主动使用。 tools: Read, Grep, Glob, Bash model: sonnet --- 你是资深代码审查员。审查时 1. 先读 diff理解变更意图 2. 重点检查边界条件、错误处理、并发安全 3. 只报告你**确认**的问题附 file_path:line_number 4. 不要复述代码不要给无依据的猜测5.2 三个字段各自决定什么字段作用设计要点description主 Agent 据此判断什么时候派它写清触发时机这是路由的依据tools能力边界只读任务就别给写工具model成本 / 质量取舍简单任务用轻模型⚠️最容易写坏的字段是description它不是给人看的简介是给主 Agent 看的路由条件。写审查代码太糊写提交前审查 diff找 bug 与安全风险才可路由。六、并发与隔离的工程细节6.1 并发一条消息里发多个工具调用机制做法效果并发同一条消息里放多个Agent调用多个子 Agent 同时跑异步run_in_background: true不阻塞主线程完成再通知文件隔离isolation: worktree各给一个 git worktree互不踩踏目录固定工作目录在启动时 pin 住子 Agent 切目录不影响父会话要并行 → 一条消息多个 Agent 调用 要隔离 → isolation: worktree改动冲突时必用代价是 ~200-500ms 磁盘 要异步 → run_in_background6.2 隔离的代价与适用场景要不要 worktree只读搜索 / 审查❌ 不需要多个 Agent 同时改不同文件⚠️ 视冲突风险多个 Agent 同时跑迁移/重构✅ 必须6.3 结果回传一个容易踩的坑子 Agent 产出 final message │ ▼ 作为 tool result 返回给主 Agent │ ▼ ⚠️ 这个 result 不会展示给用户 │ ▼ 主 Agent 必须自己转述关键结论 ← 否则用户什么都看不到现象原因用户说你派了 Agent 但我没看到结果final message 只回到主 Agent不回显主 Agent 回一句已完成偷懒了应该转述结论6.4 复用优先于重建对于有状态的专家类 Agent如claude-code-guide正确做法是先检查是否已有在跑的或已完成的同类 Agent有就用SendMessage续聊而不是新建一个。做法结果SendMessage续聊上下文保留追问不丢背景新建Agent从零开始之前的调研全部白做核心观点新建 Agent 是重新雇人SendMessage 是接着问他。前者贵且会丢上下文后者才是追问的正确姿势。七、总结7.1 核心要点Subagent 干净的专家独立上下文 / 独立 prompt / 独立工具集 / 可独立模型Fork 父会话的分身继承上下文与模型model覆盖对它无效Fork 不许换模型是为了缓存前缀相同 模型相同 → prompt cache 命中能力靠工具集裁剪Plan/Explore没有写工具而非靠提示词劝阻回传只有 final message且不展示给用户主 Agent 必须转述追问用 SendMessage别新建新建 重新雇人上下文全丢7.2 最后的话核心观点多 Agent 协作的本质不是人多力量大而是上下文管理。Subagent 是在做减法 —— 把噪音挡在主上下文之外Fork 是在做加法 —— 让已有的判断力可以并行复制。选错了不是慢一点而是主 Agent 的上下文被一步步撑爆。记住面试/设计题常考Agent 之间如何隔离上下文、如何避免上下文爆炸工程红线并行改文件必须隔离worktree否则互相覆盖进阶方向子 Agent 的提示词隔离、Workflow 的 pipeline/parallel 编排、budget预算控制标签Claude Code, Subagent, Fork Agent, 多智能体, 上下文工程, AI Agent