“ 智能體應用是大模型應用的一個重點方式，而怎么才能做出一個合格的智能體是很多人都在考慮的問題。”

對大模型有過了解的人應該都知道，大模型應用目前主要還處于探索階段，而關于大模型應用的技術也是日新月異，在不斷持續的發展。

而關于大模型的應用目前的主要形式是聊天，然后通過大模型的自身能力去完成一些工作；比如生成內容，總結文檔等。但我們對大模型的期待要遠遠高于簡單的聊天，我們需要的是大模型根據我們的指令去完成具體的任務。

但大模型本身又沒有使用外部工具的能力，因此openai就提出了一項新的技術-Function call，通過Function call大模型就能實現使用外部工具的能力，而這能大大提升大模型的能力范圍，使得大模型能夠真正解決實際問題。

但是Function call也有很多缺陷，比如說沒有統一的標準，接口實現復雜；因此最近一段時間爆火的MCP就出現了。

MCP本質上是一種協議，類似于互聯網界的Http協議，硬件中的USB-C接口，它提供一個統一的標準，讓大模型能夠使用統一的方式去使用外部工具，這樣就可以大大提升效率，加快大模型應用的發展。

協議本質上是一種標準，大家都按照統一的標準進行設計和開發，這樣就可以節省大量的時間和成本，提升效率。

當然，MCP協議雖然說類似于HTTP協議和USB-C標準，但到底能不能真正成為大模型領域的標準還有待商榷。

MCP協議

MCP協議采用的還是經典的C-S架構，主要由客戶端和服務端組成；只不過在MCP協議中，有了更多的概念，而其核心概念主要有三個——Host，Client和Server。

其工作流程如下，以找電腦上的文件為例：

1. Host：Claude Desktop 作為 Host，負責接收你的提問并與 Claude 模型交互。
2. Client：當 Claude 模型決定需要訪問你的文件系統時，Host 中內置的 MCP Client 會被激活。這個 Client 負責與適當的 MCP Server 建立連接。
3. Server：在這個例子中，文件系統 MCP Server 會被調用。它負責執行實際的文件掃描操作，訪問你的桌面目錄，并返回找到的文檔列表。

整個流程是這樣的：你的問題 → Claude Desktop(Host) → Claude 模型 → 需要文件信息 → MCP Client 連接 → 文件系統 MCP Server → 執行操作 → 返回結果 → Claude 生成回答 → 顯示在 Claude Desktop 上。

這種架構設計使得 Claude 可以在不同場景下靈活調用各種工具和數據源，而開發者只需專注于開發對應的 MCP Server，無需關心 Host 和 Client 的實現細節。

這里關于Client和Server都很好理解，可能很多人有疑問的是Host和Client之間的關系。

其實，Host和Cllient的關系很好理解；簡單來說就類似于我們自己的電腦，Host電腦的系統，我們使用電腦寫文章，刷網頁，看視頻等等；而Client就是我們的網卡，我們需要進行網絡請求的時候就通過網卡(Client)去調用外部服務獲取數據，然后再在電腦中顯示。

但這里有一個問題就是，我們使用電腦使用什么工具，什么時候使用這些工具，是由我們用戶決定的；但在MCP中，使用什么工具和怎么使用這些工具，是由大模型自己理解用戶的意圖之后，然后決定使用哪些工具。

而這一步事實上是根據Prompt engineering提示詞工程來實現的；簡單來說就是通過JSON或其它格式的數據按照MCP的客戶端要求進行約束，然后根據這些描述來決定怎么使用這些工具；本質上就是一個Schema。

當然，由于MCP采用的是C-S架構，因此網絡通訊也成了其必不可少的一環；而在MCP的網絡通訊中主要使用了兩種協議：

1. stdio standard input/output 標準輸入輸出 適用于本地調用

2. SSE Server-sent events 服務端推送協議

通過這兩種協議就可以實現MCP客戶端與服務端的通訊能力。

MCP協議現在還無法完全取代Function call的功能，而且Function call的能力也在不斷升級，因此最后鹿死誰手還不太好說。

本文轉載自公眾號AI探索時代 作者：DFires

原文鏈接：??https://mp.weixin.qq.com/s/TjKysHt1L3QgFhmWgGGTew??