第十三章：多个 Agent 怎样交接工作
最初只有 A、B、C 三份材料，一个助手足够。现在扩大教学情境：候选消息分成几个独立主题，每个主题都要核对原公告、去重并说明限制。让多个 Agent 同时处理，会不会更快、更可靠？
可能，但多一个 Agent 也意味着多一份上下文、多次模型调用和一次交接。若父任务没有说明“图片暂不支持”，子任务再认真也可能沿着错误范围推进。
本章的产物是一对任务包与返回包。目标是能判断哪里值得分工，怎样避免把“人多”误当成“完成得好”。
13.1 并行的前提是独立，不是拆成多个标题
把“寻找原公告”和“核对刚找到的公告”同时发出去，后一项没有前一项的结果，无法真正独立工作。它只能重新搜索，或者猜父任务准备采用哪份材料。
相反，不同主题各自已有候选材料，就可以独立核对，再由父任务处理跨主题重复和最终排序。先区分数据依赖，再考虑是否同时执行。
| 拆分方式 | 能否独立推进 | 父任务仍需做什么 |
|---|---|---|
| 笔记主题与语音主题各自核对 | 材料和要求齐全时可以 | 检查交叉重复、统一交付范围 |
| 先取原文，随后根据原文判断限制 | 后项依赖前项 | 前项完成后传递材料再启动 |
| 多个助手各写同一份最终简报 | 可能得到多份答案 | 比较与核对，收益未必覆盖重复成本 |
| 一个写草稿，一个同时改同一文件 | 即使能启动也有写入冲突 | 约定产物边界与合并方式 |
多 Agent 增加的是可分开的判断过程，没有取消依赖和资源争用。对于三份很短的材料，交接成本可能比节省的时间更多。
13.2 Hermes 的子任务拿到什么
Hermes 的委托能力可以创建子 Agent，运行自己的模型与工具循环。子任务从新的对话上下文开始，不自动知道父任务此前所有聊天、工具结果和隐含约定。
父任务通过目标和上下文提供所需信息。项目相关的说明可能按工作位置注入，但这也不等于获得父任务整段历史。继承工具访问和运行配置，与继承已经读过的事实，是两件事。
在固定材料案例中，一份够用的任务包可以是：
核对笔记工具甲这一件事。材料 A 是原公告，B 是同一事件的转述。只依据这两份材料判断，不额外搜索，不发送消息。返回确认事实、冲突与采用理由、仍未知的内容，以及材料标识。不要把 A 与 B 算成两件事。
这里的目标可独立完成，禁止事项有具体含义，返回也能被父任务检查。“看看笔记工具，给我结论”则会迫使子任务补猜范围。
13.3 独立上下文省了什么，又丢了什么
子任务的长篇取材过程不必全部进入父任务输入，这能降低父任务阅读噪声，也使多个方向相对独立。不过，父任务主要接回汇总后，细节和失败尝试可能被省略。
所以返回包不应只有“已完成，没问题”。它至少需要结果、依据定位、未解决项和实际产物。发现冲突时，父任务必须能回到材料，不能只能在两个漂亮摘要之间投票。
| 返回字段 | 本例应写什么 | 父任务怎样使用 |
|---|---|---|
| 确认事实 | A 只支持纯文本导出 | 写入最终草稿并保留条件 |
| 冲突与重复 | B 为同一事件，图片说法无支撑 | 去重，避免夸大 |
| 证据定位 | A 与 B 的具体相关段落或标识 | 必要时回读，而非盲信子任务 |
| 未知与失败 | 未取得更多公告，未验证图片能力 | 保留缺口，决定是否追加工作 |
| 产物与修改 | 生成哪份核对记录，是否改了文件 | 合并与追踪，不凭“成功”猜写入范围 |
Hermes 支持为返回约定结构，并检查是否符合所需形式。但格式检查只能说明字段和类型等条件满足，不能证明“图片支持”这个判断正确。结构合格与事实合格仍是两道验收。
13.4 后台返回以后，谁继续推进
Hermes 的顶层委托可以在后台运行并返回句柄，让父任务继续处理不依赖子任务的工作。完成后，结果再送回相应入口。特定配置可以按组或分别送回完成结果。
“分成一组”控制何时汇总交付，不会自动建立先后依赖。若乙必须读甲的产物，仍要等甲完成，再带着产物启动乙；把它们写进同一个分组不能解决这个问题。
还要沿第十二章的分段思路理解通知：子任务完成、结果被入口队列接收、父任务产生新一轮、最终回复送达，是不同事件。网关接受了完成消息，不等于父模型已经看过，也不等于最终用户已经收到。
这种分离允许后台工作与交互并存，也增加了队列、归属、取消和恢复的复杂性。如果你的任务很短，同步等待通常更容易推理；是否后台化应由任务需要决定。
13.5 新终端不等于新文件世界
Hermes 的子任务有各自的终端会话和进程归属，默认情况下却可能仍访问同一个工作目录。它们同时覆盖同一草稿，就会产生冲突；父任务不能用“上下文独立”来证明文件也已隔离。
版本管理工具 Git 可以组织独立工作副本，称为工作树。在适用的 Git、本地终端场景中，可以选择这种隔离，让子任务各自修改，再由父任务检查与合并。这个能力有范围和条件；实际没有成功创建隔离环境时，不能继续按“已隔离”作判断。
对于简报这种主要取材的工作，更简单的办法是子任务分别返回记录，由父任务统一写最终稿。这样少一层合并，也能清楚保留谁负责哪一部分。
后台进程还归启动它的 Agent 管理。子任务结束时，它拥有的进程可能随清理终止；返回一个进程编号并没有转移所有权。需要持续运行的服务应由有相应生命周期的父任务或独立服务承担。
13.6 把权限、预算和停止也交接出去
子任务通常继承一定配置与可用工具，同时有委托角色和能力限制；不是一个可以任意提高权限的全能副本。进一步嵌套也有专门配置，不该因“还能拆”就无限生成层次。
父任务要说明范围与预算，并在验收时汇总总开销。并行可能缩短墙上经过的时间，却增加模型用量；主模型、子模型与辅助调用的总成本要一起看。
停止也需要跟着所有权传播。Hermes 对所属会话的停止、关闭或重置有相应的子任务取消处理；中断结果可以包含部分产物。父任务应说明哪些已完成、哪些被打断，而不是把“所有孩子不再运行”当成“所有工作已完成”。
13.7 本章怎样决定是否采用委托
先按单 Agent 路径估算：未知有几个，哪些依赖哪些，材料会有多长。只有独立方向足够复杂，或者需要隔离大量取材过程时，再考虑委托。任务包和验收包写不清，往往说明拆分还没完成。
对于本书最初的三份材料，默认继续使用一个 Agent。把委托作为扩大资料范围时的可选设计，反而更能说明你理解了它的价值和代价。
本章要点
- 可并行的核心是依赖可分开；分组和多标题不会消除依赖。
- 新对话不继承完整历史，任务包必须包含目标、材料、边界和返回要求。
- 父任务负责事实验收、冲突处理与最终交付，格式验证不能代替这些工作。
- 独立上下文、终端、工作目录和进程所有权要分别判断，协作增加协调与成本。
理解题
1. 子任务说“找不到你刚才提到的图片限制”，说明它忘记了吗？
首先检查父任务是否将这一限制或材料 A 放入任务包。子任务从新上下文开始，不默认知道父历史。信息没有交接，不能称作遗忘。
2. 两个子任务返回结构合格的结论，一个说支持图片，一个说不支持，怎样处理？
回查各自依据和适用范围，确认是否使用同一版本、同一材料。不能用格式通过或多数票替代事实核对。本案例 A 明确限制图片，B 的转述无支撑，父任务应保留限制。
3. 子任务启动了长期监控后返回进程编号，父任务能否直接认为监控已经移交？
不能。进程编号只是标识，所有权仍可能属于子任务，结束清理会影响它。应由具备持续生命周期的运行方启动和管理，并验证实际状态。
运行与协作的主流程已经串起。下一章讨论谁决定任务可以做什么，接着分析失败后怎样继续。