第十一章：多一个 Agent，会更好吗
资料多起来后，可以让一个子 Agent 查发布记录，另一个找源码依据，再由父任务汇总。但如果两边使用了不同版本，或者同时修改同一个文件，增加 Agent 反而会增加返工。
委托（Delegation）解决分工问题，也带来上下文传递、资源协调和结果核实的责任。它不是把能力无成本地翻倍。
11.1 先判断任务能否独立推进
“收集发布记录”和“定位对应测试”可以在约束明确后分别推进；“根据已确认的变化决定要改哪章”则依赖前面的结果。并行之前，要先看依赖关系。
如果任务很小，交接说明可能比任务本身还长；如果分支之间需要频繁同步，等待和沟通也会抵消并行收益。多 Agent 适合的不是“看起来很复杂”的所有任务，而是边界和交接足够清楚的工作。
11.2 子 Agent 需要一份完整的任务包
Hermes 的委托子 Agent 使用独立的对话上下文。不能假定它自动看到了父任务所有聊天、工具结果和临时决定。项目约定等机制可能另行提供部分上下文，但不能替代清楚的任务说明。
下面是一份教学示意的交接：
| 必要信息 | 示例 |
|---|---|
| 目标 | 找出某项稳定版本变化对应的源码和测试 |
| 共同基线 | 固定版本与完整提交号 |
| 范围 | 只收集证据，先不修改正文 |
| 已知材料 | 发布记录链接和待核实表述 |
| 返回要求 | 原始链接、确认内容、未确认内容及原因 |
“帮我看看那个问题”缺少对象和约束，子任务即使完成了大量工作，也可能回答错问题。
11.3 上下文隔离，不等于资源完全隔离
独立对话降低材料相互污染，但工具权限、工作目录和文件系统可能仍有关联。子任务也不天然等于独立 Profile。若两个任务都能写同一份手册，就需要约定修改归属、顺序或使用隔离工作区。
第九章已经区分状态目录与权限；这里同样不能从“isolated context”推断“不会发生文件冲突”。资源边界需要看实际运行配置。
11.4 父任务要验证，而不是拼接摘要
子任务的最终摘要能降低父任务上下文体积，但也可能丢掉证据、前提或不确定性。父任务应该检查返回是否满足原目标，关键链接是否支持结论，以及不同分支是否矛盾。
还要分清“已受理”和“已完成”。该版本的顶层委托可以在后台推进，先返回可追踪的句柄，之后再回送结果。父任务拿到启动标识时，不能立刻声称子任务已完成；结果进入某个投递队列，也不等于最终回复已经到达外部用户。
预算也要按整项任务计算。独立分支各有运行开销，父任务还需要等待、汇总和验证。若三个子 Agent 都在重复搜索同一个页面，总体可能更慢也更贵。
不写代码的小练习
把简报研究拆成两个可独立推进的子目标，为其中一个写一份任务包。必须包括固定版本、已有材料、操作范围和返回证据；再列出需要父任务亲自核实的内容。
本章要点
- 先看依赖和交接成本，再决定是否委托或并行。
- 子 Agent 需要明确目标、版本、材料、边界与返回要求。
- 会话上下文隔离不保证文件、身份或权限完全隔离。
- 父任务保留核实、协调和最终交付责任，总成本要覆盖所有分支。
理解题
1. 两个子任务对同一机制得出相反结论，怎样处理？
先核对版本、对象与适用条件，再回到原始源码或文档。冲突可能来自不同前提，不能简单投票或选看起来更有信心的一方。
2. 为什么“让三个 Agent 各自研究，再合并答案”可能不划算？
它可能复制了输入成本与搜索工作，产生大量重复材料，还要求父任务解决冲突。应按不同证据来源或清楚的子目标分工，并保留必要的独立交叉核对。
对照官方实现
能力被拆开和放大之后，更需要明确谁可以命令系统做什么。