从模型到MCP：一文搞懂AI工具调用的底层逻辑

MCP（Model Context Protocol，模型上下文协议）是当前AI领域热度极高的一个概念，但很多开发者对它的定位仍然模糊——知道名字，却说不清它到底解决了什么问题。本文将循着「模型是什么 → 如何使用模型 → 使用中的瓶颈 → Function Calling → MCP」这条完整链路，帮你彻底理清MCP的来龙去脉。

大模型的本质：一堆静态的权重数据

当我们从魔搭社区或Hugging Face下载一个大语言模型时，得到的其实是一堆以 .safetensors 结尾的权重文件。这些文件本质上就是海量的浮点数——它们是训练过程中沉淀下来的静态权重数据，本身并不能工作，更无法直接生成文本。

.safetensors 是由 Hugging Face 推出的一种安全、高效的模型权重存储格式，相比早期常用的 pickle 序列化格式（.bin），它避免了反序列化时可能执行任意代码的安全风险，同时支持零拷贝内存映射加载，显著提升了大模型的加载速度。一个典型的大语言模型可能包含数十亿甚至数千亿个浮点数参数，例如 LLaMA-70B 模型的权重文件总大小超过 130GB。

要让这些「死数据」活起来，就需要推理引擎。推理引擎（如 vLLM、llama.cpp、TensorRT-LLM、Ollama 等）的作用非常直接：加载权重数据到 GPU 或 CPU 内存中，接收输入文本（经过分词后的 token 序列），执行 Transformer 架构中的矩阵运算、注意力计算和采样策略，最终逐步解码输出文本。有了权重数据和推理引擎，模型就能被部署起来运行。

模型权重与推理引擎的关系

无论是部署在远程服务器还是本地电脑上，部署完成后模型都会对外暴露一个访问接口（通常是一个URL）。我们向这个接口发送数据，它在背后调用模型生成回复。但直接调接口需要传递大量参数，非常繁琐，因此实践中我们往往借助 Cherry Studio 这类 AI客户端：只需填入 API Key 完成配置，就能在图形界面里直接与模型对话。客户端会自动帮我们完成接口调用、请求发送与结果渲染。

大模型的先天局限：只会聊天的书呆子

用起来之后，一个明显的瓶颈很快浮现：让模型写诗、写文案，它游刃有余；但一旦问「明天北京天气如何」，或让它「读取本地 readme.md 文件并总结内容」，模型往往要么答非所问，要么直接胡编乱造。

原因在于大模型的核心能力仅限于接收文本和输出文本。它天生不能联网，也不具备读写本地文件、发送邮件等能力。本质上，它是一个封闭的、静态的知识系统——比如一个用2023年数据训练的模型，其知识就凝固在那个时间点。一旦问题超出训练数据的范围，模型就会频繁产生「幻觉」。

「幻觉」（Hallucination）是大语言模型领域的核心挑战之一。从技术原理来看，大模型的生成过程本质上是基于概率的下一个 token 预测——模型根据上下文计算词汇表中每个 token 的条件概率，然后采样输出。当问题涉及训练数据中未覆盖或覆盖稀疏的知识时，模型仍然会按照概率分布「自信地」生成看似合理但实际错误的内容。这是因为模型并不具备「我不知道」的可靠自我认知机制。幻觉问题催生了多种缓解方案，包括 RAG（检索增强生成）、知识图谱注入，以及本文重点讨论的 Function Calling 外部工具调用——通过获取实时真实数据来替代模型的「猜测」。

用一句话概括：大模型本身就是一个「只会聊天的书呆子」，只能基于已有知识生成文本，不能上网、读不了文件，也调用不了任何外部功能。

Function Calling：为模型装上「手脚」

为了突破这一局限，业界引入了 Function Calling（函数调用） 机制。Function Calling 最早由 OpenAI 在 2023 年 6 月随 GPT-3.5/GPT-4 API 更新正式引入，随后迅速成为行业标准。其技术实现依赖于模型在训练阶段（通常是指令微调和 RLHF 阶段）对结构化输出格式的学习——模型被训练为在识别到自身能力不足时，输出符合预定 JSON Schema 的工具调用指令，而非编造答案。如今，几乎所有主流大模型提供商（Google Gemini、Anthropic Claude、Meta LLaMA、阿里通义千问、百度文心等）都支持 Function Calling。开源社区中，通过 Hermes、Gorilla 等专门的工具调用微调数据集，也让开源模型具备了可靠的函数调用能力。

核心思路

我们预先封装好各类工具函数——比如查天气的函数、读取本地文件的函数、文档解析函数、发邮件函数等（示例中使用Python编写）。在与模型对话时，把这些工具的信息、调用方式和参数格式一并告诉模型。

这样一来，模型的输出就从「只有文本」变成了两种可能：

如果问题它能回答，直接生成文本答案；
如果问题超出能力范围，它不再瞎编，而是输出一条工具调用指令。

Function Calling的两种输出模式

工具调用指令的结构

这条指令本质上是一段 JSON。在 OpenAI 的 API 规范中，当模型决定调用工具时，返回的响应中 finish_reason 字段会被设置为 tool_calls（而非通常的 stop），同时 message 对象中会包含一个 tool_calls 数组，每个元素包含 id（调用标识符）、type（固定为 function）、function.name（函数名，如 get_weather）和 function.arguments（JSON 格式的参数字符串，如 {"city": "北京"}）。

这里有一个关键点常被误解：工具的实际调用不是由大模型完成的。模型只负责「告诉你」需要调哪个工具、传什么参数；真正执行工具函数的是客户端（如 Cherry Studio）。客户端拿到结果后，需要构造一条 role 为 tool 的消息，携带对应的 tool_call_id 和执行结果，回传给模型。模型结合这份最新信息，才能给出准确、可信的回复。这种多轮对话结构是 Function Calling 能够可靠运作的协议基础。

Function Calling的完整流程

整个流程可以概括为：

用户提问 + 工具信息 → 发送给大模型
模型判断无法回答 → 返回工具调用指令
客户端解析指令 → 调用对应工具 → 获取真实数据
客户端回传数据 → 模型生成最终答案

Function Calling完整调用流程

从Function Calling到MCP：工具服务的标准化

Function Calling 从机制上明确了「模型可以通过输出指令来扩展能力」，但它没有规定工具应该部署在哪里、如何实现。这就留下了一个关键的架构选择。

工具放内部还是外部？

放在客户端内部：工具与客户端绑定，能快速落地，但扩展性受限、难以跨应用复用。比如 Cherry Studio 内置的工具，别的客户端就用不了。

作为独立服务放在外部：灵活性和跨平台复用能力大大增强。工具作为单独服务部署后，任何客户端都能连接使用；工具可以用 Python、Go 等任意语言编写；新增或删除工具也非常方便，客户端能快速感知到工具的变化。

显然，把工具部署到外部是更优的方案。

MCP协议要解决的核心问题

但工具一旦独立到外部，客户端与工具服务就成了两个独立程序，随之而来的是通信问题：客户端如何把工具名和参数发送到服务端？服务端执行后又如何把结果回传？这些通信细节，Function Calling 并没有规定。

MCP解决客户端与工具服务的通信问题

MCP（模型上下文协议）正是为填补这一空白而生。MCP 由 Anthropic 于 2024 年 11 月正式发布并开源，采用了 JSON-RPC 2.0 作为底层消息格式，支持两种传输机制：一是基于 stdio（标准输入输出） 的本地进程通信，适用于本地工具服务（如文件系统操作、数据库查询等）；二是基于 SSE（Server-Sent Events） 的 HTTP 远程通信，适用于云端部署的工具服务。

MCP 的架构分为三个角色：

Host（宿主应用）：如 IDE 或 AI 客户端，是用户直接交互的程序；
Client（MCP 客户端）：每个 Client 与一个 Server 保持一对一连接，负责协议层面的消息收发；
Server（MCP 服务端）：提供具体的工具（Tools）、资源（Resources）和提示模板（Prompts）。

协议定义了标准方法，涵盖：

工具如何注册与发现（通过 tools/list 方法，客户端可自动获取服务端所有可用工具及其参数描述）
客户端如何发送调用请求（通过 tools/call 方法，工具名、参数按 JSON-RPC 格式打包传输）
执行结果如何返回（服务端按标准响应格式回传结果或错误信息）

有了 MCP，大模型与外部工具的连接就变得规范、统一：客户端可以通过协议自动发现服务端上所有可用工具，实现「即插即用、即连即用」。这也为构建可扩展的智能应用（AI Agent）奠定了坚实基础。

当前，MCP 的出现正值 AI Agent（智能体）概念爆发的关键节点。智能体的核心理念是让大模型不仅能对话，还能自主规划任务、调用工具、感知环境并迭代执行——这与传统的单轮问答形成了本质区别。在此背景下，工具生态的标准化变得至关重要：OpenAI 推出了 GPTs 和 Actions 机制，Google 发布了 Agent Development Kit，而 MCP 作为开放协议，正在成为跨平台工具互操作的事实标准。目前 Cursor、Windsurf、Claude Desktop、Cline 等主流 AI 应用已原生支持 MCP，GitHub 上也涌现出数千个开源 MCP Server 项目，覆盖数据库、搜索引擎、代码仓库、日历、CRM 等各类场景，形成了一个快速增长的工具市场生态。

总结：MCP是Function Calling的规范化实现

理清了这条链路，MCP 的定位就非常清晰了：

可以把 MCP 理解为 Function Calling 的一套具体、统一、被广泛认可的实现规范。

大模型只会「读写文本」，能力封闭；
Function Calling 通过让模型输出调用指令，间接扩展了模型能力；
而 MCP 进一步规定了工具的注册、调用、结果返回等通信协议，让工具服务能够标准化地对接任意客户端。

对于开发者而言，理解「模型—推理引擎—客户端—Function Calling—MCP」这条演进脉络，是构建AI应用与智能体的必备基础。下一步，就可以动手编写属于自己的 MCP 工具服务了。