在 AI 領(lǐng)域，MCP（模型上下文協(xié)議）和 plugin（插件）是兩個熱門概念，但它們之間存在本質(zhì)區(qū)別。本文將深入探討 MCP 協(xié)議的定義、功能和使用方法，對比其與 plugin 的差異，并結(jié)合實際案例展示如何通過阿里云百煉平臺使用 MCP 服務(wù)。

最近AI領(lǐng)域的最熱門的應(yīng)該可以說得MCP協(xié)議了，從年初到現(xiàn)在，我的媒介矩陣已經(jīng)被MCP這個話題包圍了，從抖音到知乎，所有的技術(shù)博主都在談?wù)揗CP協(xié)議，雖然起初我真的很想把它叫做買彩票（MCP，沒別的意思）。

從Google trend來看，最近24個月內(nèi)，尤其是在2025年之后，有關(guān)MCP的話題搜索量幾乎直線上升，名副其實的話題之王。

不過，從區(qū)域來看，在全球搜索國家來看，我國地區(qū)是關(guān)注MCP協(xié)議人數(shù)最多的，完勝其他國家和地區(qū)，單從下方這個圖標來看，我?guī)缀醺杏X不到其他國家有在研究這玩意，這會把Google整成百度來用了。

一、MCP是什么？

那言歸正傳，什么是MCP協(xié)議呢？

MCP（Model Context Protocol，模型上下文協(xié)議）是由 Anthropic 提出并于 2024 年 11 月開源的一種通信協(xié)議，旨在解決大型語言模型（LLM）與外部數(shù)據(jù)源及工具之間無縫集成的需求。

它通過標準化 AI 系統(tǒng)與數(shù)據(jù)源的交互方式，幫助模型獲取更豐富的上下文信息，從而生成更準確、更相關(guān)的響應(yīng)。

通俗來說，MCP 協(xié)議就像是設(shè)備之間溝通的 “語言規(guī)則”，規(guī)定了不同設(shè)備或程序之間如何 “聽懂” 對方的話、如何傳遞信息。比如你和朋友聊天，需要用同一種語言（比如中文），還要遵守一定的表達順序（比如先說你好，再說事情），這樣才能互相理解。

B 端产品经理如何快速成长？

产品与业务架构主要是将整个业务工作流进行分层，梳理，然后抽象出一个个需求，将业务需求与产品合情合理的映射起来，最终使业务数据在产品中流动，执行，记录，使用。

查看详情 >

MCP 協(xié)議就是給機器、軟件、設(shè)備定下的一套類似的 “溝通規(guī)則”，讓它們能按照統(tǒng)一的方式發(fā)送和接收信息，避免 “雞同鴨講”。

這樣說你可能還是不懂，于是我們就再舉一個例子，來加深一下理解

假設(shè)你家有一個 智能燈泡 和一個控制它的 手機 APP，它們之間需要通信才能實現(xiàn) “用手機開關(guān)燈” 的功能。

沒有協(xié)議時：

手機想讓燈泡開燈，可能會發(fā)一條消息：“喂，開一下！” 但燈泡可能聽不懂，因為它不知道 “喂” 是不是開頭、“開一下” 具體是什么指令，也不知道該怎么回復(fù)手機 “我已經(jīng)開了”。就像你對一個只會說英語的人說中文，對方完全懵圈。

有了 MCP 協(xié)議后：

MCP 協(xié)議提前規(guī)定好了：

• 消息格式：必須以 “[指令]” 開頭，比如 “[開燈]”“[關(guān)燈]”，后面跟著設(shè)備編號（比如 “燈 – 001”）。
• 回應(yīng)規(guī)則：燈泡收到指令后，必須回復(fù) “[狀態(tài)] + 結(jié)果”，比如 “[已執(zhí)行] 燈 – 001 已打開”。
• 錯誤處理：如果燈泡沒電了，要回復(fù) “[錯誤] 電量不足”，讓手機知道哪里出了問題。

這樣一來，手機和燈泡就像用同一種 “語言” 對話，每一條消息都符合 MCP 協(xié)議的規(guī)則，雙方都能準確理解對方的意思，不會出錯。

二、基于MCP可以做什么？

讀到這的用戶可能會有一些疑惑，這不就是plugin嗎？

是，但又不是

說它不是，是因為它和plugin有著本質(zhì)的區(qū)別

MCP本質(zhì)是模型與工具的通用交互標準。以高德地圖為例，MCP 將高德的 API（如地點搜索、路徑規(guī)劃）封裝為符合 MCP 協(xié)議的服務(wù)，通過統(tǒng)一的 JSON Schema 定義輸入輸出格式。這種標準化設(shè)計使得：

跨模型兼容：無論是通義千問、Claude 還是 GPT，只要支持 MCP 協(xié)議，均可直接調(diào)用高德的 MCP 服務(wù)，無需單獨適配。

多步任務(wù)調(diào)度：MCP 支持復(fù)雜任務(wù)鏈的自動執(zhí)行。例如，用戶只需輸入 “規(guī)劃從杭州西湖到靈隱寺的騎行路線并預(yù)估時間”，MCP 服務(wù)會自動完成地點解析、路徑規(guī)劃、實時路況查詢等多步操作，而無需手動拆分任務(wù)。

動態(tài)上下文管理：MCP 服務(wù)在調(diào)用過程中可攜帶上下文信息（如用戶的歷史搜索記錄），提升任務(wù)連貫性。例如，用戶連續(xù)查詢 “附近的咖啡館” 和 “推薦其中評分最高的”，MCP 服務(wù)能自動關(guān)聯(lián)兩次請求的上下文。

而plugin本質(zhì)是：

廠商為特定模型設(shè)計的專有接口，例如高德為通義千問開發(fā)的插件。主要核心特點是：

• 模型綁定：插件通常僅支持特定模型（如通義千問），無法直接在其他模型中復(fù)用。例如，高德的插件需要在通義千問的生態(tài)中通過 API Key 認證才能使用。
• 單次調(diào)用邏輯：插件的功能通常以單次函數(shù)調(diào)用的形式實現(xiàn)。例如，用戶需要分別觸發(fā) “搜索地點” 和 “規(guī)劃路線” 兩個插件，而無法通過一個請求完成多步任務(wù)。
• 靜態(tài)配置依賴：插件的參數(shù)和功能通常在開發(fā)時固定，難以動態(tài)調(diào)整。例如，插件可能無法自動適配不同城市的交通規(guī)則變化

總結(jié)起來說

你要是用MCP，你可以更加開放、更加豐富、更加簡單，但是plugin不會，它是暫時、封閉和復(fù)雜的

比如，以開發(fā)成本來說，傳統(tǒng)plugin想要開發(fā)的話，需針對特定模型編寫代碼。例如，高德的插件需使用通義千問的 SDK，實現(xiàn)插件的注冊、參數(shù)解析和結(jié)果返回等邏輯。而且通常需要處理模型的認證和授權(quán)等等。

但是前者MCP，卻是低代碼幾乎是零代碼就能使用，比如，阿里云百煉這兩剛發(fā)布的MCP服務(wù)，用戶只需通過簡單配置即可接入高德的 MCP 服務(wù)，無需編寫代碼。例如，用戶可在百煉廣場直接開通高德的 MCP 服務(wù)，并通過拖拽操作將其集成到 Agent 流程中，而且，MCP 服務(wù)由平臺托管，開發(fā)者無需關(guān)心服務(wù)器部署、負載均衡等問題，省了不少麻煩。

這還只是從成本和效率來說，從跨模態(tài)和功能任務(wù)上還有更多的區(qū)別。

其實，AI一定會從成本和效率來打破僵局的，這里分享一句喬布斯的話，任何復(fù)雜的事物都不會永存。在AI時代，同樣也是，你想一想以前我們想要讓模型或者agent接入一個插件，其開發(fā)成本和維護成本先不談，質(zhì)量和穩(wěn)定性更是一個難題，很多時候，插件幾乎不能用，能用又不能適配模型

因此，這里面有一個潛在的需求又或者是趨勢，不僅僅是現(xiàn)在的傳統(tǒng)行業(yè)或者是互聯(lián)網(wǎng)行業(yè)，哪怕是AI行業(yè)，太過于復(fù)雜的、低效率的產(chǎn)品都一定會被AI所替代。

比如視頻剪輯、圖片編輯，工廠流水線、包括有些工作流的編排等等，都有被代替的風險，因為它本質(zhì)上是一種RPA，缺少足夠的創(chuàng)意，還會耗費大量的時間和人力成本。

如果真的可以實現(xiàn)，我們?nèi)祟惪梢园褧r間多花費在創(chuàng)造力上面，那將會很不同！

就功能變現(xiàn)和使用場景來說，它真的和plugin沒什么區(qū)別，如果非要找不同的話，只能說確實很方便，很快，比如，

只需要一件部署就能使用MCP服務(wù)，包括一些國外的軟件，像perplexity啥都可以用。

另外，如果沒有自己想要的MCP，我們可以隨意增加MCP服務(wù)，操作也不會太復(fù)雜，這里后文會講到。

緊接著，我們需要上手試一下這一次阿里云發(fā)布的MCP協(xié)議服務(wù)，這應(yīng)該是國內(nèi)第一家發(fā)布的MCP服務(wù)，雖說沒有MCP.so.com早，但是也還算及時，算是彌補了這一塊缺陷，畢竟整天都都講著理論不談實操，肯定是沒用的。

阿里自從開過年之后，在AI上面的進步真的有目共睹，感覺隔兩天就是發(fā)布一個新模型或者一個新產(chǎn)品。前段時間，據(jù)傳阿里所有部門都要AI化，這是打算從電商巨頭轉(zhuǎn)向AI公司了。

三、MCP如何用

話不多少，開始實操

首先，你需要打開阿里云，沒有注冊過的需要先注冊一下，網(wǎng)址在這里：https://cn.aliyun.com/

當然你也可以直接打開阿里云百煉，都是一樣的，我習慣用第一種方法。

在阿里云首頁里，找到模型，然后找到AI應(yīng)用構(gòu)建–MCP服務(wù)，目前官方已經(jīng)標識出來了，可以直接看到

不過這里阿里是把云百煉的模型和應(yīng)用分開了，原因可能是以前放在一塊的時候，功能太多，現(xiàn)在分為子母界面了，反而會更方便。

點擊之后，可以直接進入MCP中心了，下面只要是你能看到的，都是接入服務(wù)的，這里我們還是直接使用高德地圖，然后點擊開通，然后就已經(jīng)成功開通這個服務(wù)了。

但是，這里有一個問題，就是很多國外的軟件它是需要API的，比如perplexity，你想要登錄使用獲取密鑰的話，你就需要魔法，但是這一步得看緣分了

這里就引出了第一個問題，MCP服務(wù)應(yīng)該更加豐富才行，否則就會很雞肋，效果肯定不如插件好，你想想，如果你能的內(nèi)存是256g的，但是你手機商店里面只有10個軟件，其中還是一些外國的，你還用不了，這事你找誰說理去？

接著，目前很多MCP服務(wù)都是互相支持開通的，但是有些服務(wù)商不愿意接入的話，人家萬一不愿意配合，那也很麻煩，所以后續(xù)的更新可能還需要不斷的磨合，這里面也有非技術(shù)因素在影響。

然后，我們需要配置一個MCP服務(wù)了，阿里云是提供了兩個選擇，一個是應(yīng)用支持，一個是工作流支持，之間用coze或者dify的用戶，肯定都知道這是什么東西，不熟悉的話，他們也在文檔里面給了操作步驟和使用手冊，在云百煉的界面里面就能找到。

我這里就用了應(yīng)用簡單搭建一個MCP服務(wù)，這一大堆界面可以不用管，直接點擊技能，里面的MCP，把剛才的高德接入進去就行

人設(shè)和回復(fù)邏輯，大家自行填寫，我只是為了方便，其實你不寫也完全沒事，因為你MCP就使用了一個，模版的話我放在下面：

##你是一個路線規(guī)劃助手

##技能

當用戶問你路線問題的時候，你需要調(diào)用MCP服務(wù)來幫助解決問題

##限制

對于非路線或者地圖的問題，不需要回復(fù)

這里有一個注意的點：

就是模型的選擇是有限制的，第一，阿里云是提供了信任免費的額度的，很多模型基本上都是可以免費試用的

第二，要想使用MCP服務(wù)的話，就使用默認的模型，deepseek是不支持的，這里我用的是通義的max32k

然后這幾件事弄好，你就可以使用了，我問了幾個關(guān)于地圖的問題，大概就是：

• q：幫我計劃一下從杭州奧體到西湖的最佳路線
• q：幫我看看此刻西湖附近的交通情況
• q：哪種交通方式從奧體去西湖最佳？
• ………

首先從回答來看，其實還是不錯的，基本上你問它一些的交通問題，它也都能回答上來，但是肯定不如你直接去使用高德效果好的。

另外，它好像不能完全實現(xiàn)實時的數(shù)據(jù)接入，比如，我問它現(xiàn)在的西湖交通情況如何，它回答不了，我一開始以為是我prompt不準確的問題，然后我又確定了一下時間，幾時幾分，但是它還是回答不出來

最后，你可以自己添加MCP服務(wù)，操作也不復(fù)雜，肯定要比plugin簡單的多，就是下面幾個步驟，然后想用別的服務(wù)的話，比如perplexity或者notion AI啥的，你需要調(diào)用API，就自行使用了

結(jié)論就是：現(xiàn)在的MCP服務(wù)基本上其實和plugin沒有什么差別，甚至有些功能不如后者，雖然我不想潑冷水，但這也是沒有辦法的事情，它確實一個趨勢，但是現(xiàn)在要想為其成為通用agent那種模式，可能還差得很遠。

就比如，性能和延遲問題，實時應(yīng)用（如自動駕駛）需毫秒級響應(yīng)，而 MCP 調(diào)用遠程 API 可能引入數(shù)百毫秒延遲。例如，車聯(lián)網(wǎng)場景中，MCP 調(diào)用天氣 API 的延遲可能影響路線規(guī)劃的實時性。

又或者，在生態(tài)方面， 工具覆蓋不全：現(xiàn)有 MCP 工具集中在通用領(lǐng)域（如天氣、地圖），垂直行業(yè)（如半導(dǎo)體制造設(shè)備控制）的專用工具較少。

寫這篇文章的時候，Google也剛剛推出了A2A協(xié)議，一言以蔽之，是想讓多個agent之間進行互相合作而誕生的一種協(xié)議，如果這么解釋還不清楚，你可以簡單的理解為，一群agent在開會。

而MCP解決的是，工具調(diào)用的問題，二者肯定有差別，但是方向是一樣的，那就是，都是在朝著通用agent而前進，彌補現(xiàn)在agent單一、抽象、行動不足等的缺點。

但是，有總比沒有好

一個優(yōu)秀的作品往往都是從0開始，然后慢慢改進的，就像一篇文章一樣，先寫，寫出來一坨垃圾，再慢慢改。