四十五：工具 Tool¶

来源:http://mp.weixin.qq.com/s?__biz=MzYyNTk3Njg1NA==&mid=2247484607&idx=1&sn=34b4764c45fcb3125e80b90387b44217&chksm=f01eb7c6c7693ed0428b58d00a50b2349783e076fa4b57a1a739db671b7239661d316768e620#rd

1. 学习范围¶

本日主题是 Agent 的 Tool 能力，重点是 4.5.4 HuggingGPT，同时覆盖 Toolformer、MRKL 和 Function Calling。本日覆盖： - Tool 在 LLM Agent 中的定位。

工具调用的抽象：工具描述、参数 schema、调用、观察、结果融合。
Toolformer 的自监督工具使用思想。
MRKL 的神经符号模块路由思想。
Function Calling 的工程接口设计。
HuggingGPT 的四阶段流程：任务规划、模型选择、任务执行、响应生成。
工具型 Agent 的失败模式、评估方法和生产化要点。

2. Tool 的基本定义¶

Tool 是 LLM 通过结构化接口调用的外部能力。它可以是搜索、计算器、数据库、代码解释器、图像模型、语音模型、业务 API 或文件系统操作。 LLM 本身擅长语言理解、推理和生成，但不擅长稳定执行外部动作、访问实时数据、进行精确计算或处理专门模态。Tool 的作用是把模型的自然语言推理能力和外部可执行能力连接起来。典型工具调用循环：

User Query
&nbsp; -&gt; LLM decides tool
&nbsp; -&gt; Tool call with structured arguments
&nbsp; -&gt; Tool returns observation
&nbsp; -&gt; LLM integrates observation
&nbsp; -&gt; Final answer or next tool call

3. Tool 与 Agent 的关系¶

Tool Calling 本身不等同于 Agent。Tool Calling 是能力接口，Agent 是围绕目标进行规划、行动、观察和调整的系统。对比：

Function Calling: 模型按 schema 生成一次或多次工具调用。
Tool-using Agent: 模型根据目标决定是否调用工具、如何调用工具、如何处理结果。
Autonomous Agent: 进一步包含规划、记忆、反思、长期状态和任务闭环。

Tool 是 Agent 的动作空间，Planning 决定何时使用工具，Memory 提供历史上下文，Reflection 帮助修正错误工具使用。

4. 工具调用的核心组成¶

一个工具通常包含： - Name：工具名称。

Description：工具能力和适用边界。
Parameters schema：输入参数结构、类型、是否必填。
Execution function：实际执行逻辑。
Return schema：返回结果结构。
Error contract：失败时如何返回错误。
Permission policy：是否需要授权、确认或沙箱。

示例：

{
&nbsp; "name": "search_paper",
&nbsp; "description": "Search academic paper metadata by title or keyword.",
&nbsp; "parameters": {
&nbsp; &nbsp; "query": "string",
&nbsp; &nbsp; "top_k": "integer"
&nbsp; }
}

好的工具设计必须让模型知道什么时候该用、什么时候不该用、参数怎样填、返回结果如何解释。

5. 工具描述与参数 Schema¶

工具描述是模型选择工具的主要依据。描述太宽泛会导致误调用，太窄会导致漏调用。参数 schema 的价值： - 限制输入结构，减少自由文本歧义。

便于系统验证参数合法性。
支持自动生成 UI 或 API 请求。
便于记录和审计调用。

常见错误： - 工具名称相似，模型混淆。

参数字段命名不清。
缺少单位、时间范围和枚举值说明。
工具描述承诺了实际函数不能完成的能力。

6. Function Calling 的工程模式¶

Function Calling 是把工具接口显式提供给模型，让模型输出结构化函数调用参数。系统收到函数调用后，由宿主程序执行函数，并把结果返回给模型继续生成。典型流程：

1. Developer defines function schema
2. Model returns function/tool call
3. Application validates arguments
4. Application executes tool
5. Tool result is passed back to model
6. Model produces final response or calls another tool

Function Calling 的关键是：模型生成的是调用意图和参数，真正执行由外部程序完成。系统不能直接信任模型参数，需要验证、权限控制和错误处理。

7. Function Calling 的常见用法¶

Function Calling 常用于： - 查询数据库。

调用业务 API。
获取实时天气、股票、日程等数据。
执行计算和代码。
读写文件。
搜索文档或互联网。
控制多模态模型和外部服务。

它适合参数明确、执行逻辑稳定、返回结构可验证的场景。

8. Function Calling 的限制¶

Function Calling 不自动保证任务成功。常见限制包括： - 模型选错工具。

参数提取错误。
缺少必要字段。
工具返回错误或超时。
模型误解工具结果。
多工具调用顺序错误。
高风险操作缺少用户确认。

因此 Function Calling 需要和规划、状态管理、重试、校验器、权限系统结合。

9. Toolformer 的核心思想¶

Toolformer 研究如何让语言模型通过自监督方式学会使用工具。核心思路是让模型在普通文本中自动标注 API 调用位置和参数，并通过语言建模损失筛选真正有帮助的工具调用样本，再用这些样本微调模型。

简化流程：

Raw text
&nbsp; -&gt; sample possible API calls
&nbsp; -&gt; execute API calls
&nbsp; -&gt; insert API result into text
&nbsp; -&gt; keep calls that reduce language modeling loss
&nbsp; -&gt; finetune model on augmented data

Toolformer 的关键贡献是：不依赖大量人工标注，让模型通过自监督信号学习“何时调用工具、如何调用工具、如何利用工具结果”。

10. Toolformer 的工具类型¶

Toolformer 论文中涉及的工具包括： - Calculator：精确计算。

Calendar：日期相关问题。
Search engine：检索外部信息。
QA system：问答工具。
Machine translation system：翻译工具。

这些工具体现了 LLM 的典型短板：计算、实时知识、专业模块和外部事实访问。

11. Toolformer 的优势与限制¶

优势： - 自监督构造工具使用数据。

学到工具调用位置和参数。
可以提升特定能力，例如计算和事实查询。
把工具调用写入模型生成过程，而不只是外部 wrapper。

限制： - 依赖可自动执行和验证的 API。

工具调用质量受采样和筛选策略影响。
工具集合扩展后需要重新构造训练数据或适配。
训练成本和工程复杂度较高。
不等同于完整 Agent 规划系统。

12. MRKL 的核心思想¶

MRKL, Modular Reasoning, Knowledge and Language, 是一种神经符号系统架构。它把大模型和多个专家模块组合起来，由路由器决定把问题交给哪个模块或模块组合处理。

MRKL 的核心思想：

User input
&nbsp; -&gt; Router
&nbsp; -&gt; Expert module, such as calculator/search/KB/code
&nbsp; -&gt; Aggregation
&nbsp; -&gt; Final answer

MRKL 强调模块化和可解释性。LLM 不必解决所有问题，而是把专业任务交给可靠模块。

13. MRKL 与 Tool Calling¶

MRKL 可以看作早期工具型 Agent 的系统化表达。它把不同能力封装成专家模块，通过路由机制选择模块。现代 Tool Calling 则把这种模块选择以函数 schema 和模型 tool call 的方式工程化。主要差异： - MRKL 更强调模块化架构和路由。

Function Calling 更强调模型与外部函数的结构化接口。
Agent 框架进一步加入规划、记忆、反思和多步执行。

14. HuggingGPT 的问题背景¶

HuggingGPT 的出发点是：单个 LLM 无法精通所有模态和专业任务，但 Hugging Face 上有大量专用模型。可以让 ChatGPT 作为控制器，理解用户请求、拆分任务、选择模型、执行模型并整合结果。 HuggingGPT 解决的问题： - 多模态任务需要多个模型协作。

专业模型数量庞大，人工选择成本高。
用户自然语言请求需要转成可执行任务图。
不同模型输入输出格式需要串联。

15. HuggingGPT 的总体架构¶

HuggingGPT 把 LLM 作为中枢控制器，把 Hugging Face 模型作为外部工具集合。

总体流程：

User Request
&nbsp; -&gt; Task Planning
&nbsp; -&gt; Model Selection
&nbsp; -&gt; Task Execution
&nbsp; -&gt; Response Generation

四个阶段分别解决： - 要做哪些子任务。

每个子任务用哪个模型。
如何执行模型并传递中间结果。
如何把结果组织成用户可理解的最终回答。

16. Task Planning¶

Task Planning 阶段由 LLM 分析用户请求，将复杂任务拆成结构化子任务，并识别依赖关系。例如用户请求：

请描述这张图，并把描述翻译成法语，再根据描述生成一张新图。

可能被拆成：

1. image-to-text: 输入原图，输出英文描述
2. translation: 输入英文描述，输出法语文本
3. text-to-image: 输入描述，输出新图

Planning 的质量直接决定后续模型选择和执行是否正确。

17. Model Selection¶

Model Selection 阶段根据任务类型、模型描述和可用模型列表选择合适模型。模型描述通常包含任务能力、输入格式、输出格式和性能信息。选择依据： - 子任务类型。

模型支持的 modality。
输入输出格式匹配。
模型可用性和延迟。
模型描述质量。
可能的性能或评分。

风险是模型描述不准确或任务标签不匹配，导致选择错误模型。

18. Task Execution¶

Task Execution 阶段调用选定模型，执行子任务并处理依赖。多步任务中，前一个模型的输出可能是后一个模型的输入。执行需要处理： - 输入文件路径或 URL。

文本、图像、音频等不同数据格式。
模型调用失败或超时。
中间结果命名和传递。
并行执行与依赖顺序。

执行层必须是工程系统负责，不能只靠 LLM 口头描述。

19. Response Generation¶

Response Generation 阶段由 LLM 汇总子任务结果，生成最终回答。它需要说明完成了哪些任务、输出在哪里、结果含义是什么。风险包括： - 没有真实执行却生成成功描述。

忽略部分工具错误。
对模型输出过度解释。
把中间结果当最终结果。

因此最终回答应绑定实际执行记录和工具返回结果。

20. HuggingGPT 的关键价值¶

HuggingGPT 的价值在于展示了 LLM 作为控制器连接大量专用模型的可行性。它把 LLM 从单一生成器扩展为任务协调器。关键价值： - 支持复杂多模态任务。

复用模型社区中的专用模型。
将自然语言请求转成可执行工作流。
展示 LLM + tools + model hub 的系统形态。

21. HuggingGPT 与 Toolformer 的区别¶

Toolformer 重点是让模型通过自监督学习直接使用少量 API，偏训练方法。HuggingGPT 重点是让 LLM 作为控制器调度大量外部模型，偏系统架构。对比：

Toolformer: 模型学习何时插入 API 调用。
HuggingGPT: 控制器规划任务并选择外部模型执行。

22. HuggingGPT 与 MRKL 的区别¶

MRKL 强调模块化专家和路由器，HuggingGPT 更具体地将专家模块扩展为 Hugging Face 模型库，并增加任务规划、模型选择、执行和结果生成四阶段。可以把 HuggingGPT 看作一种大规模、模型库驱动的 MRKL/Tool Agent 实例。

23. HuggingGPT 与 Function Calling 的关系¶

Function Calling 提供结构化调用接口，HuggingGPT 提供多模型调度流程。HuggingGPT 中的模型调用完全可以用 function/tool schema 封装。例如：

run_model(model_id, task_type, input_uri, parameters)

Function Calling 解决“怎么规范调用”，HuggingGPT 解决“如何规划、选择和串联多个模型”。

24. 工具型 Agent 的失败模式¶

常见失败包括： - 工具选择错误。

参数抽取错误。
工具描述不清。
任务拆分错误。
依赖关系错误。
工具返回结果被误读。
调用失败后没有重试或降级。
模型幻觉工具结果。
高风险工具缺少确认。
工具权限过宽。

HuggingGPT 中还会出现模型选择错误、模态转换失败、模型不可用和中间结果格式不兼容。

25. 工具型 Agent 的评估¶

工具型 Agent 评估应覆盖： - Tool selection accuracy：是否选对工具。

Argument accuracy：参数是否正确。
Execution success rate：工具是否成功执行。
Result grounding：回答是否基于工具结果。
End-to-end task success：最终任务是否完成。
Cost and latency：工具调用成本和时间。
Safety compliance：权限和确认是否合规。

不能只看最终文本是否流畅。工具链路中的每一步都应可观测。

26. 生产化原则¶

生产工具型 Agent 应遵守： - 工具描述准确且边界清晰。

参数 schema 严格验证。
工具调用有权限和审计。
高风险操作需要用户确认。
工具失败时有重试、降级和错误反馈。
模型输出必须绑定真实工具结果。
记录完整 tool trace。
对工具结果做安全过滤和格式校验。

27. 核心总结¶

Tool 让 LLM 从“语言生成器”变成“外部能力调度器”。Toolformer 说明模型可以通过自监督学习工具调用，MRKL 说明 LLM 可以和专家模块组合，Function Calling 提供现代工程接口，HuggingGPT 展示了 LLM 调度大规模模型库完成复杂多模态任务的系统范式。面试表达时应突出： - Tool 是 Agent 的动作空间，必须与规划、记忆和执行控制结合。

HuggingGPT 的核心是四阶段：任务规划、模型选择、任务执行、响应生成。
工具型 Agent 的难点在工具选择、参数正确性、执行可靠性、结果 grounding、安全边界和可观测性。

28. 参考资料¶

Toolformer: Language Models Can Teach Themselves to Use Tools: https://arxiv.org/abs/2302.04761
MRKL Systems: A modular, neuro-symbolic architecture that combines large language models, external knowledge sources and discrete reasoning: https://arxiv.org/abs/2205.00445
HuggingGPT: Solving AI Tasks with ChatGPT and its Friends in Hugging Face: https://arxiv.org/abs/2303.17580
OpenAI Function Calling guide: https://platform.openai.com/docs/guides/function-calling
```
        预览时标签不可点
```
<div class="