协作工具解决什么问题？
- 场景: 当任务超出单个 Agent 的能力边界时，把子任务委托给其他 Agent 或人类，再整合各方的结果;
- 核心价值: 专业化分工——与其构建一个“全能”的 Agent，不如构建一组各自专精的 Agent，让它们通过协作来解决问题;
- 收益: 每个子 Agent 可以独立优化提示词、工具集和知识库，无需担心相互之间的冲突;
- 动因: 最简单的是并行执行不相关的多个任务（例如并行调研 OpenAI 的多个联合创始人）；更复杂的是使用不同的模型、工具、提示词和上下文执行不同任务，实现更好的效果;
- 展开位置: 多 Agent 架构详见第十章;
子 Agent 提示词有哪些关键要素？
- 角色定义: 开门见山说明“你是专门负责 XXX 的助手 Agent”;
- 上下文来源标注: 明确区分各个来源——
[FROM_MAIN_AGENT] 是主协调 Agent 给你的任务指令，[FROM_USER] 是用户直接补充的信息，[TOOL_RESULT] 是调用工具后的返回结果;
- 标注价值: 防止子 Agent 混淆信息来源，避免提示注入攻击，见 第三方能力的安全风险;
- 任务边界: 明确什么在职责范围内，什么需要转交或上报;
- 输出格式: 无论用 JSON 还是 Markdown，都要在提示词中明确子 Agent 的输出格式;
- 收益: 保证子 Agent 考虑所有需要考虑的方面，降低主 Agent 的解析负担，也使错误处理更加可靠;
协作原语有哪三组？
- 启动与取消:
spawn_subagent 创建子 Agent 并分配任务；cancel_subagent 在任务失去意义时（如用户改变主意、另一个子 Agent 已经找到答案）及时终止，避免继续浪费 token;
- 消息传递:
send_message_to_subagent 在子 Agent 运行期间发送补充指令或追问，子 Agent 也可以反向给主 Agent 发消息汇报进展或请求澄清;
- 发现:
list_agents 列出当前可用的 Agent 及其职责描述和运行状态，让 Agent 找到潜在的协作者;
- 类比: 这与 MCP 用
tools/list 列出可用工具是同一思路，只不过列出的是 Agent;
能承载哪些协作形态？
- 同步调用: 等待子 Agent 返回，适合快速完成的任务;
- 异步调用: 立即获得任务 ID，完成时通过事件通知;
- 流式协作: 子 Agent 持续发送增量消息，适合过程本身有价值的场景;
- 多轮交互: 子 Agent 主动询问、主 Agent 应答的对话式协作;
- 边界: 这里只关注这些形态共享的工具接口；调用子 Agent 时传递哪些上下文、选择哪种形态、如何组织多个 Agent 的拓扑与分工，详见第十章;
上下文传递方式如何对比？
- 最小化传递: 只把任务参数传给子 Agent，交接成本低但子 Agent 缺少背景;
- LLM 生成上下文: 额外调用一次 LLM，从主 Agent 轨迹中提炼出交接上下文，信息更完整但增加一次调用;
- 选择: 在交接完整性与 token 成本之间取舍;