是時候去問CTO了，咱的AI產品要不要封裝MCP？

原創：楊薈博士（Istari企業智能創始人），親愛的數據（譚婧）

第一節，當下是智能體蠻荒時期，

為什么MCP協議火了？

大家對智能體的好感，

被Manus這種操作電腦的智能體，

加了一把柴火。

還有深度研究（DeepResearch），

這種擅長信息檢索、匯總、推理、

定性定量分析的智能體產品，

也帶了好頭，

好產品起到示范作用，帶動智能體概念。

進而帶動MCP討論熱度。

當然，反對的聲音也很大，

觀點1.
兩個月后就有更好的模型出現，
我們不應該在“腳手架”上花更多時間精力。
觀點2.
現在的模型已經能讀懂API文檔了，
能生成調用API的代碼了，
為啥還要出來個MCP？
觀點3.
人來操作API都有信息安全問題，
何況智能體？
觀點4.
MCP出來大半年了，
大的服務商沒有幾個真的為它適配。

對待垃圾產品應該一致吐槽，

真正有價值的東西，

表面看似吐槽，本質是辯論：

為什么MCP如此重要？

先講個好理解的，

都知道，數據對大模型非常重要，

除了已經“喂給”模型的數據，

推理時，訪問到外部的數據也非常重要，

但唯一是“喂進去訓練”這個形式嗎？

肯定不是。

但是外面接入數據哪里那么容易。

且不只數據，文件，工具，

往大了說某個系統的能力，

都可以“接入”給大模型。

“接入”的本質是“集成”，

當下有關AI的集成高度碎片化，

這是一件極為糟糕的事情。

各界人士只要想讓AI有個好發展，好前程，

都想讓局面有個根本型的改變。

MCP應運而出，

而且會在這個方向上迅速迭代。

任何開放協議之類的東西天然受到開源社區歡迎，

后面我們還會介紹。

Anthropic公司推出MCP，

確實為模型發展“計深遠”，

OpenAI緊跟而上，

也顯示了其胸懷。

北美AI模型的兩架馬車，

均拿出了態度和行動。

現在真有點，

且看下回分解的味道了。

我回想起了漢尼拔的那句名言：

“要么我找到路，要么我開辟路。”

前面4個觀點后文均有反駁。

還有一個有趣的問題，

誰在研究MCP？

第一波人鐵定是程序員，

程序員是API最直接的“消費者”，

而第二波關心的MCP人才更關鍵——

創業公司創始人，產品負責人，技術負責人。

因為他們得決定一件事——

“我的AI產品要不要也用MCP？”

第二節：MCP是啥？

MCP，全稱Model Context Protocol。

模型上下文協議，

熱門詞匯，

不能慢一步。

吃瓜最前線，

若想挖得深，

“USB插頭”“橋梁”，

這種比喻就潦草了。

“MCP是啥”這個問題，

我也問了GPT，千問，豆包不少問題，

MCP這個話題，

幻覺程度前所未有，高達50%。

看來對于互聯網上還沒有形成定論的新興事物，

大模型也似懂非懂。

最好理解兩樣東西：

1.API

2.智能體

在MCP出現之前，

早期的技術協議已經做了類似的工作，

本質上，協議解決了軟件之間的連接。

API定義了軟件之間如何通信，

智能體想“看”地圖，

不用再造一套地圖服務，

人家高德導航做得已經很好了：

1路線規劃與導航

2實時交通信息

3位置搜索

4地點詳情查詢

5公共交通查詢

6打車服務對接

7停車場查詢與導航

8天氣與環境信息

9吃喝玩樂推薦

10周邊公共交通工具推薦

那想“調用”高德導航里某種服務怎么辦？

以前是APP之間調用，

比如：滴滴打車可用高德實時交通信息優化路線，

只是一個比方，其實滴滴并不舍得這筆費用，

滴滴有自己的地圖部門，

我認識他們部門的算法小哥哥，

怎么說呢，滴滴地圖的服務一言難盡……

話說回來，

對開發者來說，高德是一套功能。

對智能體來說，高德里的信息，功能，它都需要，

高德是智能體的“工具”，

也是MCP Server，

MCP官網說了，

有三種MCP Server。

第三節，API為何不夠用，非要MCP？

從某個角度講，

雖然MCP是Anthropic公司推出的，

近期也得到了OpenAI公司的支持，

但要成為行業通行的標準，

它還需要贏得多方支持：

終端用戶，開發者，傳統軟件工具，線上服務平臺。

每個利益相關方都有自己的訴求，

比如，開發者希望減少開發工作量，

MCP的設計天然考慮了開發者的訴求。

有請楊薈博士給“觀點2”一個硬核反駁：

最大的原因是，如果讓模型自己讀API的話，

理解和執行的能力千差萬別。

因為API寫的人，寫的方式也千差萬別。

用MCP的方式能讓智能體更容易的理解API怎么調用。降低了工作難度，降低了出錯的可能性，提高了可靠性。

智能體需要調用APP的功能，

但是APP的類型太多了，

訴求也各不相同。

有些是偏純工具，希望被使用。

比如高德。

值得注意，

這時候，高德和智能體比起來，

高德“權力”更大。

是高德允許智能體查路線、算距離，

是高德允許智能體使用它的API功能，

兼容MCP是高德“做出”動作配合AI，

把這些功能“變成一種MCP服務“，發布出去，

這樣，智能體才能來“調用”。

我們稱高德為MCP Server，

能被智能體調用。

此刻，你會問，不就是新的API嗎？

有啥好吹？

關鍵在于，智能體比較以前的軟件，

多了個腦子，

腦子是個好東西，

希望你有，我有，大家有。

沒腦子的軟件，給它一套工具，

“選用哪個”全憑代碼。

拿API來說，10個功能對應10個API，

開發者手動添加10次URL。

而智能體能自己選，

甚至給它一個工具箱入口就夠了，

因為它能判斷工具箱里10個工具用哪個合適。

工具列表里有系列說明性文字，

比如，工具信息，工具描述，

是一種智能體所需要的“背景信息”。

比如，

楊薈博士和譚老師打算，

“從上海到杭州吃西湖醋魚。”

大模型有上海到杭州的常識——不遠，

但是為了精確，

它會從高德里“查”一下距離，

這也是一種“背景信息”。

第四節，為什么Uber還不支持MCP？

并不是在技術上有難度，

實話說，MCP沒啥技術挑戰。

而是，用戶入口有可能不掌握在自己手里了。

人家才不愿意這樣做。

假如，美團接入MCP協議，

某個智能體就能幫著點外賣。

且這個智能體很熱門，用戶超級多，

美團可能就扛不住了，

你現在是不是也理解為什么美團要搞基礎模型了，

你看，AI面前，王興也焦慮。

美團基礎模型的名字很好玩，叫LongCat。

當然，美團也可以選擇抵抗，就不接入。

再講一個例子，

網頁解析器是一種服務，

能讀取和分析網頁內容。

例子：假設你想在所有電商平臺里比價，

以確保買到最便宜商品，

那得知道多個電商平臺該商品的價格變化，

手動比價很費事。

但是，智能體有調用網頁解析器服務的能力，

讓智能體“看”網頁上的價格信息，

并定期通知你價格的變化。

淘寶，京東，PDD自動比價。

你覺得，電商平臺會允許這種全平臺比價智能體，

拿到真實且實時的價格嗎？

價格，多敏感的商業信息，

很可能成立專門的團隊，

“阻止”任何組織或個人成批量“拿走價格”，

別問我怎么知道的。

你不愿意支持，但有人愿意支持。

當這些互聯網門戶級APP，

考慮要不要做MCP Server的時候，

他們擔心的是：

這么多年砸錢無數積攢下來的用戶入口地位，

把用戶入口讓給了調用這個服務的廠商，

那要問一句，

憑什么讓給你？

愿意支持MCP的 APP，

往往是開放接口吸引更多用戶，

推動標準化并構建生態系統的公司。

不愿意支持MCP的APP，

則是那些核心競爭力依賴數據敏感性，

用戶入口是核心資產，

或傾向于封閉生態的公司。

這種差異反映了不同企業，

在面對技術變革時的戰略選擇，

也揭示了技術標準推廣過程中不可避免的博弈。

第五節，“入口大戰”又來了？

MCP是技術話題，也是商業話題。

原本由平臺APP掌控的“商業模式設計權”，

現在有可能轉移到智能體開發者手中。

平臺必須重新思考如何適應這種變化，

否則可能被淘汰。

表面上，MCP的出現是為了提升效率和開放性，

但實際上它觸及了商業深層邏輯：

數據控制權、

生態系統主導權、

商業模式設計權，

以及行業規則制定權。

誰能主導MCP或者類似協議的發展，

誰就能在未來商業版圖中占據有利位置。

只要智能體做大了，

誰不兼容這款“智能助理”，

誰就損失銷售機會。

MCP這個事情的成敗，

取決于智能體繁不繁榮了。

然而，這是一個雞生蛋，

蛋生雞的問題。

首先，智能體要能切實給用戶解決真正的問題，

生活方便，上班簡便。

也有人管智能體叫“數字助理”“數字勞動力”。

智能體想有用戶，想普及，

就得能干很多活，

但是反過來，

而人類大部分的需求：

出行（滴滴），

購物（淘寶），

點外賣（美團），

都有大型APP占據，

遠看星辰大海，近看全是紅海，

看上去智能體想找份“體面工作”，

就業機會不多，

智能體若是沒有工作機會，自然沒有用戶。

這是什么局面？

有點像早期互聯網，

網頁少的時候給，搜索引擎的價值小，

有海量網頁的時候，搜索引擎才有江湖地位，

網頁創作者也會主動優化內容，

以迎合搜索引擎的規則。

當智能體沒有什么用戶的時候，頭部APP不理，

當智能體很火爆，

倒逼著APP廠商加入。

這是一個典型的“先有雞還是先有蛋”的問題，

也就是，技術生態的啟動困境和網絡效應。

有智能體，MCP類似的協議才有存在的可能。

好比，城市道路四通八達了，

到交通法才有實施的意義。

如果某個小地方只有一條10米的路，

交通法的意義也體現不出來。

當下，是智能體的市場教育時期。

楊薈博士認為：距離企業級智能體需求爆發，

還有些時日，但來日不遠。

第六節，哪種軟件最適合封裝成MCP？

看上去，你跟一個工具（MCP Server）說話，

它不會“思考”，只會干它會做，且有限的幾件事。

而智能體要復雜得多，

擅長理解，記憶，邏輯推理，

這個視角下，

大部分工具（MCP Server）像一個電飯鍋，

而智能體像廚師團隊。

要我說，電飯鍋（MCP Server），功能穩定，

只要按鍵就工作，

不記得你之前讓它干啥，

也不會主動去想你下一步要做什么。

而廚師團隊能力強，也不好管。

這種最適合封裝的“工具（MCP Server）”，

其實是那種本身不需要智能的工具，

或者說，不需要智能決策和判斷的工具。

像訂機票，訂酒店，

所以，當下，而大多數工具（MCP Server），

都是“輕量型”的，

如何托管，如何設計這樣一整個“廚師團隊”，

不是誰都有的能力，

這是智能體創業團隊的機會。

第七節，哪種軟件系統擁抱MCP最積極？

答案是，數據庫。

這是楊薈博士的觀察，

我們對“Awesome MCP Servers”集合網站有所觀察。（在github搜索awesome-mcp-servers），

擁抱MCP的軟件（服務商）的數量還在快速增加，那么問題來了，

為什么數據庫擁抱MCP最積極？

寫這節的時候，

“親愛的數據”讀者群有個群友問：

是數據庫擁抱MCP，

還是MCP擁抱數據庫？

這不是文字游戲，

在MCP面前，

MCP是一種協議或標準，本身是中立的，

它并不會主動去“擁抱”某個具體的技術或系統。

相反，軟件（如數據庫、工具、應用），

需要根據MCP的規范進行改造，以實現兼容性。

好比，MCP是一種語言，假如是“英語”。

英語來了，不是用“英語”把數據庫重寫一遍，

而是，數據庫“適配”英語，

好比，增加一個會說英語的接口，

套用這個比方，

數據庫了增加會講“MCP語言”的“服務窗口”，

數據庫不直接和消費者互動，

沒有用戶入口丟失的擔心。

數據庫希望被使用得多越多好，

擁抱MCP當然積極。

楊薈博士還補充了一個觀點，

智能體有一個剛需——

長短期記憶，

加上數據庫就相當于擴展了智能體的記憶容量，

所以，智能體想做大，

可以沒有美團的MCP，

可以沒有阿里天貓的MCP，

但不能沒有數據庫，

按說，大的數據庫的廠商動作還沒有這么快，

不過，不包括Clickhouse，

人家原廠已發布MCP Server。

第八節，

目前工具（MCPServer）里面沒有智能體。

是楊薈博士的一個觀察。

好遺憾，它們在等啥，

為何還沒把智能體放進去。

因為“工具”易于計費、易于控制。

但智能體是行為復雜，

成本不易控，結果不確定的實體。

這正是體現技術團隊價值之所在之處。

那些沒有智能體的工具湊在一起，像什么？

像API商店：

而不是“智能體服務市場”。

為什么？

智能體玩的是，我有一群助理，

能一起幫你想事、做事、配合安排。

就好比，大模型外掛智能體，

智能體在外掛智能體，

禁止俄羅斯套娃梗。

不過，萬事都有開頭。

在“大模型只輸出想法”的前提下，

智能體作為“行動層”，

真正做事的那一層，

它要靠什么爆發？

我們認為：

智能體的蓬勃發展取決于，

它是否擁有，

“通用行動能力+

高質量工具生態+

可組合的系統結構”

——這三者共同形成，

“AI動作系統”的地基。

楊薈博士說，當下看來，

第一波的影響力作用于APP。

第二波的影響力才作用于AI產品。

為什這么說？

美團可能不愿意兼容MCP，

寧愿自己造智能體。

這是天然的阻礙。

怎么辦呢？

我們認為，這可能就會形成“擺渡車”模式。

好比，你進風景去游玩的時候，

公共交通不會帶你直達景點核心地帶，

比如，公交車會停在八達嶺長城烽火臺門口嗎？

多數大景點都有“擺渡車”，

一般來說，干一件大事哪怕里面有好幾件小事，

雖然美團這類平臺不支持MCP，

但是可能會積極支持，

“智能體對智能體協議”，

例如谷歌剛剛發布的Agent to Agent（A2A）。

這就好比，

當智能體A進入美團，

先遇見一個美團前臺，

其實是智能體B。

后續，關于點外賣的一切相關事宜，

美團前臺，

也就是智能體B，

接手了。

這時候，MCP沒用了，

請用智能體和智能體的“語言體系”來溝通。

于是，智能體對智能體的協議，

會日顯重要，

市場的情況，要過數月才能清楚，

不過我們引入了一個新概念。

A2A。

這是另外一套協議。

第九節，我們認為：A2A更重要，為什么？

因為MCP協議本身有些局限性，

接入這套協議的有兩個角色：

智能體的生產廠商和外部工具開發商。

他們并不總是有動力將自己的工具封裝成MCP。

為什么？

因為它們更希望將自己的“接入能力”控制在手中。

比如，智能體廠商希望工具封裝成MCP，

美團滴滴攜程去哪兒這種APP

越多接入越好。

尤其是APP平臺。

例如，美團、滴滴、攜程，

這些平臺越多外部工具接入，

它們就越能獲得更多的流量，

但它們又不希望自己的核心能力，

被第三方工具取代。

智能體的生產商往往不愿意把自己的智能體，

封裝成MCP，

尤其是當它們的智能體已有用戶群體時。

可以說，它們更愿意選擇MCP+A2A雙重封裝，

相當于同時擁有兩種接入方式。

也就是說，

它們希望“工具”能夠主動入局，

但并不是所有的“工具”都有動力去接入MCP，

尤其是那些頭部的APP，

智能體的崛起也可能會削弱APP平臺的控制力。

APP確實很強勢，

若被智能體繞過了入口，

麻煩很大。

假如全世界的大小餐廳老板手機里就有智能體，

可以提供點餐，下單，

吃貨評價，外賣等多個服務功能；

全世界的吃貨，

也都有手機智能體，

這吃貨們的手機智能體對接大量餐廳智能體，

還需要美團干嘛？

美團情何以堪？

再總結一下，

如果終端用戶（消費者）擁有的智能體和商品/服務真正提供方的智能體能用A2A協議直連，那么它們就繞過了APP平臺。因此，A2A協議可能成為智能體沖破發展障礙的關鍵。

第十節，阿里云拿什么樣的動力擁抱MCP？

要我說，動力可太多了，

國內頭部云計算廠商里旗幟鮮明地支持MCP的，

確實只有阿里云了。

國內其他廠商都沒玩MCP。

這符合他們AI這一輪的開源策略。

智能體在當前的AI產品生態中，

占據了一個非常重要的地位，

不僅是新技術，

更是一種全新的產品形態。

對阿里云來說，

任何有利于智能體生態發展的事，

都應該多做。

這樣就有了先發優勢。

這波阿里云吃虧只有一種可能：

萬一智能體完全是個泡沫

我認為，其他廠商現在沒吶喊支持，

一部分是因為資源有限，

或者，還在考慮怎么支持，如何支持。

阿里云現有動作：

一是百煉開了智能體商城，

二是無影云電腦搞了個智能體的運行環境，

名叫AgentBay。

它倆是什么關系呢？

一個是智能體商城（百煉），

一個是商城里的旗艦店（AgentBay）。

舊邏輯里，云廠商的價值就是讓IT更簡單，

新邏輯還在形成，

我觀察，無影是阿里云原廠原裝的云電腦，

既然智能體需要操作一個“電腦”，

那么無影肯定爭先恐后，

也就是說，就有很多事情可以做。

AgentBay這個產品，

是帶電腦操作系統界面的虛擬機服務。

當你在這個虛擬機環境里讓智能體操作電腦。

不就是一個“操作間”嗎，

有操作環境，且能在這里面加裝備。

阿里云就是開發環境和裝備的廠商。

現在智能體作坊，

明日智能體工廠。

智能體有這么強的剛需嗎？

有時候，一般的本地設備（辦公電腦），

難以支撐高并發，

高算力需求的智能體，

還有時候，任務執行時，

會占用本地計算資源和操作權限，

也就是一種“我的電腦”，

被智能體“霸占”的即視感。

嚴謹地說，阿里云的目標是，

讓開發者無需自己搭建和配置虛擬機，

而是直接用阿里的虛擬機環境來開發智能體。

省流版說法：

WeWork辦公區，

誰用誰留，用完就走。

以無影云電腦為例，對比一下，

如果不使用MCP協議，

智能體仍然可調用無影的虛擬操作間服務，

但前提是，

智能體開發者需要閱讀虛擬操作間的API文檔，

并手動代碼調用這些服務。

也就是說，

開發者需要在代碼中明確“告訴”智能體，

該如何操作以及各種細節。

而如果使用MCP協議，

智能體則能自動讀取，

MCP協議中的相關操作指南，

智能體自行決定如何調用。

像Manus這樣操作電腦的產品，

云上“包間”做得好，

高效和安全就都有了。

這件事對云廠商有多重要呢？

如果云廠商不做好，

會有人替你干好。

那就是大模型廠商，

干得好，且取得壟斷地位后，

就能繞開了云廠商。

所以，對智能體，

云計算廠商都會不遺余力，

而且，要我說，一舉兩得，

云平臺按需計費的模式，

為智能體開發者提供彈性計算資源，

從而增加收入。

此外，可從調用阿里云別的服務的API中收費。

比如，智能體用了阿里云PolarDB數據庫，

阿里數據庫部門就可以賺到錢，

其他云廠商也一樣。

不僅能夠賺錢，取得規模效應后，

有機會成為“智能體商店”的所有者，

就看阿里云有沒有實力運營智能體時代的淘寶。

第十一節，有MCP，為什么谷歌還出A2A？

阿里現在支持MCP，

日后也會支持A2A嗎？

這是個好問題。

谷歌A2A博客說，

它和MCP的關系是補充關系，

但不夠本質，

A2A協議意味著，

智能體服務里的兩個角色都是智能體，

智能體A和智能體B，

甚至就可以人類自然語言交流，

還需要MCP協議嗎？

為了干活的目標，

智能體B在理解了智能體A的意圖之后，

智能體B自己決定的如何提供服務。

B提供給A服務，B服務A，

這里用甲乙方的比喻比較貼切。

蘋果會推出自己的協議和谷歌的競爭嗎？

有可能，因為在端入口，

智能手機廠商話語權最大，

硬件控制軟件，這是房東和租客的關系，

手機廠商對APP廠商始終有降維打擊的能力。

我們暢想日后，

人形機器人的數量超過了手機的數量，

機器人廠商就是房東了。

楊薈博士和我討論時談到，

悲觀的專家也在發聲，智能體泡沫太大。

智能體的瓶頸沒有暴露出來，

有個觀點是，智能體也許沒有瓶頸，

因為只有智能體大量被用戶使用，

積累真實的使用數據后，

智能體改進的過程中，

才能看清天花板到底在哪。

A2A協議還得再新開一篇，

歡迎專家前來交流。

第十二節，舉個西湖醋魚的例子，

體會MCP的方便之處，

尤其體會，

智能體在沒有人插手（規定格式，選擇工具）的情況下，就有工具可用，且知道怎么用。

以前：手動查高德和美團，

以后：智能體，

這時候，

我想再聊聊MCP里的字母C是什么？

是Context，直接翻譯是“上下文”，

那到底什么是上下文？

智能體需要理解的，

為了達成用戶的（楊薈博士和譚老師）目標，

用戶雖然沒說，智能體也應該知道的信息。

MCP協議通過標準化的數據結構和接口，

將“上下文”傳遞給智能體。

智能體的常識里有：

1.知道杭州離上海不遠；

2.西湖醋魚是杭幫菜；

智能體“調用”高德，“上下文”里有：

第一，城市地區，

出行看天氣，出發和到達城市天氣；

第二，推薦餐廳，

地點在杭州西湖景區，

第三，口味，

杭幫菜。

第四，選擇出行方式，

比如開車、騎車、步行。

再次確認杭州到上海精確距離182公里，

開車大約三小時可到達，

但只有約1/10000的用戶喜歡騎車去，

幾乎沒有人喜歡從走路去。

所以，智能體會幫楊薈博士和譚老師，

挑選自駕的方式。

接下來，

智能體“調用”美團，

第五，選擇“樓外樓”（孤山店）餐廳；

解釋一下，

這是美團內部評分排序算法得出的結果，

到底智能體能獲取前三名，還是前五名，

這取決于美團寫MCP協議的時候，

至于返回幾個最佳上榜餐廳，

至于是取前三強，

或者前五強，

由美團決定；

也就是說，

MCP協議只規定格式，

格式里的細節由美團決定，

由美團的工程師在開發MCP工具時考慮。

還可以調用Agentbay里的瀏覽器能力，

搜索下小紅書相關話題下面的口碑評價，

添點笑料，

最后，西湖醋魚上桌。

最后的最后，

作為一個杭州人，

譚老師告訴楊薈博士，

如果你覺得西湖醋魚難吃，

那一定不正宗，

因為正宗的更難吃。

（完）