4.6 协作工具
当任务超出单个 Agent 的能力边界时，协作工具可以让它把子任务委托给其他 Agent 或人类，再整合各方的结果。
子 Agent 的设计哲学
子 Agent 的核心价值在于专业化分工------与其构建一个"全能"的 Agent，不如构建一组各自专精的 Agent，让它们通过协作来解决问题。每个子 Agent 可以独立优化提示词、工具集和知识库，无需担心相互之间的冲突。
子 Agent 提示词的关键要素
- 角色定义要清晰。开门见山说明"你是专门负责 XXX 的助手 Agent"。
- 上下文来源要明确标注。区分不同信息来源：
[FROM_MAIN_AGENT]为主协调 Agent 的任务指令；[FROM_USER]是用户直接补充信息；[TOOL_RESULT]是工具调用返回结果。避免混淆信息来源，抵御提示注入攻击。 - 任务边界要明确界定。写明职责范围，定义哪些内容需要转交或上报。
- 输出格式要标准化。统一 JSON 结构，降低主 Agent 解析负担，提升错误处理可靠性。
子 Agent 上下文的准备
主 Agent 调用子 Agent 时，上下文传递需要平衡信息充足度、token 开销和隐私风险，提供四种递进策略：
- 最小化传递：仅传递调用参数，不带历史对话。隐私安全，但可能信息不足；适合简单高频调用，如查天气、计算器。
- 手动筛选传递：由主 Agent 显式指定共享上下文，可控性强，但提示词设计复杂度更高。
- 自动裁剪传递：系统规则自动筛选上下文，例如用户信息、最近多轮对话、相关工具结果；平衡信息与开销，作为中等复杂度任务默认方案。
- LLM 生成上下文：额外调用 LLM，基于任务轨迹、业务隐私规则动态生成结构化上下文。灵活性最强，可内置隐私过滤、长文本摘要；代价是增加一次 LLM 调用开销，适合复杂任务，如报告生成、客户服务。
Agent 间的协作机制
基于基础工具原语：spawn_subagent 创建子Agent、send_message_to_subagent 通信、cancel_subagent 取消任务。
支持多种协作形态：
- 同步调用：等待子Agent返回，适合短时任务
- 异步调用：返回任务ID，完成后事件通知
- 流式协作：子Agent持续推送增量消息
- 多轮交互：子Agent主动问询，与主Agent对话协作
本章聚焦工具接口与上下文传递策略；多Agent拓扑组织与分工架构属于第十章内容。
人工介入的艺术（HITL 人在回路）
部分关键决策需要人类价值观、常识或专业知识介入。
- 超时和降级策略：HITL请求设置超时阈值，无人响应时启用保守兜底策略；使用优先级队列，紧急任务多渠道通知。
- 反馈循环的建立：HITL不是一次性交互，需要形成学习闭环。记录人类审批、驳回判断与理由。可将人机决策数据做成监督数据集用于后训练；或将决策案例存入知识库，Agent遇到相似场景检索案例辅助判断，该方式可解释性更强。