一、问题引入：为什么要把工作交给子智能体
这个视频不是在讲“让 AI 更像人”的概念，而是在讲一个非常工程化的问题：当 Claude Code 的主会话已经承担需求澄清、代码阅读、命令执行和用户沟通时，哪些工作应该被拆出去，让另一个干净上下文里的 Agent 独立完成？开场演示里，作者让主会话一次派出五个不同视角的评审者：初学者、软件工程师、业务负责人、出版人和企业高管。它们并行阅读同一份内容，然后把各自报告交回主会话汇总。
这件事的价值在于，主会话不需要吞下所有材料，也不需要在同一个上下文里不断切换角色。主会话像调度器，决定“谁去看什么、要带回什么结果”；子智能体像一次性专家工作线程，读取指定文件、做研究、找漏洞或给出审稿意见。最终用户仍然只跟主会话沟通，这让界面保持简单，也让上下文污染更少。
子智能体的核心不是“更多聊天窗口”，而是让主会话把可独立完成的认知工作委派出去，再收回结构化报告。
二、核心概念解释：subagent、skill 与主会话的边界
主会话是 orchestrator，不是所有事实的仓库
作者反复强调，Claude Code 的主会话负责跟用户对话、理解当前目标、拆分任务和汇总结果。它可以命令子智能体“去读这些文件”“去做这项研究”“去修这个 bug”，但子智能体完成后通常只返回报告，而不是继续跟用户来回确认。这个设计让主会话拥有更稳定的任务视角，同时避免每一次深入阅读都把上下文窗口撑满。
子智能体不是技能文件，但可以调用技能
视频中区分了 Claude Code 里的两个概念：skill 更像可复用流程说明、脚本和资源包；subagent 则是带有角色、触发描述、工具权限和执行说明的独立代理。二者可以组合：一个 skill 里可以要求系统派出多个子智能体，一个子智能体执行时也可以再调用合适的 skill。工程上要避免把所有材料都塞进一个文件，而是利用 front matter 做渐进式加载。
YAML front matter 是触发器，也是安全边界
自定义子智能体通常以 Markdown 文件存在，顶部是 YAML front matter。作者点名最关键的字段包括 name、description、model、tools、disallowed tools、memory 与 color。尤其是 description，它不是普通说明文，而是 Claude Code 判断“这个 prompt 是否应该触发该子智能体”的触发条件。描述太泛会误触发，描述太窄会漏触发，因此需要像调试路由规则一样反复迭代。
三、关键论点与实操步骤
先定义它该接什么任务
不要先写一长段角色扮演文本。更稳的做法是先写一句非常具体的 description：它在什么请求下应该被调用、什么请求下不该被调用、输出应该是什么格式。比如“当用户要求 adversarial critique、roast my plan 或 review my plan 时使用”。
再决定它能碰哪些工具
如果子智能体只是审查计划或阅读资料，就应考虑只读工具；如果它要修 bug，才给编辑和命令执行权限。作者提到可以在 front matter 中限制工具、禁用工具或指定 MCP server，这一点是把子智能体用于真实项目时的安全阀。
用 body 写工作方法
front matter 负责“何时调用”，正文负责“怎么工作”。这里可以写审查维度、输出结构、要先读哪些文件、必须引用哪些证据、发现不确定性时如何处理。它不需要包含所有背景材料，只需要给子智能体一套稳定行为。
用真实失败调触发描述
演示中作者创建了一个 plan roaster，但第一次没有按预期触发。他没有把这视为玄学，而是让 Claude Code 读 agent 文件的 description，再对照原 prompt 分析为什么没有命中。这是最值得保留的实践：把误触发和漏触发当成路由规则调试。
一次子智能体文件可以长这样
视频没有要求观众记住完整语法，但给出的方向足够明确。一个可用的子智能体至少要回答三类问题：它叫什么、什么时候应该启动、启动后按什么流程交付结果。
---
name: plan-roaster
description: Use this agent when the user asks for adversarial critique of a plan.
tools: Read, Grep
model: sonnet
---
You are a skeptical plan reviewer.
Evaluate feasibility, missing assumptions, operational risks, and next checks.
Return concise findings first, then questions, then recommended revisions.这里最关键的是不要把 description 写成“help with plans”这种弱触发。它应该包含用户可能真的会说的话，以及不应该启动的边界。对于团队项目，还可以把这个文件放在项目级 .claude/agents/ 目录；对于个人长期使用的代理，则可以放在用户级目录，让不同项目共享。
四、决策矩阵：什么时候用 subagent，什么时候不要用
| 任务类型 | 是否适合子智能体 | 优点 | 主要风险 | 建议做法 |
|---|---|---|---|---|
| 大量文件阅读、源码扫描、资料检索 | 适合 | 把噪声留在子上下文，主会话只接收结论和证据。 | 如果没有要求引用证据，报告可能过度概括。 | 要求返回文件路径、关键行号、确认过和未确认的信息。 |
| 多个独立章节、多个 persona 评审、多个候选方案比较 | 非常适合 | 可以并行，且每个代理从干净视角出发。 | 各代理不能互相协调，结论可能重复或冲突。 | 让主会话统一汇总，并显式要求去重与冲突处理。 |
| 需要反对意见、风险审查、计划质疑 | 适合 | 子智能体可以摆脱主会话的顺从倾向，给出更尖锐的检查。 | 过度批判会牺牲可执行性。 | 把输出限定为“问题、证据、改法”，避免只做情绪化否定。 |
| 严格串行的编码步骤：1 完成后才能做 2 | 通常不适合 | 主会话直接推进更容易维护状态。 | 并行拆分会引入状态冲突和重复修改。 | 保留在主会话，必要时只派子智能体做局部阅读或审查。 |
| 需要持续向用户追问的探索任务 | 不适合 | 子智能体不是交互窗口，追问链路会断。 | 它可能猜测用户意图并给出错误方向。 | 由主会话澄清需求，再把清晰子任务委派出去。 |
五、可转述的关键观点
如果一项工作需要读大量材料、输出很长报告、可以独立并行，或者你只想要一个干净视角，就应该考虑交给子智能体。
如果步骤强依赖、代理之间必须互相对话，或者需要用户持续回答问题，那就不要把它拆成普通 subagent。
这两个判断比“会不会用 subagent”更重要。很多人会把子智能体当成炫技功能，结果每个小任务都拆出去，反而增加编排成本。视频真正有用的地方在于，它把 subagent 放回了工程判断：它是一种上下文隔离、并行阅读和专门审查工具，不是默认的万能执行单位。
六、时间戳目录
七、相关推荐
如果你想把这节课落到真实工作流里，建议按“入门配置 → 专业工作流 → 并行代理”的顺序继续看，而不是直接堆很多 agent 文件。