暑期檔電影票房突破 50 億元，長(zhǎng)安的荔枝、南京照相館、東極島，你最想去看哪個(gè)？哪部適合帶孩子去看？
通過(guò)MCP，AI模型能夠以統(tǒng)一的方式訪問(wèn)資源和工具，從而實(shí)現(xiàn)更高效、更智能的交互體驗(yàn)。本文將詳細(xì)解讀MCP的工作原理、傳輸機(jī)制及其在實(shí)際應(yīng)用中的優(yōu)勢(shì)，幫助讀者更好地理解這一創(chuàng)新技術(shù)如何推動(dòng)AI從簡(jiǎn)單的聊天工具邁向真正的智能代理。
現(xiàn)如今，人工智能（AI）和大語(yǔ)言模型（LLM）越來(lái)越聰明，甚至接近了人類的智慧水平。但如果它們只能利用自身已有的數(shù)據(jù)，無(wú)法獲取外界實(shí)時(shí)信息或者調(diào)用外部工具（在線詞典、天氣、地圖等），那么它們的能力就會(huì)被大大的限制。比如用戶問(wèn)，今天哪家公司股票漲幅最大？由于缺少實(shí)時(shí)數(shù)據(jù)和工具支持，再?gòu)?qiáng)大的AI也無(wú)法給出滿意的答案。
在沒(méi)有MCP之前智能體都是如何做的呢？
這里引入兩個(gè)概念：
大模型
大模型（LargeLanguageModel，LLM）是一種基于深度學(xué)習(xí)技術(shù)的人工智能模型，具有龐大的參數(shù)量和強(qiáng)大的學(xué)習(xí)能力，能夠理解、生成自然語(yǔ)言文本，并執(zhí)行多種復(fù)雜任務(wù)。
大模型在MCP協(xié)議出現(xiàn)之前已經(jīng)經(jīng)歷了兩個(gè)階段：
第一個(gè)階段：基于訓(xùn)練數(shù)據(jù)相對(duì)封閉階段
最初大模型（GPT、Claude等）本質(zhì)上是基于海量數(shù)據(jù)訓(xùn)練的下一個(gè)詞的預(yù)測(cè)器（Nexttokenprediction）。用戶輸入一個(gè)問(wèn)題，大模型通過(guò)一個(gè)詞一個(gè)詞最大概率出現(xiàn)的方式去給到用戶輸出。他們是基于概率的預(yù)測(cè)，也意味著大模型并不是真的理解用戶的意思，而是基于概率預(yù)測(cè)。因此會(huì)經(jīng)常會(huì)出現(xiàn)一些幻覺(jué)（一本正經(jīng)的胡說(shuō)八道）。這個(gè)時(shí)期的大模型是孤立存在的，沒(méi)有接收任何的外部信息。
第二階段：LLM+context上下文輸入給大模型階段
比如現(xiàn)在的deepseek、豆包、GPT、Kimi等，他們都有一個(gè)選項(xiàng)叫做聯(lián)網(wǎng)搜索，這個(gè)就是網(wǎng)絡(luò)的上下文。
短期記憶：模型的上下文對(duì)話記錄
長(zhǎng)期記憶：像RAG知識(shí)庫(kù)。這些都是在給模型提供有力的上下文支撐。
現(xiàn)在以人造機(jī)器人舉例，這個(gè)機(jī)器人姑且叫它張三。大模型就相當(dāng)于張三的大腦，具備智力，可以和我們進(jìn)行對(duì)話。
智能體
張三具備人類的大腦，可惜只能跟我們聊天，手腳發(fā)育還不完全，別的事情做不了。為了讓張三具備更多的能力，經(jīng)過(guò)學(xué)習(xí)研究，大家終于為張三安上了假肢（FunctionCall)。張三可以借助假肢來(lái)使用一些簡(jiǎn)單的工具。
Functioncalling沒(méi)有統(tǒng)一的標(biāo)準(zhǔn)，每家大廠的API定義都不一樣。調(diào)用工具時(shí)，每個(gè)工具都要單獨(dú)的適配，每個(gè)鏈接都需要去定制代碼、去寫特定性的服務(wù)、去處理權(quán)限、去管理格式、來(lái)保證足夠的兼容性。最后就會(huì)導(dǎo)致這整個(gè)系統(tǒng)非常的復(fù)雜。極難去維護(hù)、極難去規(guī)模化。
就像由于假肢是后面才做的，張三的大腦還不知道如何使用，因此，大家為張三量身打造了一些工具（函數(shù)、插件），可以理解為“筆”、“菜刀”，并且把工具的使用方法寫成詳細(xì)的說(shuō)明書(shū)（提示詞）存儲(chǔ)到假肢的芯片中。
并且告訴張三，以后我讓你干活的時(shí)候，你可以先讀取一下假肢里的說(shuō)明書(shū)，看看都需要調(diào)用哪些工具。
比如，讓我們告訴張三：請(qǐng)幫我們切個(gè)菜，他首先會(huì)拿出使用說(shuō)明書(shū)看一下，找找他現(xiàn)在已有的工具中可以使用來(lái)做這件事的工具。
像這樣，擁有了工具使用能力的機(jī)器人（大模型）我們就稱它為智能體了。所以說(shuō)智能體最核心的特點(diǎn)，就是具備工具調(diào)用的能力。
后來(lái)，大家做出了更多的大模型，比如又來(lái)了個(gè)李四（豆包）、王五（DeepSeek）……為了更加高效的組織和管理這些人呢，有人就創(chuàng)建了公司A（Coze、Dify等），將張三、李四、王五都招了進(jìn)來(lái)，并且專門制定了一套公司的工具使用制度（各自匹配的Functioncall)，還專門給張三、李四、王五配上了許多干活的工具（插件）。
這樣，這家公司A就就開(kāi)始給大家提供各種各樣的服務(wù)，給大家干各種各樣的任務(wù)了。
可是有一天，有人建立了公司B，想把張三、李四和王五等人挖進(jìn)來(lái)，但是公司A的制度和工具肯定不會(huì)給B對(duì)吧？于是為了讓張三、李四和王五工作，公司B也只能重新研發(fā)工具使用制度和配備相關(guān)的工具（插件）。
那么現(xiàn)在問(wèn)題來(lái)了，明明是同樣的工具，公司A和公司B沒(méi)法通用。
更夸張的是，有個(gè)人之前都是在公司A雇傭張三干活，還專門給他做了工具，但是現(xiàn)在這個(gè)人覺(jué)得公司A的費(fèi)用太貴了，想找公司B，但是之前工具都在放在公司A那里根本拿不過(guò)來(lái)，更別說(shuō)遷移使用了，只能重新再做。
后來(lái)這個(gè)人想，干脆不找公司A或者公司B了，我單獨(dú)雇傭張三來(lái)幫我干活（自己部署大模型研發(fā)智能體），自己還是要專門給他配個(gè)工具。
就這樣，重復(fù)做了好多事，浪費(fèi)了很多資源。
如何讓他們安全、高效地與外部資源和工具進(jìn)行交互，就成了一個(gè)亟待解決的核心問(wèn)題。
一、MCP應(yīng)運(yùn)而生
因?yàn)榍懊嬗龅降膯?wèn)題，于是終于有人Claude母公司（Anthropic公司）制定了一個(gè)標(biāo)準(zhǔn)–MCP
MCP（全稱是ModelContextProtocol,即模型上下文協(xié)議）
從它的名稱上我們就可以看出，MCP不是一個(gè)產(chǎn)品、不是一個(gè)應(yīng)用，也不是一個(gè)APISDK，而是一個(gè)協(xié)議。它的目標(biāo)是希望任何一個(gè)AI的模型（Chatgpt、Claude、deepseek等）都能夠以一個(gè)統(tǒng)一的方式去訪問(wèn)資源和工具。
任何你希望模型能知道、能用、能調(diào)用的內(nèi)容主要分為兩塊
資源（resources）：數(shù)據(jù)庫(kù)、API、第三方的saas等
工具（tools）：天氣、地圖、在線詞典、日歷、郵件、執(zhí)行命令、遠(yuǎn)程控制等等；
這些資源和工具是讓模型變得真的能干活的關(guān)鍵。
二、MCP是如何工作的呢？
AI客戶端：就像你手機(jī)里的ChatGPT/豆包App，是和AI聊天、發(fā)指令的“入口”，就是把一些含糊不清的自然語(yǔ)言轉(zhuǎn)化成一個(gè)明確的意圖。比如用戶要發(fā)一封郵件，我要看日歷。這種明確的意圖。
STDIO：理解成“信息快遞站”，負(fù)責(zé)把AI說(shuō)的話、要干的事兒，打包發(fā)給后面的“服務(wù)器”
MCPServer：用戶意圖就會(huì)這些請(qǐng)求就會(huì)發(fā)給MCPserver（能力適配器）。MCPserver就負(fù)責(zé)和外部的系統(tǒng)通信，比如郵箱、日歷、地圖等等。并且會(huì)聲明出它提供的工具或者資源。把它們當(dāng)“AI管家團(tuán)隊(duì)”，A管家對(duì)接高德地圖、B管家對(duì)接日歷、C管家對(duì)接Github，分工幫AI跑腿干活。
比如用戶要發(fā)一封郵件，我要看日歷，這些請(qǐng)求就會(huì)發(fā)給MCPserver（能力適配器），MCPserver就負(fù)責(zé)和外部的系統(tǒng)通信，比如郵箱、日歷、地圖等等。并且會(huì)聲明出它提供工具或者資源。
比如Gmail的MCPserver它可以去發(fā)郵件、接收郵件，寫郵件。
一個(gè)Calendarserver，可以去設(shè)置日歷、創(chuàng)建日歷提醒等
一個(gè)GithubServer可能會(huì)執(zhí)行代碼的審查、代碼編寫等。
這些Server都實(shí)現(xiàn)了一個(gè)統(tǒng)一的協(xié)議，支持通過(guò)http、Json、或者通過(guò)本地輸入輸出的方式去跟MCP的Client進(jìn)行通信。
再舉一個(gè)更加實(shí)際的例子：
比如我發(fā)出請(qǐng)求說(shuō)，幫我約小七老師這周日一起去健身，并發(fā)一個(gè)郵件給她提醒。
仔細(xì)拆解這個(gè)請(qǐng)求，其實(shí)包含著兩個(gè)任務(wù)，第一個(gè)任務(wù)是去找到我和小七老師周日都有空閑的時(shí)間段。第二個(gè)任務(wù)是去創(chuàng)建一個(gè)日程提醒并發(fā)送郵件給小七老師。
那么AI應(yīng)用作為一個(gè)MCP的Client，會(huì)先向系統(tǒng)中已經(jīng)注冊(cè)的MCPserver去查詢它的能力列表。比如是不是可以訪問(wèn)日歷，是不是有權(quán)限去發(fā)郵件，是不是能獲取到小七老師的聯(lián)系人信息？
這些能力的聲明和用戶的請(qǐng)求一并去交給大語(yǔ)言模型去處理。
模型基于給定的上下文，去判斷我應(yīng)該怎么整合現(xiàn)有的工具去完成任務(wù)。
比如決策后發(fā)現(xiàn)：
第一步：我先從Calendarserver里面去找我和小七老師都空閑的時(shí)間段
第二步：決定最終的健身時(shí)間
第三步：調(diào)用Emailserver去發(fā)郵件
第四步：可能還會(huì)提問(wèn)用戶，是不是還要叫上其他好友？整個(gè)流程非常的清晰標(biāo)準(zhǔn)化、邏輯也是閉環(huán)的，關(guān)鍵是你不需要為每個(gè)流程去寫死一個(gè)邏輯，模型也不需要提前訓(xùn)練才知道每個(gè)API
只要MCPserver有這個(gè)能力的聲明，模型就能夠動(dòng)態(tài)的發(fā)現(xiàn)、調(diào)用、并且執(zhí)行。
三、MCP常用的幾種傳輸機(jī)制有哪些呢？
MCP提供了幾種不同的“溝通方式”（傳輸機(jī)制），最受關(guān)注的是以下三種：Stdio、SSE、StreamableHTTP，他們就像不同的交通工具，各有優(yōu)缺點(diǎn)，適用于不同的“路況”（應(yīng)用場(chǎng)景）。理解他們的差異，正是為AI應(yīng)用挑選最佳交互方式、充分釋放其潛力的關(guān)鍵所在。下面我們來(lái)詳細(xì)了解這三種協(xié)議及其優(yōu)缺點(diǎn)。
1.Stdio協(xié)議
1）通信原理
Stdio（StandardInput/Output，標(biāo)準(zhǔn)輸入/輸出）協(xié)議，是基于操作系統(tǒng)提供的標(biāo)準(zhǔn)輸入輸出機(jī)制實(shí)現(xiàn)的一種數(shù)據(jù)傳輸方式。在很多編程環(huán)境和系統(tǒng)交互中，Stdio作為基礎(chǔ)的數(shù)據(jù)交互通道，承擔(dān)著數(shù)據(jù)輸入與輸出的基礎(chǔ)功能。
例如在常見(jiàn)的命令行程序中，用戶通過(guò)標(biāo)準(zhǔn)輸入向程序傳遞指令和數(shù)據(jù)，程序則通過(guò)標(biāo)準(zhǔn)輸出返回處理結(jié)果。
2）核心優(yōu)勢(shì)
通用性和易用性：幾乎所有的操作系統(tǒng)和編程語(yǔ)言都原生支持標(biāo)準(zhǔn)輸入輸出，開(kāi)發(fā)者無(wú)需額外配置復(fù)雜的網(wǎng)絡(luò)環(huán)境或引入特定的庫(kù)文件，就能快速實(shí)現(xiàn)數(shù)據(jù)的傳輸與交互，大大降低了開(kāi)發(fā)門檻；
低延遲效率高：進(jìn)程間通過(guò)標(biāo)準(zhǔn)輸入輸出進(jìn)行數(shù)據(jù)交換，直接通過(guò)內(nèi)存或者內(nèi)部管道傳輸，能夠?qū)崿F(xiàn)快速、高效的協(xié)作；
高安全性：數(shù)據(jù)只在你的電腦內(nèi)部傳輸，不會(huì)流到外面去，隱私安全方面有保障。
3）局限性
傳輸效率相對(duì)較低，在處理大量數(shù)據(jù)時(shí)，頻繁的輸入輸出操作容易成為性能瓶頸。無(wú)法同時(shí)處理多個(gè)請(qǐng)求，不適合大規(guī)模應(yīng)用；
限定于本地只能在同一臺(tái)電腦上使用，無(wú)法滿足遠(yuǎn)程數(shù)據(jù)交互的需求（訪問(wèn)不了其他電腦或者云端資源）
4）適用場(chǎng)景
本地小工具集成、處理個(gè)人隱私數(shù)據(jù)、快速做功能Demo看效果等。
2.SSE協(xié)議
1）通信原理
SSE（Server-SentEvents，服務(wù)器發(fā)送事件）協(xié)議是一種基于HTTP協(xié)議的單向數(shù)據(jù)傳輸協(xié)議，由服務(wù)器主動(dòng)向客戶端推送數(shù)據(jù)。
在Web應(yīng)用中，SSE常用于實(shí)現(xiàn)實(shí)時(shí)數(shù)據(jù)更新功能，如股票行情的實(shí)時(shí)展示、新聞動(dòng)態(tài)的即時(shí)推送等。服務(wù)器端可以隨時(shí)將新的數(shù)據(jù)變化推送給客戶端，而不需要客戶端頻繁地向服務(wù)器發(fā)起請(qǐng)求，有效降低了客戶端與服務(wù)器之間的交互壓力。
2）核心優(yōu)勢(shì)
實(shí)時(shí)性：實(shí)現(xiàn)了服務(wù)器端的主動(dòng)推送，能夠快速將最新數(shù)據(jù)傳遞給客戶端，極大地提升了數(shù)據(jù)的實(shí)時(shí)性，為用戶帶來(lái)更加流暢的實(shí)時(shí)交互體驗(yàn)；
穩(wěn)定性好：SSE基于HTTP協(xié)議，在網(wǎng)絡(luò)兼容性方面表現(xiàn)良好，能夠輕松穿越各種網(wǎng)絡(luò)代理和防火墻，保證數(shù)據(jù)傳輸?shù)姆€(wěn)定性；
支持遠(yuǎn)程訪問(wèn)：可以連接不在同一臺(tái)電腦上的服務(wù)器，適合分布式系統(tǒng)；
實(shí)現(xiàn)簡(jiǎn)單，開(kāi)發(fā)成本較低，對(duì)于只需要服務(wù)器向客戶端單向推送數(shù)據(jù)的場(chǎng)景，是一種高效的解決方案。
3）局限性
單向傳輸協(xié)議，客戶端無(wú)法主動(dòng)向服務(wù)器發(fā)送數(shù)據(jù)，這限制了其在雙向交互場(chǎng)景中的應(yīng)用。
服務(wù)器壓力大：需要一直建立連接，如果有多個(gè)客戶端，服務(wù)器負(fù)擔(dān)過(guò)重；
兼容問(wèn)題：對(duì)瀏覽器的兼容性存在一定差異，在一些老舊瀏覽器中可能無(wú)法正常使用；
即將“淘汰”：官方覺(jué)得有更好的替換方案，準(zhǔn)備用下面要講的第三種StreamableHTTP來(lái)代替。
4）適用場(chǎng)景
適用于需要服務(wù)器實(shí)時(shí)推送通知到客戶端的遠(yuǎn)程服務(wù)器。
3.StreamableHTTP協(xié)議
1）通信原理
StreamableHTTP協(xié)議是一種基于HTTP協(xié)議的流式傳輸協(xié)議，它允許數(shù)據(jù)以流的形式在客戶端和服務(wù)器之間傳輸，而不需要一次性將所有數(shù)據(jù)加載完成。在視頻流播放、音頻在線收聽(tīng)等場(chǎng)景中，StreamableHTTP協(xié)議發(fā)揮著核心作用。用戶無(wú)需等待整個(gè)媒體文件下載完成，就可以開(kāi)始播放內(nèi)容，大大提高了用戶體驗(yàn)。
2）核心優(yōu)勢(shì)
流式傳輸靈活性高：能夠顯著提升數(shù)據(jù)傳輸?shù)男屎陀脩趔w驗(yàn)，對(duì)于大文件或持續(xù)產(chǎn)生的數(shù)據(jù)，采用流式傳輸可以避免因等待數(shù)據(jù)全部傳輸完成而造成的長(zhǎng)時(shí)間延遲，實(shí)現(xiàn)數(shù)據(jù)的邊傳輸邊處理。
穩(wěn)定性好，基于廣泛使用的HTTP協(xié)議，具備良好的網(wǎng)絡(luò)適應(yīng)性和跨平臺(tái)性，無(wú)論是在Web應(yīng)用還是移動(dòng)應(yīng)用中，都能穩(wěn)定運(yùn)行。
兼容性好：能很好地配合API網(wǎng)關(guān)、CDN（內(nèi)容分發(fā)網(wǎng)絡(luò)）、負(fù)載均衡器等現(xiàn)代網(wǎng)絡(luò)設(shè)施一起工作。
3）局限性
網(wǎng)絡(luò)環(huán)境的依賴性較高：在網(wǎng)絡(luò)不穩(wěn)定的情況下，可能會(huì)出現(xiàn)卡頓、緩沖等問(wèn)題，影響數(shù)據(jù)的連續(xù)性和流暢性。
稍復(fù)雜：由于數(shù)據(jù)是按流傳輸，在數(shù)據(jù)完整性校驗(yàn)和錯(cuò)誤恢復(fù)方面相對(duì)復(fù)雜，一旦出現(xiàn)數(shù)據(jù)丟失或錯(cuò)誤，修復(fù)難度較大，可能需要開(kāi)發(fā)者自己多做一些努力。
4）適用場(chǎng)景
StreamableHTTP協(xié)議憑借其靈活高效的數(shù)據(jù)傳輸特性，成為云函數(shù)（比如AWSLambda）、需要根據(jù)負(fù)載自動(dòng)伸縮的分布式系統(tǒng)以及無(wú)狀態(tài)服務(wù)架構(gòu)等場(chǎng)景中遠(yuǎn)程通信的理想選擇。
4.對(duì)比總結(jié)
選擇建議
只在自己電腦上使用？建議用Stdio，簡(jiǎn)單直接；
需要連接遠(yuǎn)程服務(wù)器？直接用StreamableHTTP，擁抱未來(lái)，避免以后還要改代碼，維護(hù)起來(lái)更麻煩。
5.推薦幾個(gè)MCP市場(chǎng)給大家
https://www.pulsemcp.com
https://smithery.ai
https://cursor.directory/mcp
https://bailian.console.aliyun.com/?tab=mcp#/mcp-market
https://tcb.cloud.tencent.com/mcp-server
總結(jié)
最后，咱們來(lái)總結(jié)一下，MCP從根本上重構(gòu)了AI的整個(gè)應(yīng)用架構(gòu)。真正把AI從Chatbox階段推進(jìn)到了AIAgent階段。它不僅僅是一個(gè)方便的工具接入接口，他是一個(gè)全新的協(xié)議標(biāo)準(zhǔn)，正在重構(gòu)AI和世界的交互方式。它讓我們真的做到了從人使用AI生成文字、圖片、視頻到AI自主使工具和資源的新范式。
題圖來(lái)自Unsplash，基于CC0協(xié)議
該文觀點(diǎn)僅代表作者本人，人人都是產(chǎn)品經(jīng)理平臺(tái)僅提供信息存儲(chǔ)空間服務(wù)
《嫡女為謀:重生之傾世毒妃》這一世她只為復(fù)仇而生!
《嫡女為謀,重生之傾世毒妃》惜敗,她的這部作品,驚艷上榜!
《嫡女為謀:重生之傾世毒妃》她不做賢妻誓做毒婦,看誰(shuí)斗得過(guò)誰(shuí)
