大模型工具调用（Function Call / Tool Call）核心原理完整讲解

大模型支持工具调用，本质是大模型从"纯文本生成"升级为"结构化决策+格式生成" ，通过预训练范式、Prompt约束、结构化输出、执行链路闭环，实现模型感知外部工具、生成合规调用指令、交由外部系统执行、再把执行结果带回模型续写回答的全流程。下面从核心原理、流程链路、格式机制、训练范式、关键约束、和Agent的关系六个层面，用通俗+工程化的方式完整说明。

一、一句话核心原理

大模型本身不直接执行代码、不访问数据库、不调用第三方接口，它只做一件事：

根据用户意图和给定的Tool Schema，以严格JSON格式输出"要调用哪个工具、传什么参数" ；

真正的执行、IO、计算，全部由模型外部的调度器/Agent框架（如AgentScope、LangChain、OpenAI SDK、Spring AI）完成，执行结果再作为新上下文喂回模型，生成最终自然语言回答。

可以用一句话类比：

大模型 = 会看说明书、会写调用单的"调度员"
外部工具 = 真正干活的"工人"（API、数据库、计算器、搜索、文件读取）
调度框架 = 传递调用单、收结果、递回给调度员的"信使"

二、完整工具调用流程（标准闭环）

这是所有支持Tool Call的大模型（GPT系列、Qwen、文心一言、Doubao、GLM等）通用标准流程，不分厂商，原理完全一致：
纯文本回答
工具调用指令
用户提问
构造Prompt: 系统描述+工具列表+用户问题
模型再次推理: 整合结果生成自然语言回答
模型输出类型?
直接返回用户
框架解析JSON: 提取tool_name/parameters
框架执行真实工具: HTTP/DB/本地方法
收集工具返回结果
把结果拼回对话上下文

流程逐环节拆解

工具注册与Schema注入

开发者先定义所有可用工具的结构化描述（JSON Schema），包含：
- 工具名（name）
- 功能描述（description）
- 参数结构（type、properties、required、enum、示例等）
  这部分会以System Prompt的形式固定注入模型上下文，相当于给模型发"工具说明书"。
意图判断与工具选择

模型接收到用户问题后，基于上下文和工具说明书做推理：
- 是否需要调用外部工具？（如"查天气、算数学、查订单"必须调用；"写作文"不需要）
- 若需要，从注册列表里选最匹配的一个/多个工具。
结构化参数生成（核心能力）

模型不随意输出文本，而是强制输出符合JSON Schema的调用指令 ，格式由厂商统一规范（如OpenAI格式、通用Tool Call格式）。

模型的工作就是：把用户自然语言参数，映射为工具要求的结构化字段。

例：用户说"帮我查北京明天天气"→模型输出{"name":"get_weather","parameters":{"city":"北京","date":"2026-02-03"}}
外部框架解析与执行

Agent/调度框架做纯工程工作：
- 校验JSON格式合法性
- 校验必填参数是否存在
- 路由到对应工具实现（Java方法、Python函数、REST接口、数据库查询）
- 捕获成功/失败结果
结果回灌与多轮续写

工具执行结果（文本、JSON、表格）会作为新的用户/工具消息追加到对话历史，模型进行第二轮推理：
- 阅读执行结果
- 整理、翻译、解释、汇总
- 输出人类可读的最终回答
  若一次调用不够（如先查用户ID、再查订单、再查物流），模型可连续输出多轮工具调用，形成多跳工具调用。

三、关键机制：模型为什么能输出规范JSON？

很多人会疑惑：大模型是生成式的，为什么能稳定输出可解析的JSON，而不是乱码或自由文本？核心来自三个层面：

1. 预训练数据与对齐训练（SFT/RLTF）

支持Tool Call的模型，在训练阶段就加入了大量**「自然语言指令 → 结构化JSON调用」**的样本对：

输入：用户问题 + 工具列表
输出：标准格式的tool call JSON
模型学习到的是模式匹配与格式遵循，而不是"理解工具本身"。它本质学到的是：

遇到这类意图 → 输出这个结构 → 参数按这个位置填。

2. 强约束Prompt（系统提示词）

厂商内置或开发者手动添加的System Prompt会明确要求：

只从给定列表选工具
必须严格按指定JSON结构输出
不允许添加多余文本、注释、说明
参数必须匹配类型和枚举
这是语法约束，让模型生成行为高度收敛。

3. 采样与解码约束（Decoder Constraints）

高阶支持工具调用的模型，会在推理时做解码级限制：

强制输出以{开头、}结尾
限制key只能是name/parameters/tool_call_id等固定字段
参数值做类型校验（数字、字符串、枚举范围）
部分开源模型使用Grammar Constrained Decoding、JSON Schema约束采样，从token层面杜绝格式错误。

四、标准工具调用格式（通用Schema）

不管是闭源模型（GPT、Qwen-Max）还是开源模型，工具调用格式高度趋同，以下是行业事实标准结构，也是你前面看到的AgentScope、Function Call的底层格式：

1. 工具定义格式（给模型看的说明书）

json 复制代码

{
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_new_product",
        "description": "获取奶茶店新品推荐",
        "parameters": {
          "type": "object",
          "properties": {
            "userId": {
              "type": "string",
              "description": "用户ID"
            }
          },
          "required": ["userId"]
        }
      }
    }
  ]
}

2. 模型输出的工具调用指令

json 复制代码

{
  "tool_calls": [
    {
      "id": "call_001",
      "type": "function",
      "function": {
        "name": "get_new_product",
        "parameters": "{\"userId\":\"12345678901\"}"
      }
    }
  ]
}

3. 工具执行结果回传格式

json 复制代码

{
  "role": "tool",
  "tool_call_id": "call_001",
  "content": "推荐新品：云桃乌龙、桂花云露"
}

这三段结构，就是所有大模型工具调用的通用语言，模型只负责生成第二段，第一段由开发者定义，第三段由框架构造。

五、模型到底"懂不懂"工具？------ 重要认知澄清

这是最容易产生的误区，必须明确：

模型没有执行能力

模型无法发起HTTP请求、无法写文件、无法连接MySQL，它甚至不知道"函数执行"是什么。它只输出字符串（JSON），执行是外部系统的工作。
模型不"理解"工具业务逻辑

模型不知道get_weather内部是怎么调用气象API的，它只知道：
- 这个工具叫什么
- 要传什么参数
- 大概能返回什么信息
  完全依赖你写的description描述。
工具调用是生成任务，不是推理任务

从AI技术分类上，Tool Call属于条件生成，而不是逻辑编程。模型最优表现是：格式准、参数对、工具选得对；不代表模型具备真正的"规划能力"（复杂规划属于Agent/Planning模块）。

六、工具调用 vs 普通文本生成 ------ 核心差异

维度	普通文本生成	工具调用（Tool Call）
输出目标	流畅自然语言	严格结构化JSON
约束强度	宽松，允许口语、冗余	极强，必须符合Schema
模型行为	自由续写、创作、解释	意图识别→工具路由→参数填充
后续流程	直接返回用户	解析→执行→回灌→二次生成
依赖外部	无	必须依赖调度框架+工具实现
典型场景	聊天、写作、总结、翻译	查询、计算、操作、数据获取

七、工具调用与Agent、SkillBox、Tool的关系

结合你前面问的 AgentScope、SkillBox、多Tool管理，可以把整套体系串起来：

复制代码

大模型（负责输出Tool Call JSON）
↑↓
Agent/调度框架（AgentScope、Spring AI、LangChain）
  └── SkillBox（工具容器，批量管理多个Tool）
       ├── Tool1：新品推荐
       ├── Tool2：冲泡指导
       ├── Tool3：库存查询
       └── Tool4：订单查询

大模型：只输出"调用指令"，不干活；
SkillBox：集中注册、管理、路由一组工具，给模型提供统一"说明书"；
Agent框架：解析指令、调用SkillBox里的对应Tool、收集结果、回传给模型；
Tool：真正执行IO/计算/接口调用的最小业务单元。

八、常见支持工具调用的模型与实现方式

闭源商用模型
- OpenAI GPT-3.5/4o 系列：原生Function Call
- 通义千问Qwen-Max：Tool Call
- 文心一言、讯飞星火、Doubao大模型：均支持标准工具调用
  调用方式：SDK传入tools参数，模型返回tool_calls结构。
开源模型
- Llama 3、Mistral、Qwen开源版：通过SFT支持工具调用
- 部署方式：配合vLLM、llama.cpp的JSON约束解码
- 格式：兼容OpenAI工具调用规范，便于无缝接入框架

九、总结（最精简核心原理）

本质：大模型工具调用 = 结构化意图识别 + 规范JSON生成，模型不执行任何真实操作。
流程：注入工具说明书 → 模型选工具填参数 → 框架解析执行 → 结果回灌 → 模型生成回答。
能力来源：专用训练数据 + 强Prompt约束 + 解码级格式限制。
分工边界 ：
- 模型：做决策、出格式
- 框架/AgentScope：做解析、做调度、做执行
- Tool/SkillBox：做业务、做数据、做接口

这套原理是所有LLM Agent、工具调用系统、自动化工作流的底层通用理论基础，无论你用Java、Python、任何大模型、任何Agent框架，核心逻辑完全一致。