OpenAI 早在2023年06月就推出了 Function Calling，為大模型提供了工具調用功能。Anthropic 在2024年11月推出了 MCP，旨在標準化 AI 大模型與外部工具和數據源的交互。

MCP 是否要取代 Function Calling？下文詳細剖析。

1、Function Calling 架構設計

Function Calling 是由 OpenAI 等公司推動的一種技術，它允許大語言模型（LLM）通過自然語言指令與外部工具和服務進行交互，從而將自然語言轉換為具體的 API 調用。這一技術解決了大語言模型在訓練完成后知識更新停滯的問題，使大模型能夠獲取實時信息，比如：當前的天氣、股市收盤點數等。

第一、工作原理

Function Calling 的工作原理可以通過以下4個步驟來理解：

1.識別需求：大模型識別出用戶的問題需要調用外部 API 來獲取實時信息。比如：用戶詢問“今天北京的天氣如何？”大模型會識別出這是一個關于實時天氣的問題。

2.選擇函數：大模型從可用的函數庫中選擇合適的函數。在這個例子中，大模型會選擇 get_current_weather 函數。

3.準備參數：大模型準備調用函數所需的參數。例如：

{
  "location": "北京",
  "unit": "celsius"
}

3.調用函數：AI 應用使用這些參數調用實際的天氣 API，獲取北京的實時天氣數據。

4.整合回答：大模型將獲取的數據整合成一個完整的回答，比如：“根據最新數據，北京今天的天氣晴朗，當前溫度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 采用了客戶端-服務器架構，主要包括以下幾個核心組件：

1、MCP 主機（Hosts）

角色：這是需要訪問數據的程序，例如Claude Desktop、各種IDE或AI工具。

功能：它們是MCP生態系統的入口點，負責向用戶提供AI功能，并作為用戶與AI模型之間的橋梁。

2、MCP 客戶端（Clients）

角色：這些是協議客戶端，負責維持與 MCP 服務器的1:1連接。

功能：它們處理通信細節，確保主機和服務器之間的數據傳輸順暢，從而實現高效的數據交互。

3、MCP 服務器（Servers）

角色：這些是輕量級程序，每個服務器都通過標準化的 Model Context Protocol 暴露特定功能。

功能：服務器是 MCP 的核心，它們連接 AI 大模型與實際數據源，使模型能夠訪問和操作數據。

4、數據源

本地數據源：包括您計算機上的文件、數據庫和服務，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 系統"的組合。

用一句話說清楚：大模型通過 FunctionCalling 表達，我要調用什么工具，Agent 遵循指令執行工具的調用，而 MCP 則是提供了一種統一的工具調用規范。

用一個比喻來理解：老板（用戶）要喝咖啡，于是，在辦公室（MCP Host）里，辦公室主任（大模型）吩咐秘書（Agent）去買一杯美式（Function Calling）。秘書（Agent）查了一下供應商名冊，發現美式咖啡的供應商已接入了美團或公司統一采購系統（實現了 MCP Server），接著，秘書在采購系統中找到供應商（MCP Client）一鍵下單。

在過去沒有 MCP 時，大模型下發 Function Calling，Agent 去執行翻譯，直接連接到 API 去調用工具。因此，你得為每個 API 單獨設置對應的調用模式，去單獨定義工具列表和調用模式，這樣 Agent 才知道怎么去翻譯。而有了 MCP 后，只是很多 API 都可以直接通過供應商 MCP Client 一鍵下單了，Agent 省力了。但大模型的 Function Calling 沒有任何變化。還是{tool: “買加啡”, "type": "美式"}這個形式。

不過在過去，有人會把這一整套 Function Calling + Agent +API的模式叫做一個 Function Calling，所以會引起混淆。

通過區分 Function Calling 和 MCP，我們可以清晰地看出，MCP 并不負責決定使用哪個工具，也不進行任務規劃或理解用戶意圖。這些是 Agent 層面的工作。MCP 只是提供了一個統一的工具接口，成為了產業內認可的工具調用標準協議。

本文轉載自??玄姐聊AGI??  作者：玄姐