Agents as Tools

• 能说明Agents as Tools解决什么问题，以及何时适用。
• 能解释为什么“子 Agent 直接承担最终责任”是误区。

一个主管可能需要请专家提取条款、翻译段落或检查数据，但仍要自己维护用户目标并组织最终答案。将专家封装成工具，可以让委派像其他工具调用一样具有输入、输出与失败边界。

这种模式适合可收敛的子任务。若专家需要直接与用户连续对话、接管后续流程，则应另外评估控制权交接，而不是把所有协作都藏在工具内部。

Agents as Tools 让一个 Agent 作为另一个 Agent 的函数工具运行，用于有边界的专业子任务。

负责人把分析任务交给专家，专家交回报告，但最终由负责人向用户汇报。

主管为子 Agent 提供明确任务与必要上下文，子 Agent 在自己的指令和工具范围内运行，然后把结果返回主管。调用者保留顶层目标与最终回答责任；子 Agent 的输出只是待验证的中间结果。

好的子任务输入应限定范围与成功条件。例如“从这些段落提取付款期限，并附证据位置”比“研究一下合同”更容易验收，也更容易判断是否需要重试或补充资料。

返回契约应区分发现、证据、不确定性与失败状态。若专家没有找到期限，应明确返回未发现，而不是猜一个数值；主管也不应为了填满最终模板把空结果改写成确定结论。

嵌套运行需要独立预算、超时与父子追踪，权限仍由应用分配。子 Agent 不因被包装成工具就自动继承全部能力；取消顶层任务时，也要考虑如何终止正在运行的子任务。

1. 定义专业 Agent
2. 包装为具名工具
3. 主管选择并调用
4. 专家返回结果
5. 主管验证并汇总

• 研究摘要
• 领域分析

• 子任务范围无限扩大，嵌套调用自己继续拆分却没有预算与停止规则。
• 专家返回没有证据位置和失败状态的长文，主管无法验证却直接引用。
• 把工具封装误当权限隔离，默认向子 Agent 传入全部历史和全部写入能力。

输入

• 边界明确的子任务

输出

• 供主管使用的专业结果

能力

• 研究摘要
• 领域分析