从"只能回答"到"能调用工具"：LLM能力的演进

背景与演进

在传统的 LLM 交互中，模型只能通过自然语言与用户对话。无论用户问什么问题，LLM 都只能基于其训练数据生成文本回答——它无法真正"做"任何事情，比如查询实时天气、读取数据库、发送邮件或执行代码。

这就好比一个非常博学但行动力为零的学者：他知道一切知识，但当你让他"帮我查一下明天的航班"时，他只能告诉你"我很抱歉，我无法访问实时数据"。

Function Calling 的出现，改变了这一局面。它让 LLM 从"只能回答问题"的被动角色，变成了"能指挥工具干活"的主动指挥官。

核心比喻：

• 传统 LLM：像一台只有屏幕的电视机——只能被动显示内容
• Function Calling：给这台电视接上了遥控器——可以控制外部设备
• MCP：为所有遥控器制定了统一的标准协议

延伸阅读：

• OpenAI Function Calling Documentation - Function Calling官方文档
• Anthropic Tool Use Guide - Claude工具调用指南

Function Calling底层原理

现代大模型（如 GPT-4、Claude、Qwen-7B-Chat 等）之所以能够精准调用工具，是因为在训练阶段进行了特殊的有监督微调，使用精心构造的数据集让模型建立了"任务意图→工具选择→参数提取"的概率关联。

这一过程让模型学会：当用户意图匹配某个工具时，不再输出自然语言，而是输出特定格式的结构化数据（通常是 JSON），方便代理层解析并执行相应的服务调用。

从技术角度看，Function Calling 的实现涉及三个层面：

1. 训练层面：教会模型"填空" (SFT)

问题：模型本质上是一个概率预测器，它如何学会"当用户想预订会议室时，应该调用特定函数并提取参数"？

答案：通过有监督微调（Supervised Fine-Tuning，简称 SFT）。

训练数据构造

训练团队会构造大量高质量的「用户意图→工具调用」配对数据：

训练示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

### System:
你是一个行政助手。可用工具: [book_meeting_room(room_name, date, duration_hours)]

### User:
帮我定一下明天下午'星云阁'会议室，用 2 小时。

### Assistant:
<|thought|>
用户想要预订会议室。
参数提取：
- 会议室：星云阁
- 日期：明天（基于当前日期 2026-03-09 推算为 2026-03-10）
- 时长：2 小时
匹配工具：book_meeting_room
<|tool_call_start|>:{"name": "book_meeting_room", "arguments": {"room_name": "星云阁", "date": "2026-03-10", "duration_hours": 2}}<|tool_call_end|>

通过这样的 SFT 训练，模型学到了一种模式：当用户意图与某个工具描述匹配时，不再输出自然语言，而是输出特定标记符包裹的 JSON 结构，方便代理层解析和执行。

延伸阅读：

• Fine-Tuning Large Language Models - 有监督微调理论基础
• Instruction Tuning for Large Language Models - 指令微调研究

2. 推理层面：强制模型"守规矩" (Constrained Decoding)

问题：LLM 生成文本是概率性的，可能会生成错误的 JSON（比如缺少逗号、括号不匹配），导致代理层解析失败。

解决方法：推理引擎（如 vLLM、llama.cpp）使用约束解码（Constrained Decoding / Grammar-based Sampling）。

工作原理

实例说明

假设模型已经生成了 {"city":，按照 JSON 语法，下一个 Token 必须是字符串的开始引号 "。如果模型想要生成一个数字，推理引擎会强行把数字的概率设为 0，迫使模型只能选择符合 JSON 语法的 Token。

结果：这保证了程序后端在拿到模型输出时，可以直接用 json.loads() 解析，而不会因为格式错误（Syntax Error）导致系统崩溃。

延伸阅读：

• llama.cpp Grammar-based Sampling - 基于语法的采样实现
• Guidance: Controlling Generative Models - 输出约束控制库

3. 协议层面：完整的交互循环（The Loop）

Function Calling 不仅仅是一次请求，而是一个标准的 4 步循环协议：

核心逻辑：一个"意图 → 动作 → 结果 → 结论"的完整闭环。

重要概念： 模型本身并不具备访问互联网或执行代码的能力。它只是"提议"调用某个函数，真正的执行是由代理层业务代码（Python/Node.js 等）完成的。

实用技巧：

• 强制触发（Tool Choice）：可以通过参数 tool_choice='required' 强制模型必须调用某个工具，这在自动化流水线（Pipeline）中非常有用
• 并行调用：某些模型支持同时调用多个工具，提升执行效率

延伸阅读：

• OpenAI Parallel Function Calling - 并行函数调用
• Streaming Function Calls - 流式工具调用

MCP：模型上下文协议

除了 Function Calling，MCP（Model Context Protocol）是大模型工具调用领域另一个备受关注的核心概念。

MCP的定义

MCP，全称 Model Context Protocol，中文可译为模型上下文协议。

它由 Anthropic（Claude）在 2024 年提出，是一种 Agent 级系统协议，目标是让大模型（LLM）能够安全、受控地访问外部工具和数据源。

MCP的核心价值

与Function Calling的关系

类比理解：

• Function Calling：像是"器官"——定义了模型"如何表达"想用工具的意图
• MCP：像是"神经系统"——定义了工具和数据"如何规范地"暴露给模型，并提供统一的传输链路

简单来说，Function Calling 解决了**“模型怎么说”的问题，而 MCP 解决了“工具怎么接”**的问题。

延伸阅读： Model Context Protocol Specification - MCP官方规范文档

Function Calling 与 MCP 的协作

可以把它们的关系类比为**“乐高积木"与"乐高底板”**：

维度一：能力的标准化

维度二：连接的拓扑结构

• Function Calling（点对点）：App → 编写解析代码 → 调用具体 API
• MCP（星型拓扑）：App → MCP 控制器 → 挂载 N 个 MCP Servers（如 Postgres 服务器、Slack 服务器、GitHub 服务器）

核心比喻： MCP 是为 LLM 打造的"USB 接口标准"，让它能安全地接上各种外部设备和服务。

完整对比表

延伸阅读：

• MCP: A Standard for Connecting AI Assistants to Data - MCP 官方介绍
• Building MCP Servers - MCP 服务器开发指南

MCP 架构详解

MCP 采用基于客户端-服务器的架构，包含三个主要组件：

三大核心组件

延伸阅读：

• MCP Client Implementation Guide - MCP 客户端实现指南
• MCP Server Quick Start - MCP 服务器快速入门

MCP 工作流程

MCP 的基本步骤可以概括为三段式：注册 → 调用 → 控制：

1. 服务注册（Service Registration）

外部服务（如 Notion API、SQL 数据库、内部 CRM）通过 MCP 定义接口，声明自己能做什么（类似"菜单"）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

// 示例：一个文件系统 MCP Server 的工具声明
{
  "name": "read_file",
  "description": "读取文件内容",
  "inputSchema": {
    "type": "object",
    "properties": {
      "path": {
        "type": "string",
        "description": "文件路径"
      }
    },
    "required": ["path"]
  }
}

2. 模型调用（Invocation）

当 LLM 需要完成某个任务时，它通过 MCP 发出请求：

1
2

LLM → MCP Client → MCP Server → 实际服务
"我需要调用 filesystem.read_file 来读取配置文件"

MCP 会验证参数是否合法、调用是否安全，然后再把请求转发给实际的服务。

3. 安全控制（Control & Guardrails）

MCP 不是一个"裸奔接口"，它有一层安全护栏：

延伸阅读：

• MCP Security Considerations - MCP 安全性考量
• MCP Resource Access Control - 资源访问控制

实践建议与最佳实践

选择建议

开发流程

1. 确定需求：分析需要接入的工具和数据源
2. 选择方案：根据工具数量和复杂度决定使用 Function Calling 还是 MCP
3. 实现集成：
   • Function Calling：编写 JSON Schema 和解析逻辑
   • MCP：运行或开发对应的 MCP Server
4. 测试验证：确保参数提取准确、调用正常、结果正确
5. 监控优化：监控调用成功率、延迟和成本

延伸阅读：

• Claude MCP Integration - Claude MCP 集成指南
• Cursor MCP Setup - Cursor MCP 配置教程

学习资源推荐

官方文档与规范

• MCP Specification - MCP 协议规范
• OpenAI Function Calling Docs - OpenAI 函数调用文档
• Anthropic Tool Use Guide - Claude 工具使用指南

深度技术文章

• Fine-Tuning Large Language Models - 有监督微调研究
• Instruction Tuning for Large Language Models - 指令微调论文

视频教程

• MCP是啥？技术原理是什么？一个视频搞懂MCP的一切 - Windows系统配置MCP，Cursor、Cline使用MCP

实战教程（中文）

• MCP是什么，一篇搞懂MCP爆火的其中奥秘！ - CSDN深度解析
• 什么是MCP和A2A？一文搞懂MCP和A2A - MCP与A2A对比分析
• MCP协议是什么？MCP入门实战 - MCP实战入门

开源项目与示例

• Official MCP SDKs - MCP 官方 SDK 仓库
• MCP Servers Collection - 社区维护的 MCP Server 集合