是時候去問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裏的瀏覽器能力，

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

添點笑料，

最後，西湖醋魚上桌。

最後的最後，

作為一個杭州人，

譚老師告訴楊薈博士，

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

那一定不正宗，

因為正宗的更難吃。

（完）