工具使用导读：让 LLM 从"会说"变成"会做"

本章阅读时间：约25分钟（共3篇）

1.1 Function Calling / Tool Use 是什么

官方定义（来自 OpenAI 官方文档）：

The tools parameter in the Chat Completion API can be used to provide function specifications. The purpose of this is to enable models to generate function arguments which adhere to the provided specifications.

Chat Completion API 中的 tools 参数用于提供函数规范。其目的是让模型生成符合规范的函数调用参数。

一个关键认知，官方文档明确说明：

The API will not actually execute any function calls. It is up to developers to execute function calls using model outputs.

API 本身不会执行函数调用。执行函数调用是开发者的责任，使用模型的输出来完成。

Anthropic 对工具使用的定义：工具（Tools）是扩展 Agent 功能的扩展，使其能够"获取实时数据、执行代码、查询外部数据库并在世界中采取行动"。从技术上讲，它们是"具有明确输入输出的可调用函数，传递给聊天模型"。

一句话理解：Function Calling 是 LLM 的"决策"能力——模型决定调用哪个函数、传什么参数，但真正执行的是你的代码。

1.1.1 Function Calling 的四步工作流

官方文档描述的标准工作流：

发送请求：将用户消息和工具定义（函数名、描述、参数 Schema）一起发给模型
模型决策：模型判断是否需要调用工具，如需要则返回 finish_reason: "tool_calls" 和调用参数
执行函数：开发者用模型返回的参数调用实际函数，获取结果
继续对话：将函数结果追加到消息历史，再次调用模型生成最终回答

想象你雇了一位博学的顾问，他读过世界上几乎所有的书，能回答你任何问题。但有一个致命缺陷：他只能说话，不能动手做事。他知道如何查汇率，但没法帮你查；他知道数据库查询语法，但没法连到你的数据库；他知道怎么发邮件，但没法帮你发。

这就是没有工具调用的 LLM 的处境。工具调用（Function Calling / Tool Use）是让 LLM 从"会说"变成"会做"的关键机制，也是 Agent 能力的基础设施。

为什么 LLM 必须依赖工具

LLM 有三个结构性的先天局限，靠改进模型本身无法彻底解决：

局限一：知识截止日期

LLM 的"知识"来自训练数据，训练完成后就冻结了。今天的天气、实时的股价、刚发布的 API 文档——这些都在它的知识截止日期之后，它统统不知道。强行回答只会给你一个过时的或者编造的答案。

局限二：不能执行代码

让 LLM 计算 1234567 * 8901234，它会用语言推理猜一个答案。不够精确，不够可靠。它知道 Python 语法，但它本身不是 Python 解释器；它知道 SQL，但它没有数据库连接。知道和能做，是两回事。

局限三：无法访问外部系统

查你的 MySQL 数据库、调用你公司的内部 API、发一封邮件——LLM 只是一个文本处理器，它和这些系统之间没有任何连接。

工具调用就是为了突破这三个边界，让 LLM 能够指挥外部程序来完成它自己做不到的事情。

工具调用的工作机制

有一个关键认知需要在学习之前确立：LLM 不直接执行工具，它只做决策。

真正的工具执行，始终由开发者的代码完成。LLM 的角色是"指挥官"，负责判断：需要调哪个工具？传什么参数？得到结果后怎么整合进回答？

完整的工具调用流程如下：

code

第一步：开发者定义工具
  → 工具名称、功能描述、参数规格（JSON Schema 格式）

第二步：把工具定义随消息一起发给 LLM
  → LLM 知道"我有这些工具可以用"

第三步：LLM 分析用户问题，决策
  → 需要工具吗？需要哪个？参数是什么？

第四步：LLM 返回"工具调用请求"
  → 不是文字回答，而是一个结构化的调用意图：{"tool": "get_weather", "args": {"city": "北京"}}

第五步：开发者代码执行实际的工具调用
  → 真正地去请求天气 API，真正地去查数据库

第六步：把工具执行结果发回给 LLM
  → LLM 看到了真实的数据

第七步：LLM 根据工具结果生成最终的自然语言回答

这个设计的安全性很重要：LLM 只能"建议"调什么工具，实际执行权始终在开发者手里。你可以在执行前加权限检查、参数校验、人工确认，任何危险操作都可以拦截。

本章内容结构

本章三篇文章，从不同角度完整覆盖工具调用：

文章	角度	核心内容
09.Function-Calling详解	底层原理层	JSON Schema 工具定义、消息格式、多轮调用、并行调用
03.LangChain Tools	框架实践层	`@tool` 装饰器、`bind_tools`、完整调用循环、内置工具
04.OutputParser	输出处理层	结构化输出解析、PydanticOutputParser、`with_structured_output`

关于编号说明：本章文章编号不连续（00、03、04、09），是因为部分内容从第6章和第14章整合而来，编号保留了原始序号。学习顺序请按导读中的路径，而不是按编号顺序。

推荐阅读顺序

先读第 09 篇（Function-Calling 详解），理解底层机制——为什么要这样设计、消息格式是什么样的、LLM 和工具之间怎么来回传递信息。这是理解一切上层框架的基础。

再读第 03 篇（LangChain Tools），看 LangChain 怎么把这些机制封装成好用的 API，@tool 装饰器、bind_tools、完整的多工具调用循环。

最后读第 04 篇（OutputParser），理解如何把 LLM 的输出可靠地转成结构化数据对象，而不是手动解析字符串。

工具调用的核心设计原则

学完工具调用之后，有几个原则值得记住：

工具描述比代码更重要

LLM 完全依赖工具的 description 字段来决定什么时候用哪个工具。描述写得模糊，LLM 就会选错工具或者搞错参数。写工具描述，就是在给 LLM 写使用说明书——越精准越好。

工具数量不是越多越好

一个 Agent 挂 3-5 个工具，效果通常优于挂 15 个工具。工具太多，LLM 在选择时更容易出错，就像菜单太长反而不知道点什么。如果工具很多，应该考虑按职责拆分成多个专责 Agent。

错误处理必须返回有意义的信息

工具执行失败时，要把有意义的错误信息返回给 LLM，让它能决定下一步策略，而不是直接抛出异常让程序崩溃。

写入操作需要谨慎

涉及删除数据、发邮件、扣款等不可逆操作的工具，应该在 LLM 决策和工具执行之间加一个人工确认步骤（Human-in-the-loop）。

与其他章节的关联

与 API 入门（第 7 章）的关系

工具调用本质上是 API 调用的扩展——在基础的文本生成之上，增加了工具定义和工具结果回填的机制。第 7 章的 API 基础用法是先决条件。

与 Prompt 工程（第 8 章）的关系

工具的 description 字段就是 Prompt 工程的直接应用。写好工具描述，需要理解 LLM 如何理解自然语言指令，这正是 Prompt 工程的核心。

与 MCP 协议（第 10 章）的关系

MCP 是工具调用能力的标准化协议层。第 9 章理解了工具调用的本质，第 10 章才能理解 MCP 的价值——它解决的是"工具如何跨应用复用"的问题。

与 Agent 基础（第 12 章）的关系

Agent 的核心能力之一就是工具调用。Agent 的"行动"（Action）本质上就是工具的调用和结果处理。第 12 章的 Agent 系统完全建立在本章的工具调用能力之上。

与 LangGraph（第 13 章）的关系

LangGraph 把工具调用纳入了图节点，工具调用节点是 LangGraph 工作流的基本构件之一。理解了本章，看 LangGraph 的工具节点会非常直觉。