Tool Calling(工具调用,也称 Function Calling / 函数调用)是大型语言模型(LLM)与外部系统交互的核心能力——它让 LLM 不只停留在"对话生成",而是能够调用真实的函数、API 和服务来获取数据、执行操作、完成任务。

前置教程

如想快速开始学习本教程,你可能需要先完成以下前置教程:

资源下载

1. 什么是 Tool Calling

1.1 概念

Tool Calling(工具调用)是指大语言模型在生成回复的过程中,识别出需要调用外部工具才能完成任务,然后以结构化的格式输出工具调用指令,由应用程序(而非模型本身)去执行该调用,并将执行结果返回给模型以生成最终回复的一种交互模式,它的工作模式是:

graph LR A[用户提问] --> B[LLM] B -->|直接回答| C[回复用户] B -->|需要工具| D[执行工具] D --> B B --> C style A fill:#ebdef0,stroke:#7d3c98,stroke-width:2px style B fill:#ffecd6,stroke:#e67e22,stroke-width:2px style C fill:#d5f5e3,stroke:#27ae60,stroke-width:2px style D fill:#d6eaf8,stroke:#2980b9,stroke-width:2px

这种机制让 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 中的依赖,如 uvicornfastapi 等。

启动服务

项目根目录下执行以下命令启动服务:

python main.py

调用测试

  • 打开浏览器,访问 http://localhost:8001 即可查看前端页面。
  • 输入城市名称,如 "北京",点击 "查询天气" 按钮。
  • 你可以在前端页面查看返回的天气信息。

weather_app_screenshot

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 等框架原生支持