为什么要委派
你刚刚花了一整模块讲情境管理。修剪、封盖、缓存。Agent比以前更乖了。问题还没有完全解决。
在五十步任务中，Agent失败的部分是修剪无法捕捉的。不是因为背景太长，而是因为Opus本身对Agent来说形状不对。探索、规划、执行和验证彼此交织。探索的Agent变成了正在做出改变的Agent，探索时的所有背景依然保留着。
委托则把这些拆解开来。父 Agent决定该怎么做。子 Agent去做。每一个都是孤立运行的。父 Agent得到答案，而不是旅程。
学习成果
你可以描述委派修复的三种单Agent失败模式，也能判断什么任务适合委派，什么时候更适合父 Agent。
失效模式
这些失败是修剪无法发现的。
环境污染
Agent读取二十个文件以理解代码库。现在有二十个文件内容在上下文中。当Agent开始做更改时，与变更相关的文件会被埋在十五个五步前有用、现在毫无用处的文件里。
修剪最终会把它们去除，但前提是它们会把实际的任务从最上面的注意力中移开。
失去了专注
到了第三十步，Agent已经漂移了。系统提示词说“重构认证模块”。在某个阶段，Agent发现了一个CSS错别字，修正了它，然后发现了一个次优导入，重构了它，最后写了一条评论解释一个它感兴趣的函数。最初的任务被遗忘了。
这就是当一个人有太多顾虑和绳索过多时Agent会发生的事。
过宽能力
Agent有write和bash。在探索过程中，它“贴心”地修正了它在阅读文件中发现的一个拼写错误。修复会破坏别的东西。探索不应该被允许修改任何东西，但一个拥有完整工具的单Agent不会为自己划清界限。
模式
委派将Agent划分为不同工具和模型的角色。
Parent
Plans the work
Delegates research to an Explorer
Delegates implementation to an Executor
Synthesizes results
Makes architectural decisions
Explorer subagent
Read and grep only (cannot modify anything)
Cheap, fast model (Haiku)
Reports findings, does not act
Executor subagent
Full tools, including write and bash
Stronger model (Sonnet or Opus)
Follows precise instructions from the parent
Cannot ask user questions (no askUser)父 Agent是唯一提出问题、做决策或制定长期计划的Agent。其他所有事情都被委托和规划。
何时委托
| 代表 | 保持在父 Agent |
|---|---|
| 跨多个档案进行研究 | 单列变更 |
| 并行独立任务 | 顺序依赖变更 |
| 机械散装作业 | 建筑决策 |
| 行动前的探索 | 模糊需求（使用askUser） |
分歧在于Opus是否干净利落地交接。阅读三十个文件并返回一段摘要，是干净利落的交接。决定三种架构方法中的哪一种则不重要，因为决策本身就是工作本身。
**注意：委派并非免费**
子 Agent 调用是一种全新的模型，拥有自己的启动时间token、自己的系统提示词和延迟。不要把所有事情都委派去做。把父 Agent从看不到全部痕迹中受益的工作委派给他们。如果父 Agent能三步完成任务，委托就没有自偿。
动手试试
这是一个概念课。没有代码可运行。自我检视：
- 不回头，说出三种单Agent故障模式
- 从上周选一个你自己的编码任务。哪些部分会是探索器好的？哪一个执行器效果更好？哪些必须留在计划本那里？
- 如果你把整个任务交给一个拥有所有工具、五十个步骤、没有委派的Agent，会发生什么？
提交
这节课没有代码。下一课构建了探索器。
完成标准
- [ ] 你可以说出三种单Agent故障模式
- [ ] 你可以描述什么时候委派有效，什么时候无效
- [ ] 你可以勾勒出实际任务的哪些部分会分为父 Agent、探索器和执行器