大模型中的 Function Calling 与工具模式:机制、区别与本质

本文由ChatGPT和Claude.ai辅助完成

大模型(LLM)在现代应用中的一个核心能力,是能够按照严格结构调用外部工具,例如数据库查询、Python 代码执行、HTTP 请求、存储系统等。围绕这一点,业界形成了“function calling”与“tools API”等概念。尽管二者在语义上相近,但其实现逻辑、系统结构与应用接口存在明显差异。

本文围绕以下主题展开:

Function calling 与 tools 的定义与区别
Function calling 是否只是一种“更严格的格式输出”
如何指定 function calling 模式
为什么大模型能够进入工具模式(tool mode)
工具模式是概率行为,不是硬编码逻辑
工具模式的本质:训练、API 与提示词的协同机制
MCP 协议:Function Calling 的标准化实践

1. Function Calling 与 Tools:定义与本质区别

1.1 Function calling 是“结构化调用能力”

在 OpenAI、Google、Anthropic 等厂商的 API 语境里，“function calling”更准确地说是模型在工具可用上下文中生成结构化工具调用的能力。其常见特征是:

应用侧会先声明可用工具及其参数 schema
模型会在合适时生成结构化的工具调用信息
参数通常需要与预定义 schema 对齐
工具调用结果再由应用侧执行并回填给模型

它是对大模型输出格式的一种能力层面的约束。

1.2 Tools 是“可调用的工具清单”

Tools 则是 API 层提供给模型的工具定义集合,包括:

函数名称
输入参数 schema
参数类型与约束
功能描述(让模型理解工具用途)

它是系统告诉模型:“你现在可以调用哪些工具”。

1.3 区别总结

两者关系可以这样理解:

Tools 是系统提供给模型的工具目录
Function calling 是模型执行工具调用的能力与方式
API 层负责定义结构;模型负责决策与生成调用

换句话说:

Tools = 可用工具清单
Function calling = 选择并正确调用工具的能力

2. Function Calling 与普通格式化输出的本质差异

2.1 普通提示词格式要求:基于概率,无强制保证

当你通过提示词要求模型输出 JSON:

1	请以 JSON 格式输出,包含 name 和 age 字段

模型可能会:

输出不合法的 JSON
混入注释或说明文字
结构不完整或嵌套错误
使用错误的引号或缺失逗号

它只是较高概率地遵循要求,但没有强制保证。

2.2 Function calling 是训练赋予的专门能力

Function calling 模式下:

模型通常在训练中学习过工具调用相关模式
API 也会通过 tools、tool_choice、schema 等结构化信号约束输出
在部分平台上，如启用严格 schema 约束，参数格式可靠性会更高
相比纯提示词 JSON 输出，结构化调用通常更稳定
但具体返回形式和严格程度，仍取决于不同厂商的 API 设计

2.3 本质差异总结

维度	普通格式化	Function Calling
控制方式	纯提示词引导	训练能力 + API 结构
可靠性	概率性,误差较大	高可靠,误差极小
实现机制	模型对自然语言的理解	专门训练的结构化输出能力

3. 如何指定 Function Calling 模式

3.1 API 中的工具定义

以 OpenAI API 为例:

{
  "model": "gpt-4-turbo",
  "messages": [...],
  "tools": [{
    "type": "function",
    "function": {
      "name": "get_weather",
      "description": "获取指定城市的天气信息",
      "parameters": {
        "type": "object",
        "properties": {
          "city": {
            "type": "string",
            "description": "城市名称"
          }
        },
        "required": ["city"]
      }
    }
  }]
}

3.2 调用模式控制

A. 自动模式(模型决策)

1
2
3

{
  "tool_choice": "auto"
}

模型根据对话内容判断是否需要调用工具。

B. 强制调用特定工具

{
  "tool_choice": {
    "type": "function",
    "function": {"name": "get_weather"}
  }
}

C. 禁用工具调用

1
2
3

{
  "tool_choice": "none"
}

3.3 这是 API 层面的声明式控制

与纯提示词不同,这是结构化的控制信号,模型在训练中已学会如何响应这些信号。

4. 大模型为什么能够进入“工具模式”

核心原因通常是:模型训练、API 结构化约束以及上下文提示共同作用。

现代大模型(GPT、Gemini、Claude)通常会通过训练和后续对齐，让模型学会在工具可用时更稳定地进入结构化调用模式。下面的分解更适合作为一种工作机制理解，而不是厂商公开披露的统一训练细节:

4.1 数据收集

收集大量工具调用示例数据
包含完整的调用流程:
- 用户请求
- 模型决策(是否调用工具)
- 工具调用的 JSON 格式
- 工具返回结果
- 模型整合结果生成最终回复

4.2 监督微调(SFT)

让模型学习正确的工具调用格式
强化参数提取与 JSON 生成能力
学习何时应该调用工具

4.3 强化学习或其他对齐手段

优化工具调用的时机判断
提高格式准确性
改进多工具协作能力

4.4 触发机制

当 API 请求包含 tools 字段时:

模型识别到这是一个工具可用的上下文
激活训练时学习的工具调用行为模式
输出空间偏向于工具调用格式
根据对话内容决策是否调用及调用哪个工具

这不是规则系统,而是模型的学习能力。

5. 工具模式是概率性的,非确定性逻辑

5.1 不是硬编码的 if-else

模型进入工具模式不是因为:

1 2	if api_has_tools: output_format = "function_call"

5.2 而是概率模型的高概率行为

实际机制:

模型在训练中形成了对工具调用的强偏好
当上下文信号(messages + tools schema)出现时
输出工具调用格式的概率变得极高
但仍然是概率分布,不是绝对规则
因此存在微小概率的格式错误或拒绝调用

5.3 为什么可靠性很高

大量高质量训练数据
专门的损失函数优化
RLHF 阶段的强化
在工程实践中，成功率通常会明显高于纯提示词约束

但这仍然是概率模型的表现,而非确定性系统。

6. 工具模式的本质:训练、API 与提示词的协同

6.1 “本质是提示词工程”这个说法的对与错

部分正确之处:

API 中的 tools schema 确实是给模型的“上下文提示”
System prompt 也会包含工具使用指南
从信息论角度,这些都是“输入控制输出概率空间”

不完全准确之处:

API 的 tools 字段不是纯自然语言,而是结构化控制信号
模型对 tools 的响应不仅靠“理解提示词”,更靠训练出的专门能力
这种能力不是通过提示词现场“告诉”模型的,而是预先训练好的

6.2 更准确的理解

Function calling 是以下三者的协同机制:

模型能力层(训练获得的结构化输出能力)
API 控制层(tools 定义与 tool_choice 参数)
上下文层(system prompt 与对话历史)

公式化表达:

1	工具调用成功 = 模型训练能力 × API结构化控制 × 上下文引导

任何一项缺失,可靠性都会大幅下降。

7. MCP 协议:Function Calling 的标准化实践

在理解了 function calling 的本质后,我们可以进一步探讨业界如何将工具接入和上下文交换标准化。MCP (Model Context Protocol) 是由 Anthropic 发起并开放出来的一套协议,用于标准化应用如何向模型提供工具、资源与上下文。

7.1 从能力到协议:为什么需要 MCP

虽然各大模型提供商都支持 function calling,但在实际应用中面临以下问题:

碎片化的工具定义:

每个开发者自定义工具格式
相同功能的工具在不同项目中重复开发
工具无法跨应用、跨平台复用

缺乏统一标准:

没有工具发现机制
权限和安全管理各自实现
集成成本高,维护困难

MCP 的出现就是为了解决这些问题,将 function calling 能力从“单点技术”提升为“生态标准”。

7.2 MCP 的技术定位

MCP 可以理解为工具与上下文集成层的一种开放协议。 在很多实现中,它会与 function calling 或其他工具调用机制配合使用,但两者不是严格的一一依赖关系。可以用技术栈来粗略理解它们的关系:

┌─────────────────────────────────────┐
│  应用层: Claude.ai, AI 应用          │  ← 用户交互
├─────────────────────────────────────┤
│  协议/集成层: MCP                    │  ← 标准化上下文与工具接入
├─────────────────────────────────────┤
│  能力层: Function Calling            │  ← 模型核心能力
├─────────────────────────────────────┤
│  模型层: Claude/GPT/Gemini           │  ← 基础大模型
└─────────────────────────────────────┘

这种分层架构类似于网络协议栈:

Function calling 更像模型侧的结构化工具调用能力
MCP 更像应用和工具之间的标准化接入协议
具体工具 则是在该协议之上暴露能力的实现

7.3 MCP 的核心价值

1. 统一的工具定义标准

MCP 规范了工具、资源等能力的描述与交互方式。实践中,只要客户端和服务端都支持同一版本的 MCP,跨应用复用会更容易:

{
  "name": "read_file",
  "description": "读取文件内容",
  "inputSchema": {
    "type": "object",
    "properties": {
      "path": {"type": "string", "description": "文件路径"}
    },
    "required": ["path"]
  }
}

2. 标准化的通信协议

MCP 当前规范采用 JSON-RPC 消息格式,并定义了客户端与服务器之间的标准通信方式,以提升不同实现之间的互操作性。

3. 可复用的工具生态

开发者可以将工具打包为 MCP 服务器,发布到社区供他人使用。用户可以像安装浏览器插件一样,为 AI 应用添加新能力,而无需修改应用代码。

7.4 MCP 的实际应用场景

基于 function calling 能力,MCP 让以下场景变得标准化和简单化:

文件系统访问: 通过 filesystem MCP 服务器,AI 可以读写本地文件
数据库操作: 通过 database MCP 服务器,AI 可以查询和修改数据
云服务集成: 通过 Google Drive、Slack 等 MCP 服务器,AI 可以访问云端资源
开发工具: 通过 Git MCP 服务器,AI 可以执行版本控制操作

这些能力在很多 AI 应用里会结合模型的工具调用能力一起使用,但 MCP 关注的是“应用如何把工具和上下文标准化地接给模型”,而不是替代各家模型自身的调用机制。

7.5 类比理解 MCP 与 Function Calling

概念	网络技术类比	角色
Function Calling	应用中的结构化调用能力	让模型生成工具调用
MCP	接入协议/标准	定义工具与上下文如何暴露
MCP Servers	具体服务实现	提供具体功能

或者用移动应用生态来理解:

Function calling = 手机的应用安装和运行能力
MCP = 应用商店的标准(如何打包、分发、安装应用)
MCP Servers = 商店中的各个应用

7.6 从孤立能力到开放生态

MCP 的意义在于将 function calling 从“每个项目自己实现”转变为“整个生态共享复用”:

没有 MCP:

1
2
3

项目A → 自己实现文件读取工具
项目B → 重复实现文件读取工具
项目C → 又一次实现文件读取工具

有了 MCP:

1
2
3

filesystem-mcp-server (统一实现,开源共享)
    ↓
项目A、B、C 都直接使用,无需重复开发

这种标准化让 AI 应用的开发效率大幅提升,同时也让工具质量更有保障(社区验证和维护)。

总结:从能力到生态的完整图景

核心要点

Function calling 是基础能力
- 模型通过专门训练获得的结构化调用能力
- 高可靠性来自训练优化,而非硬编码逻辑
工具模式是概率行为
- 基于训练数据形成的高概率输出模式
- 需要 API 控制、训练能力、上下文提示三者协同
MCP 是能力的标准化和生态化
- 基于 function calling 构建的应用层协议
- 解决了工具定义、发现、复用的问题
- 类似于 HTTP 之上的 RESTful 规范
技术演进的三个阶段
- 阶段1: 模型具备 function calling 能力
- 阶段2: 各家自定义工具调用格式
- 阶段3: MCP 统一标准,建立开放生态

理解层次关系至关重要

应用产品 (用户体验)
   ↓
MCP 协议 (标准化)
   ↓
Function Calling (核心能力)
   ↓
模型训练 (能力来源)

实践启示

设计工具调用时:

Schema 描述要清晰准确,这是模型理解的基础
利用 system prompt 补充使用指南和约束
实现错误处理和边界情况的降级方案
理解概率系统的特性,做好监控和兜底

采用 MCP 生态时:

优先使用成熟的 MCP 服务器,避免重复造轮子
关注权限和安全配置,保护敏感数据
开发自定义工具时遵循 MCP 规范,便于分享和维护
将工具逻辑与业务逻辑分离,提高系统可扩展性