MCP 和 Function Calling 架构设计对比剖析

OpenAI 早在2023年06月就推出了 Function Calling，为大模型提供了工具调用功能。Anthropic 在2024年11月推出了 MCP，旨在标准化 AI 大模型与外部工具和数据源的交互。

MCP 是否要取代 Function Calling？下文详细剖析。

—1—Function Calling 架构设计

Function Calling 是由 OpenAI 等公司推动的一种技术，它允许大语言模型（LLM）通过自然语言指令与外部工具和服务进行交互，从而将自然语言转换为具体的 API 调用。这一技术解决了大语言模型在训练完成后知识更新停滞的问题，使大模型能够获取实时信息，比如：当前的天气、股市收盘点数等。

第一、工作原理

Function Calling 的工作原理可以通过以下4个步骤来理解：

识别需求：大模型识别出用户的问题需要调用外部 API 来获取实时信息。例如：用户询问“今天北京的天气如何？”大模型会识别出这是一个关于实时天气的问题。
选择函数：大模型从可用的函数库中选择合适的函数。在这个例子中，大模型会选择 get_current_weather 函数。
准备参数：大模型准备调用函数所需的参数。例如：
```
{
"location": "北京",
"unit": "celsius"
}
```
调用函数：AI 应用使用这些参数调用实际的天气 API，获取北京的实时天气数据。
整合回答：大模型将获取的数据整合成一个完整的回答，比如：“根据最新数据，北京今天的天气晴朗，当前温度23°C，湿度45%，微风。今天的最高温度预计为26°C，最低温度为18°C。”

第二、对开发者的好处

对于开发者来说，使用 LLM 的 Function Calling 入门相对容易。

开发者只需按照 API 的要求定义函数规格（通常是 JSON 格式），并将其随 Prompt 请求发送给大模型。
大模型会根据需要调用这些函数，整个逻辑相当直观。
对于单一大模型、少量功能的简单应用，Function Calling 的实现非常直接，几乎可以“一键”将大模型输出对接到代码逻辑中。

第三、局限性

然而，Function Calling 也有一些局限性：

缺乏跨大模型的一致性：每个 LLM 供应商的接口格式略有差异，这使得开发者在支持多个大模型时需要为不同的 API 做适配，或者使用额外的框架来处理这些差异。
平台依赖性：Function Calling 通常依赖于特定的平台或框架，这限制了其在不同环境中的通用性。
扩展性有限：虽然 Function Calling 能够解决特定问题，但在面对更复杂的任务时，其扩展性可能会受到限制。开发者可能需要为每个新功能编写新的函数，并确保这些函数与模型的交互逻辑兼容。

第四、总结

Function Calling 是一种强大的工具，它为大语言模型提供了与外部工具和服务交互的能力，从而解决了大模型知识更新停滞的问题。然而，它的局限性在于缺乏跨模型的一致性和平台依赖性。尽管如此，Function Calling 仍然是一个重要的技术，尤其是在需要快速实现特定功能时。未来，随着技术的不断发展，我们期待看到更多能够克服这些局限性的解决方案。

—2—MCP 架构设计

MCP（Model Context Protocol）是由 Anthropic 公司提出的一种协议，旨在解决不同大语言模型（LLM）与不同外部工具集成的标准化问题。通过 MCP，开发者能够以一种统一的方式将各种数据源和工具连接到 AI 大模型，从而提升大模型的实用性和灵活性。

目前，MCP 生态已经得到了广泛的支持，包括 Anthropic 的 Claude 系列、OpenAI 的 GPT 系列、Meta 的 Llama 系列、DeepSeek、阿里的通义系列以及 Anysphere 的 Cursor 等主流模型均已接入 MCP 生态。

第一、MCP 的架构设计

MCP 采用了客户端-服务器架构，主要包括以下几个核心组件：

MCP 主机（Hosts）
- 角色：这是需要访问数据的程序，例如 Claude Desktop、各种 IDE 或 AI 工具。
- 功能：它们是 MCP 生态系统的入口点，负责向用户提供 AI 功能，并作为用户与 AI 模型之间的桥梁。
MCP 客户端（Clients）
- 角色：这些是协议客户端，负责维持与 MCP 服务器的 1:1 连接。
- 功能：它们处理通信细节，确保主机和服务器之间的数据传输顺畅，从而实现高效的数据交互。
MCP 服务器（Servers）
- 角色：这些是轻量级程序，每个服务器都通过标准化的 Model Context Protocol 暴露特定功能。
- 功能：服务器是 MCP 的核心，它们连接 AI 大模型与实际数据源，使模型能够访问和操作数据。
数据源
- 本地数据源：包括您计算机上的文件、数据库和服务，MCP 服务器可以安全地访问这些资源。
- 远程服务：通过互联网可用的外部系统（比如：通过 API），MCP 服务器可以连接这些系统，从而扩展模型的能力。

第二、MCP 的优势

统一性：MCP 提供了一个统一的协议标准，使得不同 AI 大模型能够以一致的方式连接到各种数据源和工具，从而避免了平台依赖性问题。
安全性：通过 MCP，数据的传输和访问过程更加安全，敏感数据可以保留在本地，无需全部上传到云端。
灵活性：MCP 支持多种数据源和工具的连接，无论是本地资源还是远程服务，都可以轻松集成到 AI 应用中。
生态丰富：MCP 生态已经得到了广泛的支持，开发者可以利用现有的 MCP 服务器和工具，快速构建和部署 AI 应用。

第三、总结

MCP 通过其客户端-服务器架构和标准化的协议，为 AI 大模型与外部工具和数据源的集成提供了一个高效、安全且灵活的解决方案。它不仅解决了不同大模型与工具之间的兼容性问题，还为开发者提供了一个丰富的生态系统，使得 AI 应用的开发和部署变得更加简单和高效。

—3—MCP 和 Function Calling 架构对比剖析

MCP 不是 Function Calling 的替代，而是基于 Function Calling 的工具箱。

很多人误认为，MCP 是对传统 Function Calling 的一种替代。而实际上，两者并非替代关系，而是紧密合作的关系。

Function Calling 是大语言模型（LLM）与外部工具或 API 交互的核心机制。它是大模型的一个基础能力，就是识别什么时候要工具，可能需要啥类型的工具的能力。
MCP 则是工具分类的箱子。

因此 MCP 不是要取代 Function Calling，而是在 Function Calling 基础上，联合 Agent 一起去完成复杂任务。

如果把整个工具调用的流程剖析开来，实际是“Function Calling + Agent + MCP 系统”的组合。

用一句话说清楚：

大模型通过 Function Calling 表达，我要调用什么工具；
Agent 遵循指令执行工具的调用；
而 MCP 则是提供了一种统一的工具调用规范。

用一个比喻来理解：

老板（用户）要喝咖啡，于是，在办公室（MCP Host）里，办公室主任（大模型）吩咐秘书（Agent）去买一杯美式（Function Calling）。
秘书（Agent）查了一下供应商名册，发现美式咖啡的供应商已接入了美团或公司统一采购系统（实现了 MCP Server），接着，秘书在采购系统中找到供应商（MCP Client）一键下单。

在过去没有 MCP 时：