子 Agent 能并行，却不能互相说话：Claude Code 里哪些活不该委派
Claude Code 的官方子 Agent 指南里，有两条建议并排放着。一条说流水线式任务适合子 Agent：先设计、再实现、然后测试，每个阶段交给一个独立实例。另一条说顺序且互相依赖的工作不要用子 Agent，因为第二步需要第一步的完整输出时，单个会话更干净。
同样是一步接一步，结论却相反。
分辨这两种情况的是交接点：上游的成果能不能压成一份写得下来的规格。能压缩，流水线成立；不能压缩，拆开就是自找麻烦。
而这条区分背后，是子 Agent 仅有的那一个机制------独立的上下文窗口。它带来的每一项收益，和它造成的每一次失败，都出自同一处隔离。搞清楚这一点，"要不要委派"就从经验判断变成了一个可以当场回答的问题。
子 Agent 买到的是隔离，不是额外算力
子 Agent 是一个拥有自身上下文窗口的独立 Claude 实例。它接下任务、独立读文件和改代码，完成后只把相关结果返回主对话。
关键在最后半句。派出去的是一段任务描述，回来的是一段结论，中间读过的几十个文件、试错和半成品，全都留在那个窗口里，随任务结束一起丢弃。
主会话省下的是上下文，不是时间。单个子 Agent 串行跑，总耗时并不会变短，省的是主会话不必背着那几十个文件继续往下走。真正省时间的是并行------多个子 Agent 同时运行，三个任务大致在一个任务的时间里完成。
隔离还顺带给出一个副产品：每个子 Agent 可以有不同权限。研究型的给只读，实现型的给完整编辑能力。这样即使某个子 Agent 判断失误，它能造成的影响事先就被限定住了。
Claude Code 内置了三类子 Agent：通用型处理复杂多步骤任务，规划型在给出实现策略前先研究代码库，探索型为快速只读搜索做过优化。多数时候 Claude 会自行派生它们，不需要你开口。
同样是一步接一步，交接物能否压缩决定成败
回到开头那对矛盾。
流水线之所以成立，是因为阶段之间的交接物本身就是紧凑的。设计阶段产出一份规格，实现阶段拿着规格就够了，它不需要知道设计过程中否决过哪三个方案。测试阶段拿着代码和规格，同样够用。每一次交接都是一次有损压缩，但损掉的部分下游本来也用不上。
顺序依赖的工作正相反。第二步需要第一步的全部输出，第三步两者都需要。这时候要么把上游上下文原样塞进下游的提示词------那隔离就白做了，要么靠文件在子 Agent 之间传状态------那比单会话脏得多。
所以判断的第一个提问是：把上游的成果压成一段能写下来的交接物，下游还够用吗？
够用，拆；不够用，留在主会话里一路做完。
该委派和不该委派，是同一条判断的两面
官方指南把适用场景和反模式列成了两张清单。把它们放到一起看，会发现每一条都在回答同一个问题------隔离在这里是帮忙还是添乱。
| 场景 | 隔离在这里的作用 | 判断 |
|---|---|---|
| 要读几十个文件才能动手 | 原始内容不进主会话，回来的是结论 | 委派 |
| 多个互不依赖的子任务 | 各自独占窗口，可以真正并行 | 委派 |
| 需要一次无偏审查 | 不继承主对话的假设、取舍和盲点 | 委派 |
| 下游需要上游的完整输出 | 交接必然失真，只能靠文件传状态 | 留在主会话 |
| 多个任务要改同一个文件 | 彼此看不见对方的改动，冲突的温床 | 留在主会话 |
| 一次快速修复或一个聚焦问题 | 启动开销盖过收益 | 留在主会话 |
无偏审查那一条值得单独说一句。想要一块干净白板，/clear 也能做到，代价是彻底丢掉那段历史；子 Agent 拿到同样的白板，主对话还完整留着。
提交前想确认实现有没有过拟合到测试上、有没有漏掉边界情况，交给一个没被实现过程影响过的子 Agent 去看，比自己回头再读一遍更容易发现问题------熟悉感会掩盖东西。这与自动代码审查工具的定位是同一类考虑：它交付的是一次独立意见，不是最终裁决。
至于规模，官方给了两个可以直接用的阈值：需要探索十个或更多文件，或者涉及三项以上互相独立的工作。达到任意一条，就该主动把 Claude 引向子 Agent。
自定义 Agent 定义得越多，自动委派反而越不准
这一条最违反直觉。既然可以把常用的专家固化下来，多定义几个似乎只有好处。
机制在于 Claude 决定委派的依据：自定义子 Agent 的 description 字段。Claude 拿当前任务去匹配这些描述，描述之间一旦重叠，路由就出现歧义，选谁都说得通，结果是谁都不稳定。名册越长，重叠越难避免。
所以官方的建议是把描述写成触发条件，而不是能力标签。"在提交前审查代码的安全问题"给出了明确的触发时机，"安全专家"只说明了它会什么。前者路由得准得多。
大多数团队最后会稳定在少数几个范围清晰的 Agent 上。这些文件放在 .claude/agents/（项目级，随仓库共享）或 ~/.claude/agents/（用户级，跨项目可用），用 /agents 命令交互式创建最省事。
子 Agent 不能互相说话，超出这条边界要换工具
隔离推到极限，就是标题里那句话：子 Agent 只向主对话汇报，彼此之间无法交谈。
这不是没做完的功能，而是独立上下文窗口的直接推论------既然各自的窗口互不可见，就没有通信信道可言。所有协调都必须绕回主会话，由它转述。
因此凡是需要子 Agent 之间往返讨论的任务，用子 Agent 就是走错了路。官方给出的替代品是 Agent 团队：它让多个 Agent 跨独立会话协调，代价是比子 Agent 更重也更贵。需要通信才上 Agent 团队，只需要汇报就留在子 Agent。
五种调用方式是一道阶梯，不是五个并列选项
对话式调用、自定义子 Agent、CLAUDE.md 指令、技能、钩子------这五种方式常被并排介绍，但它们之间有明确的先后。
排序的依据是同一个问题：这个模式重复了几次，值不值得固化。
起点始终是对话。直接说"用一个子 Agent 探索这个代码库里认证是怎么工作的"，在终端、VS Code、JetBrains、网页版和桌面应用里都有效。说清楚三件事就够用：范围、要不要并行、想要什么形式的输出。任务跑得久时，Ctrl+B 把它丢到后台，/tasks 看还有什么在跑。
往后每一级都是在牺牲灵活性换取自动化。CLAUDE.md 每次对话都会加载，适合放"什么时候该动用哪个专家"这类始终生效的规则；技能按需加载，靠 description 匹配，适合那些应该随时可用但不该影响每一条提示词的流程；钩子在生命周期节点上无人触发，最自动，也最容易在工作流还没定型时锁死错误的做法。
跳级的代价是固化了一个还没验证过的模式。等模式自己浮现出来再往上爬，比一开始就写钩子稳。
回到那对矛盾
流水线和顺序依赖的区别，现在可以一句话讲完：交接物能压缩就拆，不能压缩就不拆。
值得带走的判断模型只有一条------子 Agent 的收益和代价来自同一处隔离。下次犹豫要不要委派时，第一步不是数任务有几个，而是问隔离在这里帮忙还是添乱：主会话是否需要看到这些中间过程？几个任务会不会碰同一个文件？它们之间要不要互相说话？
这条判断在两种情况下会失效。一是任务规模太小，此时隔离既不帮忙也不添乱，纯粹是开销，直接在主对话里做完更快。二是协调需求已经超出"汇报"，需要 Agent 之间真正往返讨论，那时候要换的是 Agent 团队，不是再多派几个子 Agent。
至于会不会用子 Agent，Claude 自己就会派。值得你花心思的是另一半：知道什么时候该拦住它，别把一条需要信息流动的工作切成互相看不见的几段。