MCP:AI大模型的萬能插座
最近一直在做數據+AI方向的工作,前兩天無意中看到一個MCP的技術,經過詳細的學習之后,了解到這個可能不僅僅應用在大模型,而更多是數據和模型之間的橋梁,最近就一直在考慮對于多模態(tài)數據如何才能實打實的和應用模型結合起來的事情,MCP無疑是提供了某種思路,下面是關于MCP的一些介紹,部分內容是參考的社區(qū)文檔。
MCP(Model Context Protocol) 是一種開放協(xié)議,它標準化了應用向設備提供上下文的方式。可以將 MCP 想象成 AI 應用的 USB-C 端口。正如 USB-C 提供了一種標準化的方式將您的設備連接到各種外圍設備和配件一樣,MCP 也提供了一種標準化的方式將 AI 模型連接到不同的數據源和工具。
首先來說說為什么會有MCP,隨著AI大模型和人工智能助手的快速發(fā)展,很多企業(yè)都在往AI方向轉型,定制和自身業(yè)務相關聯(lián)的AI應用,投入巨資在模型的推理和訓練上,然而,即便是再厲害的大模型、即便是再強大的預訓練模型,也會因為和業(yè)務數據隔離而受到限制,等于模型和數據是被困在各自的信息孤島中。
如果我們要接入企業(yè)內部的數據源,則需要單獨來定制實現數據源的連接,這對于很多企業(yè)有大量不同數據源的系統(tǒng)來說,工作量非常大,二者對于整個系統(tǒng)后續(xù)都難以擴展。
所以,MCP提供了一項開放標準,使開發(fā)者能夠在數據源和AI驅動的工具之間建立安全的雙向連接。MCP的架構簡單易懂,開發(fā)者可以通過MCP服務器來公開訪問,也可以構建連接到這些服務器的AI應用中(也就是MCP的客戶端)。
下面來看看一個關于MCP的使用示意圖:
假如我們有M個不同的AI應用(例如聊天問答、RAG知識庫等等)和N個不同的服務系統(tǒng)(內部數據庫、聊天數據等等),那么可能需要構建M*N個不同的API來集成,這會導致維護復雜度很高,以及團隊之間的重復工作。
MCP其實就是希望將M*N的問題,轉換為M+N的問題,我們需要構建N個MCP的Server端,然后應用程序客戶端構建M個MCP 客戶端,MCP是一個Client/Server的架構,有如下幾個角色說明:
- Hosts:與用戶交互的應用程序(例如,Claude Desktop、類似 Cursor 的 IDE、自定義代理)。
- Clients:位于主機應用程序中,管理與特定 MCP 服務器的連接。保持 1:1 的連接。
- Servers:通過客戶端通過標準 API 向 AI 模型公開工具、資源和提示的外部程序。
其中,MCP Server端的組件包括:
1. Tools(模型控制): 這些是可以調用來執(zhí)行特定操作的函數(工具),例如天氣 API,基本上是函數調用
2. Resources(應用控制): 這些是可以訪問的數據源,類似于 REST API 中的 GET 端點。資源提供數據時無需執(zhí)行大量計算,不會產生任何副作用。上下文/請求的一部分
3. 提示(用戶控制):這些是預定義的模板,用于以最佳方式使用工具或資源。在運行推理可以進行選擇
MCP是怎么運行的?
MCP 采用前面描述的客戶端-服務器模型運行。以下是簡化的流程:
1. Initialization(初始化): 當主機應用程序啟動時,它會創(chuàng)建 N 個 MCP 客戶端,它們通過握手交換有關功能和協(xié)議版本的信息。
2. Discovery(發(fā)現): 客戶端請求服務器提供哪些功能(工具、資源、提示)。服務器返回列表和描述。
3. Context Provision(提供上下文): 主機應用現在可以向用戶提供資源和提示,或將工具解析為兼容格式,例如 JSON 函數調用
4. Invocation(調用): 如果確定需要使用工具(例如,根據用戶請求“‘X’ 存儲庫中有哪些未解決的問題?”),主機會指示客戶端向相應的服務器發(fā)送調用請求。
5. Execution(執(zhí)行): 服務器接收請求(例如,使用 repo 'X' 的 fetch_github_issues),執(zhí)行底層邏輯(調用 GitHub API),并獲取結果。
6. Response(響應): 服務器將結果發(fā)送回客戶端。
7. Completion(完成): 客戶端將結果中繼到主機,主機將其合并到LLM的上下文中,從而允許LLM根據最新的外部信息為用戶生成最終響應。
MCP 是一個標準框架,它定義了 AI 系統(tǒng)如何與外部工具、服務和數據源交互。MCP 無需為每個服務創(chuàng)建自定義集成,而是定義了這些服務如何互操作、請求如何構建、哪些功能可用以及如何發(fā)現這些功能等基本概念。它使開發(fā)者能夠輕松可靠地在 AI 工具與外部數據源、應用和其他服務之間構建安全可靠的雙向連接。
MCP Server是 MCP 世界與外部系統(tǒng)特定功能(例如 API、數據庫、本地文件等)之間的橋梁/API。它們本質上是根據 MCP 規(guī)范暴露這些外部功能的包裝器。
只要服務器能夠通過支持的傳輸協(xié)議進行通信,就可以使用各種語言(Python、TypeScript、Java、Rust 等)構建服務器。服務器主要通過兩種方式與客戶端通信:
- stdio(標準輸入/輸出): 當客戶端和服務器在同一臺機器上運行時使用。這對于本地集成(例如訪問本地文件或運行本地腳本)來說簡單有效。
- 通過 SSE(服務器發(fā)送事件)的 HTTP: 客戶端通過 HTTP 連接到服務器。初始設置后,服務器可以使用 SSE 標準通過長連接向客戶端推送消息(事件)。
MCP 解決的什么問題?
人工智能工具的實用性取決于它們能夠訪問的數據和能夠采取的行動。
AI人工智能將來應用到實際中場景中的時候,更多的特征還是取決于它們能夠訪問的數據以及針對訪問到的數據所作出的行動。
對于通用性的能力,LLM的預訓練數據就足夠了,但是,牽扯到讓AI了解公司內部的業(yè)務數據,例如銷售額與上季度相比變化,競爭對手的營銷策略如何根據市場狀況做出調整。
如果希望AI利用這些信息執(zhí)行某些操作的話,我們就需要一種方式讓它與這些應用程序進行交互,MCP就是這樣一種程序,通過提供標準化的方式來發(fā)現和調用外部系統(tǒng)中的操作,簡化了這一過程。它彌合了理解與執(zhí)行之間的差距,因此 AI 不僅僅是提供洞察,還能積極地完成任務。
以前,這意味著你需要為每個想要獲取洞察或采取行動的應用構建自定義集成。而 MCP 則為 AI 工具如何與任何數據源交互提供了標準化解決方案。任何支持 MCP 的應用都能夠提供一套結構化的工具或操作,供 AI 助手或代理使用。當你要求 AI 執(zhí)行某項操作時,它可以檢查可用的工具并采取適當的操作——靈活性大大提升。
通過使用安全協(xié)議標準化 AI 模型與外部數據源之間的通信,MCP 使開發(fā)人員能夠更快、更輕松地與關鍵工具構建安全集成,并且也使開發(fā)人員能夠更輕松地在不同工具之間切換。例如,兩個不同的文件存儲應用應該具有類似的 MCP 服務器實現,而無需編寫全新的集成代碼。
MCP 和 AI Agent的區(qū)別
AI Agent是由人工智能驅動的工具,能夠自主行動。舉個簡單的例子, ChatGPT、 DeepSeek 能夠根據我們的查詢決定執(zhí)行哪些網絡搜索以及訪問哪些網站,我們可以告訴它想要什么,但它決定如何為我們提供服務。
MCP 能夠實現Agent行為。通過允許開發(fā)者將應用程序和數據源連接到 AI 助手,他們可以構建能夠自主決策并在其他應用程序中采取行動的 AI 工具。但 MCP 并非構建 AI 代理的唯一方法,使用 MCP 也不會自動將任何 AI 驅動的工具變成 AI Agent。它只是將 AI 連接到另一個工具的一種方式。
MCP 主要面向構建自定義集成和 AI 應用程序的開發(fā)者,尤其適合擁有技術資源、需要在自己的應用程序或工作流程中構建專用 AI 功能的團隊。
這兩種方法在生態(tài)系統(tǒng)中都有其地位:MCP 為開發(fā)人員提供了更深層次的控制和自定義實現的靈活性,而無代碼工具則為沒有大量開發(fā)資源的業(yè)務用戶或團隊提供了可訪問性和速度。
本文轉載自??DataForA??I,作者:易程Date
