Claude Code 什么时候该用子代理

排查一个认证问题时，你让 Claude Code 在主会话里搜遍调用链、跑完整套测试。半小时后，几百行搜索结果和测试日志塞满了上下文，真正要做决定时，前面讨论好的思路已经被冲淡了。另一次，你只想改一行按钮文案，它也派出一个子代理，等了好一会儿才回来。

这是两个方向相反的失误：一个该委派却没委派，一个不该委派却委派了。子代理的价值在于把一部分工作放进另一个上下文：大量中间过程留在那里，只把结论和证据带回主会话。可它也有成本：新上下文要重新收集背景，要等待，还要花额外的 token。

判断要不要委派，可以先问三个问题：

子任务能否用一段自包含的说明讲清楚？
它会不会产生大量主会话以后用不上的中间输出？
它能否独立完成，用一份短结果交付？

多数能答“是”，再考虑委派。任务规模继续变大，还有 Skill、Agent Teams 和 Dynamic Workflow 可选，按谁来控制下一步、要协调多少执行者来挑。下面先讲三个问题，再从主会话一直排到脚本编排。

01 子代理适合什么样的任务

子代理适合接收自包含的任务，把大量中间过程留在独立上下文，再带回主会话需要的证据。例如认证调用链调查和测试失败归类：

主会话
  ├─ 委派：梳理认证调用链
  │    └─ 子代理 A：搜索大量文件，只返回调用链摘要
  ├─ 委派：运行测试并归纳失败
  │    └─ 子代理 B：保留完整日志，只返回失败原因
  └─ 汇总结论，决定下一步修改

隔离中间过程能减少主会话的干扰，但不保证结论正确。任务定义和最终复核仍然决定结果是否可用。

开头三个问题如果大多能答“是”，就可以考虑委派。经常得来回沟通、靠当前讨论补背景，或只改一行代码，直接留在主会话就好。把任务派出去也有说明和等待成本。

Claude Code 最佳实践对子代理的成本讲得很实在：它的主要开销是 token，每个子代理都单独发请求，和主会话计入同一份用量；有时还会更慢，因为新的子代理得先收集主会话里已有的背景。官方列出的值得用的场景有四类：

同时推进相互独立的工作，让整体更快完成；
把完整测试输出、大范围搜索这类长输出挡在主会话之外；
找一个没看过代码编写过程的审查者；
给某个任务比主会话更少的工具，例如只能读、不能改的审查者。

02 先用内置子代理

Claude Code 提供几类内置子代理，分别覆盖常见场景：

代理	工具与模型	适合任务
Explore	只读工具；默认用主会话的模型	找文件、搜索引用、理解代码结构
Plan	只读工具；继承主会话模型	在 Plan 模式中研究代码并为计划收集背景
general-purpose	全部工具；继承主会话模型	需要探索、推理和修改的多步骤任务

看见 Explore 是只读搜索角色，还要再查它用了什么模型。当前默认跟随主会话，并非固定 Haiku。如果希望搜索一直用轻量模型，可以覆盖 Explore，或单独定义一个研究代理。子代理文档给的做法是：在用户或项目里定义一个名叫 Explore 的子代理，它会覆盖内置版本，再写上 model: haiku。角色名称不能代替模型配置。

还有一点影响交接：Explore、Plan 为了保持轻量，启动时不加载项目 CLAUDE.md 和 Git 状态。需要遵守的限制要在委派时再说一遍，委派消息怎么写见怎样给子代理交代任务、核对结论。

03 从主会话到脚本编排

同一个目标，可以用复杂程度不同的方式完成：

机制	谁控制下一步	适合规模
主会话直接处理	Claude 按当前对话推进	小而明确、改动集中、反馈频繁
Plan 模式后实现	你先审查计划，再允许修改	跨文件、有设计选择或不熟悉代码
Skill	Claude 按可复用说明推进	团队反复执行的固定流程
少量子代理	主会话逐次委派并汇总	几个独立调查或高输出任务
Agent Teams	主代理协调长期运行的同伴会话	少量持续协作、需要相互通信的角色
Dynamic Workflow	JavaScript 脚本控制循环、分支和聚合	大范围审计、批量迁移、交叉研究

先看当前任务的规模和反馈方式。改动集中、需要频繁沟通时，主会话通常就够用；增加代理和编排还会带来交接成本。Skill 用于复用方法，子代理用于独立执行；需要多个长期运行、相互通信的会话时，再考虑 Agent Teams。是否升级机制，要看协作需求。

放进同一项任务时，由主会话负责推进决定，其他机制各自承担需要的工作：

主会话：理解当前目标，决定如何推进
Skill：提供可复用的方法、检查表和脚本
子代理：在独立上下文中完成聚焦工作
Hook：在固定生命周期节点执行确定动作
Dynamic Workflow：用代码控制大规模循环、分支和聚合

04 什么时候用 Dynamic Workflow

只有当目标很多、阶段反复执行，或需要隔开大量中间噪音时，才值得考虑脚本编排。规模、重复次数、上下文和依赖要一起权衡。

Dynamic Workflows 文档的定义是：一个由 Claude 编写、编排许多子代理的 JavaScript 脚本，由运行时在后台执行，会话保持可用。官方用“谁掌握计划”来区分几种机制：子代理、Skill 和 Agent Teams 都是 Claude 一轮一轮决定下一步，中间结果都进上下文；workflow 把循环、分支和中间结果都放进脚本变量，Claude 的上下文里只留最终答案。规模上，子代理是每轮几个委派任务，workflow 是每次运行几十到几百个代理。

适合的场景包括批量路由认证审计、组件迁移及逐项验证、有上限的多轮修复，或多来源交叉研究。几点使用上的注意：

用 /workflows 查看阶段、代理、token 和耗时，也可以在那里暂停和恢复；
稳定后可以保存到项目的 .claude/workflows/，以后从斜杠入口调用；
代理的工具调用仍走当前会话的权限，启动前查计划、脚本和写入范围；
先挑少量文件试跑，查结果质量、返回格式和停止行为，再逐步扩大。

需要分阶段审批，就把 Dynamic Workflow 拆开，它不适合随意插入业务审批节点。

05 嵌套委派的代价

旧资料可能说子代理不能再委派。按子代理文档，当前默认可以嵌套到主会话下三层；到达上限时，Claude Code 会收回子代理的 Agent 工具。子代理拿到 Agent 工具后才能继续派任务。要禁止它再派，就在 tools 中不提供 Agent，或用 disallowedTools 移除。

每增加一层，都可能增加信息传递、调度和模型成本。一个专注于当前问题的代理能完成时，保持单层；边界不清时先补充输入。几个子代理同时跑时怎样分工，见多个子代理同时改代码时的分工方法。

回到开头的两次失误：认证调查那次，调用链搜索和测试日志各派一个子代理，只带回摘要，主会话就能留给决策；改一行文案那次，直接在主会话里改完更快。先看规模、反馈频率和中间输出，机制只在有实际用途时加入。