OpenAI 早在2023年06月就推出了 Function Calling，為大模型提供了工具調(diào)用功能。Anthropic 在2024年11月推出了 MCP，旨在標(biāo)準(zhǔn)化 AI 大模型與外部工具和數(shù)據(jù)源的交互。

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

1、Function Calling 架構(gòu)設(shè)計(jì)

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

第一、工作原理

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

1.識(shí)別需求：大模型識(shí)別出用戶的問題需要調(diào)用外部 API 來獲取實(shí)時(shí)信息。比如：用戶詢問“今天北京的天氣如何？”大模型會(huì)識(shí)別出這是一個(gè)關(guān)于實(shí)時(shí)天氣的問題。

2.選擇函數(shù)：大模型從可用的函數(shù)庫中選擇合適的函數(shù)。在這個(gè)例子中，大模型會(huì)選擇 get_current_weather 函數(shù)。

3.準(zhǔn)備參數(shù)：大模型準(zhǔn)備調(diào)用函數(shù)所需的參數(shù)。例如：

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

3.調(diào)用函數(shù)：AI 應(yīng)用使用這些參數(shù)調(diào)用實(shí)際的天氣 API，獲取北京的實(shí)時(shí)天氣數(shù)據(jù)。

4.整合回答：大模型將獲取的數(shù)據(jù)整合成一個(gè)完整的回答，比如：“根據(jù)最新數(shù)據(jù)，北京今天的天氣晴朗，當(dāng)前溫度23°C，濕度45%，微風(fēng)。今天的最高溫度預(yù)計(jì)為26°C，最低溫度為18°C。”

第二、對(duì)開發(fā)者的好處

對(duì)于開發(fā)者來說，使用 LLM 的 Function Calling 入門相對(duì)容易。開發(fā)者只需按照 API 的要求定義函數(shù)規(guī)格（通常是 JSON 格式），并將其隨 Prompt 請(qǐng)求發(fā)送給大模型。大模型會(huì)根據(jù)需要調(diào)用這些函數(shù)，整個(gè)邏輯相當(dāng)直觀。因此，對(duì)于單一大模型、少量功能的簡單應(yīng)用，F(xiàn)unction Calling 的實(shí)現(xiàn)非常直接，幾乎可以“一鍵”將大模型輸出對(duì)接到代碼邏輯中。

第三、局限性

然而，F(xiàn)unction Calling 也有一些局限性：

缺乏跨大模型的一致性：每個(gè) LLM 供應(yīng)商的接口格式略有差異，這使得開發(fā)者在支持多個(gè)大模型時(shí)需要為不同的 API 做適配，或者使用額外的框架來處理這些差異。

平臺(tái)依賴性：Function Calling 通常依賴于特定的平臺(tái)或框架，這限制了其在不同環(huán)境中的通用性。

擴(kuò)展性有限：雖然 Function Calling 能夠解決特定問題，但在面對(duì)更復(fù)雜的任務(wù)時(shí)，其擴(kuò)展性可能會(huì)受到限制。開發(fā)者可能需要為每個(gè)新功能編寫新的函數(shù)，并確保這些函數(shù)與模型的交互邏輯兼容。

第四、總結(jié)

Function Calling 是一種強(qiáng)大的工具，它為大語言模型提供了與外部工具和服務(wù)交互的能力，從而解決了大模型知識(shí)更新停滯的問題。然而，它的局限性在于缺乏跨模型的一致性和平臺(tái)依賴性。盡管如此，F(xiàn)unction Calling 仍然是一個(gè)重要的技術(shù)，尤其是在需要快速實(shí)現(xiàn)特定功能時(shí)。未來，隨著技術(shù)的不斷發(fā)展，我們期待看到更多能夠克服這些局限性的解決方案。

2、MCP 架構(gòu)設(shè)計(jì)

MCP（Model Context Protocol）是由 Anthropic 公司提出的一種協(xié)議，旨在解決不同大語言模型（LLM）與不同外部工具集成的標(biāo)準(zhǔn)化問題。通過MCP，開發(fā)者能夠以一種統(tǒng)一的方式將各種數(shù)據(jù)源和工具連接到 AI 大模型，從而提升大模型的實(shí)用性和靈活性。

目前，MCP 生態(tài)已經(jīng)得到了廣泛的支持，包括 Anthropic 的 Claude 系列、OpenAI 的 GPT 系列、Meta 的 Llama 系列、DeepSeek、阿里的通義系列以及 Anysphere 的 Cursor 等主流模型均已接入 MCP 生態(tài)。

第一、MCP 的架構(gòu)設(shè)計(jì)

MCP 采用了客戶端-服務(wù)器架構(gòu)，主要包括以下幾個(gè)核心組件：

1、MCP 主機(jī)（Hosts）

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

功能：它們是MCP生態(tài)系統(tǒng)的入口點(diǎn)，負(fù)責(zé)向用戶提供AI功能，并作為用戶與AI模型之間的橋梁。

2、MCP 客戶端（Clients）

角色：這些是協(xié)議客戶端，負(fù)責(zé)維持與 MCP 服務(wù)器的1:1連接。

功能：它們處理通信細(xì)節(jié)，確保主機(jī)和服務(wù)器之間的數(shù)據(jù)傳輸順暢，從而實(shí)現(xiàn)高效的數(shù)據(jù)交互。

3、MCP 服務(wù)器（Servers）

角色：這些是輕量級(jí)程序，每個(gè)服務(wù)器都通過標(biāo)準(zhǔn)化的 Model Context Protocol 暴露特定功能。

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

4、數(shù)據(jù)源

本地?cái)?shù)據(jù)源：包括您計(jì)算機(jī)上的文件、數(shù)據(jù)庫和服務(wù)，MCP 服務(wù)器可以安全地訪問這些資源。

遠(yuǎn)程服務(wù)：通過互聯(lián)網(wǎng)可用的外部系統(tǒng)（比如：通過 API），MCP 服務(wù)器可以連接這些系統(tǒng)，從而擴(kuò)展模型的能力。

第二、MCP 的優(yōu)勢

統(tǒng)一性：MCP 提供了一個(gè)統(tǒng)一的協(xié)議標(biāo)準(zhǔn)，使得不同 AI 大模型能夠以一致的方式連接到各種數(shù)據(jù)源和工具，從而避免了平臺(tái)依賴性問題。

安全性：通過 MCP，數(shù)據(jù)的傳輸和訪問過程更加安全，敏感數(shù)據(jù)可以保留在本地，無需全部上傳到云端。

靈活性：MCP 支持多種數(shù)據(jù)源和工具的連接，無論是本地資源還是遠(yuǎn)程服務(wù)，都可以輕松集成到AI 應(yīng)用中。

生態(tài)豐富：MCP 生態(tài)已經(jīng)得到了廣泛的支持，開發(fā)者可以利用現(xiàn)有的MCP服務(wù)器和工具，快速構(gòu)建和部署AI應(yīng)用。

第三、總結(jié)

MCP 通過其客戶端-服務(wù)器架構(gòu)和標(biāo)準(zhǔn)化的協(xié)議，為 AI 大模型與外部工具和數(shù)據(jù)源的集成提供了一個(gè)高效、安全且靈活的解決方案。它不僅解決了不同大模型與工具之間的兼容性問題，還為開發(fā)者提供了一個(gè)豐富的生態(tài)系統(tǒng)，使得AI應(yīng)用的開發(fā)和部署變得更加簡單和高效。

3、MCP 和 Function Calling 架構(gòu)對(duì)比剖析

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

很多人誤認(rèn)為，MCP 是對(duì)傳統(tǒng) Function Calling 的一種替代。

而實(shí)際上，兩者并非替代關(guān)系，而是緊密合作的關(guān)系。

Function Calling 是大語言模型（LLM）與外部工具或 API 交互的核心機(jī)制。它是大模型的一個(gè)基礎(chǔ)能力，就是識(shí)別什么時(shí)候要工具，可能需要啥類型的工具的能力。

而 MCP 則是工具分類的箱子。因此 MCP 不是要取代 Function Calling，而是在 Function Calling 基礎(chǔ)上，聯(lián)合 Agent 一起去完成復(fù)雜任務(wù)。

如果把整個(gè)工具調(diào)用的流程剖析開來，實(shí)際是"Function Calling+ Agent + MCP 系統(tǒng)"的組合。

用一句話說清楚：大模型通過 FunctionCalling 表達(dá)，我要調(diào)用什么工具，Agent 遵循指令執(zhí)行工具的調(diào)用，而 MCP 則是提供了一種統(tǒng)一的工具調(diào)用規(guī)范。

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

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

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

通過區(qū)分 Function Calling 和 MCP，我們可以清晰地看出，MCP 并不負(fù)責(zé)決定使用哪個(gè)工具，也不進(jìn)行任務(wù)規(guī)劃或理解用戶意圖。這些是 Agent 層面的工作。MCP 只是提供了一個(gè)統(tǒng)一的工具接口，成為了產(chǎn)業(yè)內(nèi)認(rèn)可的工具調(diào)用標(biāo)準(zhǔn)協(xié)議。

本文轉(zhuǎn)載自??玄姐聊AGI??  作者：玄姐