1.2 MCP是如何誕生的

1.2.1 大模型視角

2022年11月30日，OpenAI發布了ChatGPT——一款基于大模型的對話產品。ChatGPT以驚人的交互體驗迅速出圈（用戶通過自然語言對話即可完成編程、寫作、推理等復雜任務），讓“大模型”這一原本只在技術社區流傳的概念首次進入了公眾視野。業界迅速達成共識：大模型將成為下一代人機交互的核心載體。

在之后的時間里，大模型技術有了飛速發展，通過對話助手與大模型對話，逐漸成了人們上網獲取信息的主要途徑。

然而，大模型是通過歷史數據進行訓練的，這些數據在訓練時就已經固定。模型訓練完成后，其知識就停留在訓練時的狀態，無法自動獲取訓練之后的新信息。也就是說，大模型的“靜態知識”與動態世界的“實時需求”之間存在根本性矛盾。

為了突破這一矛盾，解決大模型對訓練后信息的獲取問題，行業探索出兩類主要的解決方案。

第一類：模型微調

模型微調的基本原理是在預訓練好的大模型的基礎上，使用新的數據集進行額外的訓練。通常情況下，模型的基本架構保持不變，只調整全部或者部分參數，從而使模型學習新的知識或適應特定任務。

相比從頭訓練，模型微調需要的計算資源更少，能夠更高效地實現模型的定制化。它的主要局限性在于，模型微調仍然是一個“先訓練后部署”的方案，雖然在解決某些專業領域問題時補充了新知識，但不適用于對時效性要求高的場景，比如獲取實時新聞、天氣信息等。

第二類：上下文補充

上下文補充指的是為大模型提供外部知識庫或信息源的技術方案，旨在讓大模型突破知識的時效性限制，能夠訪問專業領域信息，從而提高回答的準確性、時效性和可靠性。

與模型微調不同，上下文補充不需要改變模型參數重新訓練，而是在模型生成回答時實時提供相關信息作為輸入上下文，讓模型能夠基于這些最新的信息進行推理。基于補充的上下文信息，大模型能夠回答與訓練之后發生的事件相關的問題，彌補靜態知識與動態世界之間的鴻溝。

MCP的核心在于C，也就是上下文（Context），從這個角度來看，MCP誕生的初衷就是給大模型補充上下文。

在MCP之前，行業存在如下幾種為大模型補充上下文的主流方案。

1. 記憶存儲

記憶存儲通常由大模型客戶端實現。客戶端會將用戶與大模型的每輪對話內容記錄下來，并設定一定的記憶容量。當用戶提出新問題時，系統會從記憶庫中提取與當前對話相關的信息，作為補充上下文提供給大模型，從而使模型的回答更加連貫，就像賦予了模型“記憶”能力。

不過，這種記憶機制也存在一定的局限性，模型的“記憶”能力主要受限于大模型支持的上下文長度。如果每次都將同一個會話的全部歷史內容傳入模型，容易因上下文窗口限制而導致信息截斷；而若僅選取與當前問題相關的歷史內容，則對客戶端的實現能力提出了更高的要求，需要依賴相似度匹配等技術來篩選最相關的信息。

2. RAG

RAG（retrieval-augmented generation，檢索增強生成）是一種讓大模型獲取實時信息的重要技術，其工作原理是：當用戶發出提問時，AI應用通過向量檢索、關鍵詞匹配等方式，從外部知識庫或數據源檢索相關信息，再把檢索到的信息作為上下文提供給大模型，讓大模型基于補充的信息進行回答。

RAG的交互流程如圖1-5所示。

RAG技術的主要優勢是：不需要重新訓練模型（成本低）；可以靈活更新知識庫（保持信息的新鮮度）。因此，RAG可以用于聯網查詢實時信息、跟本地文檔（知識庫）對話等場景。

RAG技術的局限性在于：大模型的最終回答效果依賴于檢索到的信息質量。因此，檢索步驟非常關鍵，需要基于高效、準確的檢索算法和優質的數據源，而在實際應用中，這兩點往往很難同時滿足。

3. 函數調用

函數調用（function calling）是一種讓大模型執行特定任務的機制，允許大模型將自然語言請求轉換為具體的函數調用，供AI應用調用外部工具，并將結果反饋給用戶。

函數調用的工作原理是：當用戶發出提問時，AI應用會將集成的函數列表作為上下文發送給大模型。大模型根據用戶輸入判斷具體調用的函數，并生成相應的調用參數。隨后，AI應用執行該函數并將結果發送給大模型，作為補充信息供其生成最終的總結或回答。

函數調用的交互流程如圖1-6所示。

函數調用擴大了大模型的能力邊界，通過函數調用的方式，大模型既能外掛各種類型的數據，也能執行各種類型的操作。

自OpenAI于2023年6月首次在其GPT系列模型中支持函數調用機制以來，各大模型廠商紛紛跟進，函數調用已經成為大模型外掛數據的標配。

然而，17個月之后，MCP出現了。

4. MCP

我們可以認為，MCP是在函數調用的基礎上做了進一步的升級和抽象，目的是讓AI應用更加簡單、高效、安全地對接外部資源，更好地為大模型補充上下文信息。因此，接下來我們用對比講解函數調用和MCP的方式來了解MCP。

函數調用是一種交互范式，其本質是一種設計模式，定義了AI應用與外部函數的調用規范。

從用戶視角看，函數調用的交互流程涉及三個角色：AI應用、函數、大模型；核心交互流程涉及兩大核心步驟：函數選擇和函數調用。

函數選擇：AI應用把函數列表和用戶提問發送給大模型，大模型識別用戶意圖，挑選最適合的函數來滿足用戶需求。

函數調用：應用通過大模型返回的函數名稱和參數，調用函數獲取外部數據。

圖1-6已經介紹了函數調用的交互流程，此處不再贅述。

MCP是一套通信協議，其本質是為AI應用與外部工具交互而制定的標準化接口規范、數據格式和通信契約。

MCP定義了三個角色：MCP主機、MCP客戶端、MCP服務器。跟函數調用相比，MCP相當于是把“MCP客戶端-MCP服務器”作為一個黑盒使用。

從用戶視角看，MCP的交互流程也涉及三個角色：AI應用、黑盒（MCP客戶端MCP服務器）、大模型。MCP的交互流程（以調用工具為例）如下所示（注意，只提及了核心步驟）。

AI應用把用戶提問發送給黑盒中的MCP客戶端。

黑盒中的客戶端請求黑盒中的MCP服務器，獲取MCP服務器定義的工具列表。

AI應用把工具列表和用戶提問發送給大模型，由大模型進行工具選擇。

AI應用根據大模型返回的工具調用參數，通過黑盒中的MCP客戶端，向黑盒中的MCP服務器發起工具調用請求。

黑盒中的MCP服務器請求外部數據或服務，將結果返回給MCP客戶端。

AI應用得到黑盒返回的外部數據，作為上下文信息發送給大模型生成回答。

可以用一幅圖概括MCP的交互流程，如圖1-7所示。