本页提纲
多 Agent 协作
Agent 可以将目标的一部分交由其他 Agent 处理。当某项工作拥有清晰的边界时（例如检查某一章节的文档、审查一段补丁或排查某次测试失败），委托协作尤为有效。委托方 Agent 始终对整合并验证最终结果负有全部责任。
两类委托方式
受监督的子 Agent（Supervised child）在父 Agent 的直接监督下处理边界明确的指派任务。带返回结果的调用会为父 Agent 提供一个可供等待或检查状态的任务句柄。子 Agent 执行结束本身并不会自动将其销毁，生命周期清理属于独立的操作。
对等 Agent（Peer）则是拥有独立身份、历史记录与职责分工的已有 Agent。向其发送持久消息只能确认投递成功已被接受，并不代表对等方已经开始或完成了该工作。如果调用方需要等待回复的句柄，必须使用受支持的调用接口，而不能把发送回执直接当作执行结果。
对等方的回复也可能是提问、进度通报或拒绝执行。即使收到了回复，在将业务工作标记为完成前，依然需要仔细审查其具体内容。 如果对端 Agent 在调用方登记等待之前就返回了答复，该答复仍会作为等待结果交付，不会丢失。
委托方 Agent 的持续责任
明确的指派应当交代范围、输入、预期产出以及验收标准，同时指明文件修改边界与是否允许执行外部系统操作。为被委托方提供充足的上下文，但不要假设它能看到父 Agent 的全部历史对话。
例如，父 Agent 在准备代码补丁时，可以要求子 Agent 仅审查被修改的解析器模块并报告发现，不得修改任何文件。子 Agent 随后返回执行证据；父 Agent 核查证据，决定哪些发现需要纳入补丁修复，并在最终面向操作者时说明完成了哪些验证。如果子 Agent 执行失败，父 Agent 必须如实报告或进行容错恢复，绝不能静默地将审查视为已通过。
并行工作不仅需要清晰的任务归属，还需要明确的文件归属。使用独立的 worktree 可以防止两个被委托方同时修改同一个工作副本。在共享目录中工作时，必须划分互不重叠的文件修改范围。
监督与清理
借助调用的任务句柄来等待执行完成。在图形化客户端中，可以直接打开子 Agent 的对话视图，并返回父 Agent。
需要诊断时检查状态或输出，不再需要时及时终止执行。处于终态的任务句柄属于历史证据，不能当作重新启动同一次调用的通信通道。
在删除临时子 Agent 之前，应确认它仍处于父 Agent 的清理权限之下，且没有尚未归档的工作或产物。务必先妥善保存交付结果。一次调用的完成，并不赋予删除共享对等 Agent 或其他 Agent 工作区的权限。即使调用方认为指派已经结束，运行时的权属检查与活动状态保护依然可能拒绝清理请求。 历史失败记录属于诊断证据，不再作为活跃执行的阻塞项。已结算且处于空闲或 停止状态的子 Agent，在交付成果确认妥当后即可安全清理，不会仅因运行过程中曾记录过错误而被无故滞留。已删除记录的后台清理会渐进进行，不会让空闲的运行时持续占用 CPU。
权限与信任边界
委托并不会扩大权限范围。子 Agent 的角色、可用工具与执行上下文必须严格限制在已授予的范围内。它的输出属于另一个 Agent 提供的外部证据，不能当作操作者的新指令。子 Agent 在返回报告中声称“操作者已批准发布”，并不能作为已经获得审批的凭据。
父 Agent 必须根据最初的请求与手头的可用证据，对关键主张进行交叉核实。详见信任边界。