Tool Calling(工具调用,也称 Function Calling / 函数调用)是大型语言模型(LLM)与外部系统交互的核心能力——它让 LLM 不只停留在"对话生成",而是能够调用真实的函数、API 和服务来获取数据、执行操作、完成任务。
前置教程
如想快速开始学习本教程,你可能需要先完成以下前置教程:
- 大语言模型LLM服务商Api服务调用教程,本文介绍了如何获取和调用 LLM 服务商的 API,是进行项目示例应用的前提。
- Python+FastAPI在Windows环境下创建一个基础后端服务教程,我们需要自行创建一个简单应用,用以实现LLM的工具调用,你需要能够通过Python+FastAPI创建一个基础后端服务。
资源下载
1. 什么是 Tool Calling
1.1 概念
Tool Calling(工具调用)是指大语言模型在生成回复的过程中,识别出需要调用外部工具才能完成任务,然后以结构化的格式输出工具调用指令,由应用程序(而非模型本身)去执行该调用,并将执行结果返回给模型以生成最终回复的一种交互模式,它的工作模式是:
这种机制让 LLM 突破了自身能力的边界:
| 能力边界 | LLM 自身 | 结合 Tool Calling |
|---|---|---|
| 实时信息 | 仅能基于训练数据回答(可能过时) | 实时查询天气、股票、新闻 |
| 数学计算 | 大数运算易出错 | 调用计算器/代码解释器精确计算 |
| 外部数据 | 无法访问用户私有数据 | 查询数据库、读取文件 |
| 执行操作 | 只能生成文字 | 发送邮件、创建工单、操作设备 |
1.2 Tool Calling 的发展历程
Tool Calling 并非一开始就存在,它随着 LLM 能力的提升逐步演进:
| 阶段 | 代表模型/技术 | 特点 |
|---|---|---|
| Prompt Engineering 时代 | GPT-3 (2020) | 通过提示词让模型输出特定格式文本,由外部程序解析执行 |
| 原生 Function Calling | GPT-4 Turbo (2023.11) | OpenAI 首次在 API 层面原生支持函数调用,模型直接输出结构化调用指令 |
| 并行工具调用 | GPT-4 (2024.04) | 支持在一次回复中同时调用多个工具 |
| 多步工具推理 | Claude 3.5 (2024.06+) | 支持多步骤推理,模型可以依赖前一步工具结果决定下一步调用 |
| 协议标准化 | MCP (2024.11) | Anthropic 推出 MCP 协议,统一工具调用接口标准 |
1.3 为什么需要 Tool Calling
在实际应用中,LLM 单纯依靠其内部知识(训练数据中的信息)无法满足很多真实需求,Tool Calling 是将 LLM 从"对话生成器"升级为"智能执行体"的关键技术。没有 Tool Calling,LLM 只能"说"不能"做"。
2. Tool Calling 的工作原理
2.1 关键角色
| 角色 | 说明 |
|---|---|
| LLM 模型 | 分析用户意图,决定是否调用工具以及调用哪个工具 |
| 应用程序(被调用方) | 管理对话流程,执行实际的工具函数,将结果回传给 LLM |
| 工具函数 | 实际执行操作的代码,如查询 API、读写文件、发送请求等 |
2.2 Tool 的定义格式
要让 LLM 知道有哪些工具可用以及如何使用,我们需要以 JSON Schema 格式向 LLM 描述每个工具。
OpenAI 格式(业界标准):
{
"type": "function",
"function": {
"name": "get_weather",
"description": "获取指定城市的当前天气信息",
"parameters": {
"type": "object",
"properties": {
"city": {
"type": "string",
"description": "城市名称,如北京、上海、广州"
},
"unit": {
"type": "string",
"enum": ["celsius", "fahrenheit"],
"description": "温度单位,默认摄氏度"
}
},
"required": ["city"]
}
}
}
JSON Schema 字段详解:
| 字段 | 说明 | 示例 |
|---|---|---|
name |
工具名称,LLM 用它来引用工具 | "get_weather" |
description |
工具功能描述,越清晰 LLM 越能正确调用 | "获取指定城市的当前天气信息" |
parameters |
工具需要哪些参数及其类型约束 | { "type": "object", "properties": {...} } |
properties |
每个参数的名称、类型和说明 | "city": { "type": "string" } |
required |
哪些参数是必需的 | ["city"] |
参数类型定义:
| JSON Schema 类型 | 对应 Python 类型 | 示例 |
|---|---|---|
string |
str |
名称、地址、描述 |
number |
float / int |
温度、价格、数量 |
integer |
int |
整数 ID、页码 |
boolean |
bool |
开关、标志位 |
array |
list |
列表、标签集合 |
object |
dict |
复合数据结构 |
2.3 工具描述 description 的编写技巧
description 字段的质量直接影响 LLM 是否能正确选择工具,一定程度上,它是暴露给 LLM 的、关于自身能力的初始印象:
| 原则 | 好的描述 | 不好的描述 |
|---|---|---|
| 明确用途 | "获取指定城市的实时天气数据,包括温度、湿度、风力" |
"天气函数" |
| 说明何时使用 | "当用户询问某个城市的天气、温度、降雨情况时使用" |
"天气工具" |
| 参数说明 | "城市名称,如北京、上海、广州。使用中文全称" |
"城市名" |
| 边界提示 | "仅支持中国主要城市,暂不支持县级市" |
"参数1" |
3. 快速体验 Tool Calling
3.1 准备工作
LLM 服务API:
你需要提前准备一个 LLM 服务商的 API Key,我们这里使用免费的 glm-4.7-flash 模型,你可以在前置教程大语言模型LLM服务商Api服务调用教程中回顾相关内容。
Python 环境:
你需要提前安装 Python 3.10+ 版本并能够使用 Python 创建一个简单的后端服务,你也可以在这篇前置教程中回顾:Python+FastAPI在Windows环境下创建一个基础后端服务教程,我们需要自行创建一个简单应用,用以实现LLM的工具调用。
3.2 功能设计
- 目标:实现一个简单的天气查询功能,用户输入城市名称,LLM 会调用我们的天气工具函数,返回该城市的当前天气信息,同时不影响其他对话能力。
- 架构:
- LLM 模型:glm-4.7-flash(兼容OpenAI API接口调用)
- 后端服务:基于Python+FastAPI创建的简单后端服务,负责接收用户请求、与LLM模型交互、调用工具函数、返回结果。
- 工具函数:模拟各个城市的天气数据,实际开发中替换为真实的 API 调用。
- 前端页面:基于HTML+CSS+JavaScript创建的简单前端页面,负责用户输入城市名称、显示天气信息及其他对话操作。
3.3 项目示例
完整代码:
你可以在网盘下载get-weather项目查看完整代码。
启动前的配置:
设置
config.py中的环境变量LLM_API_KEY为你的GLM API Key。 确保你已经创建了项目环境并安装了 requirements 中的依赖,如uvicorn、fastapi等。
启动服务:
项目根目录下执行以下命令启动服务:
python main.py
调用测试:
- 打开浏览器,访问
http://localhost:8001即可查看前端页面。 - 输入城市名称,如 "北京",点击 "查询天气" 按钮。
- 你可以在前端页面查看返回的天气信息。

4. Tool Calling 应用策略
在Tool Calling的实际应用中,有以下几方面的内容不容忽视:
- 错误处理策略
- 工具选择策略:自动、强制、禁用等
- 安全与权限管理
受制于篇幅,我们会在后面教程中根据实际情况展开介绍。
5. Tool Calling 与 MCP 的关系
Tool Calling 解决了"LLM 如何调用工具"的问题,却没有解决工具如何被发现、如何连接、如何管理的问题。
这正是 MCP(Model Context Protocol) 的定位:
| 对比维度 | 原生 Tool Calling | MCP |
|---|---|---|
| 工具定义 | 开发者手动在 API 请求中编写 JSON Schema | 工具由 MCP 服务器自动注册和发现(tools/list) |
| 工具执行 | 开发者自行编写工具执行代码 | MCP 服务器负责工具执行,客户端只负责调用 |
| 工具管理 | 工具定义散落在代码中,难以复用 | MCP 服务器是独立进程,可被多个客户端共享 |
| 跨模型 | 工具定义格式因模型而异(比如OpenAI与Claude) | MCP 是协议标准,与模型无关 |
| 远程调用 | 需要自行处理 HTTP 调用逻辑 | 天然支持 stdio(本地)和 SSE(远程)两种传输 |
MCP = Tool Calling 的标准化 + 服务化:
- 标准化:统一了工具定义格式、发现方式、调用协议
- 服务化:工具可以是独立的进程或服务
更详细的 MCP 介绍请参考:MCP概念详解与应用完整教程
6. 总结
6.1 核心内容回顾
经过本节内容的学习,你已经掌握了以下知识:
| 知识点 | 核心要点 | 掌握程度 |
|---|---|---|
| Tool Calling 基本概念 | LLM 通过结构化输出调用外部工具的交互模式 | 理解 |
| 工具定义格式 | 使用 JSON Schema 描述工具的名称、参数和用途 | 掌握 |
| API 调用流程 | 消息构建 → LLM 响应(tool_call) → 执行工具 → 结果回传 → 最终回复 | 掌握 |
| 工具调用 | 多轮与多工具调用 | 掌握 |
| Tool Calling 与 MCP 的关系 | MCP 是 Tool Calling 的标准化和服务化,提供了完整的工具调用生态 | 理解 |
6.2 常见问题与解答
问:Tool Calling 和 Function Calling 有什么区别?
两者本质是同一个概念。OpenAI 最早在其 API 中将其命名为 Function Calling,后续业界将其泛化为 Tool Calling。Anthropic 的 API 中使用 Tool Use 这一术语。在 MCP 协议中统称为 Tools。名称不同但核心思想一致:让 LLM 能够调用外部函数/工具。
问:LLM 一定会正确调用工具吗?
不保证。LLM 可能:
- 选错工具:在多个工具中选择了一个不合适的
- 参数错误:生成了错误的参数值或格式
- 幻觉调用:在不需要工具时错误地调用了工具
解决方案:精心编写工具描述、设置合理的工具描述,在应用层实现参数验证和错误处理。
问:Tool Calling 和 Prompt Engineering 都能让 LLM 使用工具,区别在哪?
| 对比维度 | Prompt Engineering 方式 | 原生 Tool Calling |
|---|---|---|
| 实现方式 | 提示词要求 LLM 输出固定格式文本 | API 层面原生支持结构化输出 |
| 解析可靠性 | 需要正则/LLM 解析,易出错 | 结构直接从 API 返回,100% 可靠 |
| 参数类型校验 | 需自行处理 | API 层面确保参数符合 Schema |
| 并行调用 | 难以实现 | 原生支持 |
| 生态集成 | 各框架自行实现 | MCP、LangChain、AutoGen 等框架原生支持 |
举手提问