最新中文字幕一区二区乱码,91精品国产自产91精品,中文字幕国产精品

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í)信息，比如：當(dāng)前的天氣、股市收盤點(diǎn)數(shù)等。

第一、工作原理

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

識別需求：大模型識別出用戶的問題需要調(diào)用外部 API 來獲取實(shí)時(shí)信息。例如：用戶詢問“今天北京的天氣如何？”大模型會(huì)識別出這是一個(gè)關(guān)于實(shí)時(shí)天氣的問題。
選擇函數(shù)：大模型從可用的函數(shù)庫中選擇合適的函數(shù)。在這個(gè)例子中，大模型會(huì)選擇 get_current_weather 函數(shù)。
準(zhǔn)備參數(shù)：大模型準(zhǔn)備調(diào)用函數(shù)所需的參數(shù)。例如：
```
{
"location":?"北京",
"unit":?"celsius"
}
```
調(diào)用函數(shù)：AI 應(yīng)用使用這些參數(shù)調(diào)用實(shí)際的天氣 API，獲取北京的實(shí)時(shí)天氣數(shù)據(jù)。
整合回答：大模型將獲取的數(shù)據(jù)整合成一個(gè)完整的回答，比如：“根據(jù)最新數(shù)據(jù)，北京今天的天氣晴朗，當(dāng)前溫度23°C，濕度45%，微風(fēng)。今天的最高溫度預(yù)計(jì)為26°C，最低溫度為18°C。”

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

對于開發(fā)者來說，使用 LLM 的 Function Calling 入門相對容易。

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

第三、局限性

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

缺乏跨大模型的一致性：每個(gè) LLM 供應(yīng)商的接口格式略有差異，這使得開發(fā)者在支持多個(gè)大模型時(shí)需要為不同的 API 做適配，或者使用額外的框架來處理這些差異。
平臺(tái)依賴性：Function Calling 通常依賴于特定的平臺(tái)或框架，這限制了其在不同環(huán)境中的通用性。
擴(kuò)展性有限：雖然 Function Calling 能夠解決特定問題，但在面對更復(fù)雜的任務(wù)時(shí)，其擴(kuò)展性可能會(huì)受到限制。開發(fā)者可能需要為每個(gè)新功能編寫新的函數(shù)，并確保這些函數(shù)與模型的交互邏輯兼容。

第四、總結(jié)

Function Calling 是一種強(qiáng)大的工具，它為大語言模型提供了與外部工具和服務(wù)交互的能力，從而解決了大模型知識更新停滯的問題。然而，它的局限性在于缺乏跨模型的一致性和平臺(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è)核心組件：

MCP 主機(jī)（Hosts）
- 角色：這是需要訪問數(shù)據(jù)的程序，例如 Claude Desktop、各種 IDE 或 AI 工具。
- 功能：它們是 MCP 生態(tài)系統(tǒng)的入口點(diǎn)，負(fù)責(zé)向用戶提供 AI 功能，并作為用戶與 AI 模型之間的橋梁。
MCP 客戶端（Clients）
- 角色：這些是協(xié)議客戶端，負(fù)責(zé)維持與 MCP 服務(wù)器的 1:1 連接。
- 功能：它們處理通信細(xì)節(jié)，確保主機(jī)和服務(wù)器之間的數(shù)據(jù)傳輸順暢，從而實(shí)現(xiàn)高效的數(shù)據(jù)交互。
MCP 服務(wù)器（Servers）
- 角色：這些是輕量級程序，每個(gè)服務(wù)器都通過標(biāo)準(zhǔn)化的 Model Context Protocol 暴露特定功能。
- 功能：服務(wù)器是 MCP 的核心，它們連接 AI 大模型與實(shí)際數(shù)據(jù)源，使模型能夠訪問和操作數(shù)據(jù)。
數(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)對比剖析

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

很多人誤認(rèn)為，MCP 是對傳統(tǒng) Function Calling 的一種替代。而實(shí)際上，兩者并非替代關(guān)系，而是緊密合作的關(guān)系。

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

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

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

用一句話說清楚：

大模型通過 Function Calling 表達(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è)置對應(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)載自：https://mp.weixin.qq.com/s/-9VgvTPPe75IPEjlr5vYzQ