在大模型应用开发领域，工具调用是实现复杂业务功能的关键技术。其中，Function calling 与 MCP（Model Context Protocol） 作为两种主流的工具调用机制，既有内在联系，也存在本质差异。本文将从零开始，带你系统性地理解这两者的核心定义、实现原理、优缺点及适用场景，帮助你快速掌握大模型工具调用的必备知识。
一、深入理解 Function calling
1. 定义与作用
Function calling 是 OpenAI 率先提出的一种让大模型识别并调用外部工具的机制。借助它，开发者可以使大模型与外部 API 实现交互，从而完成发送邮件、查询天气、检索知识库等复杂操作。在 OpenAI 后续官方文档中，该接口的入参名称已变更为 tools，因此业界也常将其统称为工具调用。你只需记住：Function calling、tools、工具调用 这几个术语本质上指向同一个概念。
2. 实现方式与代码示例
以下通过 OpenAI 官方 Python 示例演示如何定义一个获取天气信息的函数：
``` tools = [ { "type": "function", "function": { "name": "get_weather", "description": "获取指定城市的天气信息", "parameters": { "type": "object", "properties": { "city": { "type": "string", "description": "城市名称" } }, "required": ["city"] } } } ] ```调用 GPT 后，模型会返回一个 function_call 类型的响应，其中包含被调用的函数名及其参数：
小提示： 注意返回类型为
function_call而非Function calling，OpenAI 在术语命名上并未严格统一，初学者容易混淆。你只需记住：返回的 function_call 信息就是模型在告诉开发者“该调用哪个函数”以及“需要传入什么参数”。
3. 完整调用流程
后续开发者需要自行编写代码，根据 AI 返回的函数名称去执行对应的实际函数，获取结果（例如天气数据），再让 GPT 依据结果生成最终回答。整体流程可分为以下 5 个步骤：
- 步骤1： 定义工具列表并传入大模型
- 步骤2： 大模型返回
function_call（包含函数名与参数） - 步骤3： 开发者编写代码，根据函数名调用真实 API
- 步骤4： 将 API 返回的结果（如天气数据）传回给大模型
- 步骤5： 大模型基于结果生成最终的自然语言回答
可以看出，步骤1、3、4 都需要开发者自行编码实现，且每个工具或函数都需独立适配，不同厂商的 API 风格各不相同，集成工作相当繁琐。
4. 关键注意事项
- 大模型必须具备工具调用能力（依赖于训练与微调），并非所有模型都支持。例如 Coze 平台中的某些 DeepSeek 模型就不具备工具调用功能。
- Function calling 功能相对单一，一次仅执行一个任务，采用同步调用方式，缺乏上下文管理能力，生态也较为封闭。
二、深入理解 MCP（Model Context Protocol）
1. 定义与核心组成
MCP 是一套标准化的协议体系，包含服务端（Server）、客户端（Client）以及两者之间的通信规范。它封装了三大核心原语：
- 提示词（Prompts）： 由用户控制的、与服务器交互的提示信息。MCP Client 通常内置了经过优化的提示词，以获得更佳效果。
- 资源（Resources）： 每次交互涉及的上下文数据、响应信息等，统一存储在服务器中。
- 工具（Tools）： 服务端提供的可调用函数，供 LLM 使用。
从官方文档可以看出，MCP 的原语中已包含工具调用（即 Function calling），但 MCP 的核心优势在于将复杂的调用步骤封装为标准化接口，开发者只需调用 MCP SDK 即可完成任务。
2. 工作原理与调用流程
MCP 的执行流程如下：
- MCP Server 定义对外提供的工具类型及描述信息。
- 客户端通过 LLM 分析用户指令，判断需要调用哪个 MCP 服务器。
- 客户端生成固定格式的请求参数，调用 MCP Server 的
call_tool方法。 - Server 执行相应工具并返回结果。
在官方示例中，仅需一行代码即可完成工具调用：
``` result = await client.call_tool("get_weather", {"city": "Beijing"}) ```这里同样需要 LLM 的参与——让 LLM 判断用户输入应该调用哪个工具（对应 Function calling 的第一步），而后续步骤全部由 MCP 框架自动完成。开发者无需再自行编写调用逻辑。
3. MCP 的核心优势
- 功能强大： 支持多轮对话，一次可调用多个任务，支持异步执行。
- 统一标准： 所有适配 MCP 的 Server 都可以使用统一的代码进行调用，生态繁荣（目前已有 2000+ 个 MCP Servers）。
- 灵活调用方式： 既可以通过 Function calling 实现工具调用，也可以使用自然语言描述的提示词告知 LLM 可用工具，这种方式更依赖模型的语言理解能力（例如 Claude 的体验更佳）。
常见问题： 使用提示词方式存在哪些潜在问题？
答案： 传输到大模型的上下文会非常长。例如多个 MCP 同时调用时，可能消耗数十万 token。Cline 源码直接将 MCP 内容全部放入提示词，导致 token 消耗极高。
三、MCP 与 Function calling 的区别与联系
1. 一句话总结
MCP 是集提示词、上下文资源和工具调用于一体的协议，功能更强大、规范性更强；其中的工具调用既可以通过 Function calling 实现，也可以单纯依赖提示词方式完成。
2. 对比表格
| 维度 | Function calling | MCP |
|---|---|---|
| 功能定位 | 功能单一，仅负责工具调用 | 功能丰富，封装提示词、资源、工具三大原语 |
| 调用方式 | 一次只执行一个任务，同步调用 | 支持多轮对话、多任务并行、异步执行 |
| 标准化程度 | 无统一标准，需厂商或开发者自行适配 | 具备统一协议，所有 Server 可用相同代码调用 |
| 生态与社区 | 相对封闭，缺乏开源项目支撑 | 社区蓬勃发展，已有 2000+ 个 Server |
| 上下文管理 | 不具备，需开发者自行维护 | 内建资源管理，自动维护上下文 |
| 对 LLM 的要求 | 必须具备工具调用能力（需训练支持） | 可通过提示词方式调用，依赖语言理解能力，更加灵活 |
3. 架构对比图
上图清晰展示：Function calling 是“各自为战”的模式，工具直接与大模型对接；而 MCP 引入了 Client 与 Server 的标准化交互，Server 不直接与大模型通信，而是通过 Client 连接模型。
四、常见问题与解答（FAQ）
- Q：为什么有些大模型不支持 Function calling？
A：工具调用能力需要模型在训练阶段引入专用数据，并通过微调学习。因此许多旧模型或小型模型不具备此能力。例如 Coze 中的部分 DeepSeek 模型就不支持该功能。 - Q：MCP 是否必须依赖 Function calling？
A：不一定。MCP 的工具调用既可以通过 Function calling 实现，也可以借助自然语言描述（纯提示词）来完成，后者更依赖模型的语言理解能力。 - Q：使用提示词方式调用 MCP 工具会导致 token 暴增吗？
A：是的。如果同时接入多个 MCP Server，提示词中会包含大量工具描述，可能消耗数十万 token。主流客户端如 Cline 就存在这一问题。 - Q：我该选择 Function calling 还是 MCP？
A：若你只需要简单调用一两个自有 API，且希望快速开发，可以直接使用 Function calling。若你希望构建可扩展、多工具协作的系统，并享受标准化生态带来的便利，推荐选用 MCP。
五、总结
Function calling 是基础的工具调用机制，适合简单场景；MCP 则是更高级的协议化方案，将提示词、上下文与工具调用统一管理，大幅降低了开发复杂度。深入理解两者的区别与联系，能够帮助你在面对不同业务需求时做出更合理的技术选型。
小提示： 如果觉得内容偏长，可以直接回顾上方的对比表格与架构图，它们是全文的核心精华所在。