是時(shí)候去問CTO了，咱的AI產(chǎn)品要不要封裝MCP？

原創(chuàng)：楊薈博士（Istari企業(yè)智能創(chuàng)始人），親愛的數(shù)據(jù)（譚婧）

第一節(jié)，當(dāng)下是智能體蠻荒時(shí)期，

為什么MCP協(xié)議火了？

大家對智能體的好感，

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

加了一把柴火。

還有深度研究（DeepResearch），

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

定性定量分析的智能體產(chǎn)品，

也帶了好頭，

好產(chǎn)品起到示范作用，帶動(dòng)智能體概念。

進(jìn)而帶動(dòng)MCP討論熱度。

當(dāng)然，反對的聲音也很大，

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

對待垃圾產(chǎn)品應(yīng)該一致吐槽，

真正有價(jià)值的東西，

表面看似吐槽，本質(zhì)是辯論：

為什么MCP如此重要？

先講個(gè)好理解的，

都知道，數(shù)據(jù)對大模型非常重要，

除了已經(jīng)“喂給”模型的數(shù)據(jù)，

推理時(shí)，訪問到外部的數(shù)據(jù)也非常重要，

但唯一是“喂進(jìn)去訓(xùn)練”這個(gè)形式嗎？

肯定不是。

但是外面接入數(shù)據(jù)哪里那么容易。

且不只數(shù)據(jù)，文件，工具，

往大了說某個(gè)系統(tǒng)的能力，

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

“接入”的本質(zhì)是“集成”，

當(dāng)下有關(guān)AI的集成高度碎片化，

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

各界人士只要想讓AI有個(gè)好發(fā)展，好前程，

都想讓局面有個(gè)根本型的改變。

MCP應(yīng)運(yùn)而出，

而且會在這個(gè)方向上迅速迭代。

任何開放協(xié)議之類的東西天然受到開源社區(qū)歡迎，

后面我們還會介紹。

Anthropic公司推出MCP，

確實(shí)為模型發(fā)展“計(jì)深遠(yuǎn)”，

OpenAI緊跟而上，

也顯示了其胸懷。

北美AI模型的兩架馬車，

均拿出了態(tài)度和行動(dòng)。

現(xiàn)在真有點(diǎn)，

且看下回分解的味道了。

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

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

前面4個(gè)觀點(diǎn)后文均有反駁。

還有一個(gè)有趣的問題，

誰在研究MCP？

第一波人鐵定是程序員，

程序員是API最直接的“消費(fèi)者”，

而第二波關(guān)心的MCP人才更關(guān)鍵——

創(chuàng)業(yè)公司創(chuàng)始人，產(chǎn)品負(fù)責(zé)人，技術(shù)負(fù)責(zé)人。

因?yàn)樗麄兊脹Q定一件事——

“我的AI產(chǎn)品要不要也用MCP？”

第二節(jié)：MCP是啥？

MCP，全稱Model Context Protocol。

模型上下文協(xié)議，

熱門詞匯，

不能慢一步。

吃瓜最前線，

若想挖得深，

“USB插頭”“橋梁”，

這種比喻就潦草了。

“MCP是啥”這個(gè)問題，

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

MCP這個(gè)話題，

幻覺程度前所未有，高達(dá)50%。

看來對于互聯(lián)網(wǎng)上還沒有形成定論的新興事物，

大模型也似懂非懂。

最好理解兩樣?xùn)|西：

1.API

2.智能體

在MCP出現(xiàn)之前，

早期的技術(shù)協(xié)議已經(jīng)做了類似的工作，

本質(zhì)上，協(xié)議解決了軟件之間的連接。

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

智能體想“看”地圖，

不用再造一套地圖服務(wù)，

人家高德導(dǎo)航做得已經(jīng)很好了：

1路線規(guī)劃與導(dǎo)航

2實(shí)時(shí)交通信息

3位置搜索

4地點(diǎn)詳情查詢

5公共交通查詢

6打車服務(wù)對接

7停車場查詢與導(dǎo)航

8天氣與環(huán)境信息

9吃喝玩樂推薦

10周邊公共交通工具推薦

那想“調(diào)用”高德導(dǎo)航里某種服務(wù)怎么辦？

以前是APP之間調(diào)用，

比如：滴滴打車可用高德實(shí)時(shí)交通信息優(yōu)化路線，

只是一個(gè)比方，其實(shí)滴滴并不舍得這筆費(fèi)用，

滴滴有自己的地圖部門，

我認(rèn)識他們部門的算法小哥哥，

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

話說回來，

對開發(fā)者來說，高德是一套功能。

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

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

也是MCP Server，

MCP官網(wǎng)說了，

有三種MCP Server。

第三節(jié)，API為何不夠用，非要MCP？

從某個(gè)角度講，

雖然MCP是Anthropic公司推出的，

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

但要成為行業(yè)通行的標(biāo)準(zhǔn)，

它還需要贏得多方支持：

終端用戶，開發(fā)者，傳統(tǒng)軟件工具，線上服務(wù)平臺。

每個(gè)利益相關(guān)方都有自己的訴求，

比如，開發(fā)者希望減少開發(fā)工作量，

MCP的設(shè)計(jì)天然考慮了開發(fā)者的訴求。

有請楊薈博士給“觀點(diǎn)2”一個(gè)硬核反駁：

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

理解和執(zhí)行的能力千差萬別。

因?yàn)锳PI寫的人，寫的方式也千差萬別。

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

智能體需要調(diào)用APP的功能，

但是APP的類型太多了，

訴求也各不相同。

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

比如高德。

值得注意，

這時(shí)候，高德和智能體比起來，

高德“權(quán)力”更大。

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

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

兼容MCP是高德“做出”動(dòng)作配合AI，

把這些功能“變成一種MCP服務(wù)“，發(fā)布出去，

這樣，智能體才能來“調(diào)用”。

我們稱高德為MCP Server，

能被智能體調(diào)用。

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

有啥好吹？

關(guān)鍵在于，智能體比較以前的軟件，

多了個(gè)腦子，

腦子是個(gè)好東西，

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

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

“選用哪個(gè)”全憑代碼。

拿API來說，10個(gè)功能對應(yīng)10個(gè)API，

開發(fā)者手動(dòng)添加10次URL。

而智能體能自己選，

甚至給它一個(gè)工具箱入口就夠了，

因?yàn)樗芘袛喙ぞ呦淅?0個(gè)工具用哪個(gè)合適。

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

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

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

比如，

楊薈博士和譚老師打算，

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

大模型有上海到杭州的常識——不遠(yuǎn)，

但是為了精確，

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

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

第四節(jié)，為什么Uber還不支持MCP？

并不是在技術(shù)上有難度，

實(shí)話說，MCP沒啥技術(shù)挑戰(zhàn)。

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

人家才不愿意這樣做。

假如，美團(tuán)接入MCP協(xié)議，

某個(gè)智能體就能幫著點(diǎn)外賣。

且這個(gè)智能體很熱門，用戶超級多，

美團(tuán)可能就扛不住了，

你現(xiàn)在是不是也理解為什么美團(tuán)要搞基礎(chǔ)模型了，

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

美團(tuán)基礎(chǔ)模型的名字很好玩，叫LongCat。

當(dāng)然，美團(tuán)也可以選擇抵抗，就不接入。

再講一個(gè)例子，

網(wǎng)頁解析器是一種服務(wù)，

能讀取和分析網(wǎng)頁內(nèi)容。

例子：假設(shè)你想在所有電商平臺里比價(jià)，

以確保買到最便宜商品，

那得知道多個(gè)電商平臺該商品的價(jià)格變化，

手動(dòng)比價(jià)很費(fèi)事。

但是，智能體有調(diào)用網(wǎng)頁解析器服務(wù)的能力，

讓智能體“看”網(wǎng)頁上的價(jià)格信息，

并定期通知你價(jià)格的變化。

淘寶，京東，PDD自動(dòng)比價(jià)。

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

拿到真實(shí)且實(shí)時(shí)的價(jià)格嗎？

價(jià)格，多敏感的商業(yè)信息，

很可能成立專門的團(tuán)隊(duì)，

“阻止”任何組織或個(gè)人成批量“拿走價(jià)格”，

別問我怎么知道的。

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

當(dāng)這些互聯(lián)網(wǎng)門戶級APP，

考慮要不要做MCP Server的時(shí)候，

他們擔(dān)心的是：

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

把用戶入口讓給了調(diào)用這個(gè)服務(wù)的廠商，

那要問一句，

憑什么讓給你？

愿意支持MCP的 APP，

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

推動(dòng)標(biāo)準(zhǔn)化并構(gòu)建生態(tài)系統(tǒng)的公司。

不愿意支持MCP的APP，

則是那些核心競爭力依賴數(shù)據(jù)敏感性，

用戶入口是核心資產(chǎn)，

或傾向于封閉生態(tài)的公司。

這種差異反映了不同企業(yè)，

在面對技術(shù)變革時(shí)的戰(zhàn)略選擇，

也揭示了技術(shù)標(biāo)準(zhǔn)推廣過程中不可避免的博弈。

第五節(jié)，“入口大戰(zhàn)”又來了？

MCP是技術(shù)話題，也是商業(yè)話題。

原本由平臺APP掌控的“商業(yè)模式設(shè)計(jì)權(quán)”，

現(xiàn)在有可能轉(zhuǎn)移到智能體開發(fā)者手中。

平臺必須重新思考如何適應(yīng)這種變化，

否則可能被淘汰。

表面上，MCP的出現(xiàn)是為了提升效率和開放性，

但實(shí)際上它觸及了商業(yè)深層邏輯：

數(shù)據(jù)控制權(quán)、

生態(tài)系統(tǒng)主導(dǎo)權(quán)、

商業(yè)模式設(shè)計(jì)權(quán)，

以及行業(yè)規(guī)則制定權(quán)。

誰能主導(dǎo)MCP或者類似協(xié)議的發(fā)展，

誰就能在未來商業(yè)版圖中占據(jù)有利位置。

只要智能體做大了，

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

誰就損失銷售機(jī)會。

MCP這個(gè)事情的成敗，

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

然而，這是一個(gè)雞生蛋，

蛋生雞的問題。

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

生活方便，上班簡便。

也有人管智能體叫“數(shù)字助理”“數(shù)字勞動(dòng)力”。

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

就得能干很多活，

但是反過來，

而人類大部分的需求：

出行（滴滴），

購物（淘寶），

點(diǎn)外賣（美團(tuán)），

都有大型APP占據(jù)，

遠(yuǎn)看星辰大海，近看全是紅海，

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

就業(yè)機(jī)會不多，

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

這是什么局面？

有點(diǎn)像早期互聯(lián)網(wǎng)，

網(wǎng)頁少的時(shí)候給，搜索引擎的價(jià)值小，

有海量網(wǎng)頁的時(shí)候，搜索引擎才有江湖地位，

網(wǎng)頁創(chuàng)作者也會主動(dòng)優(yōu)化內(nèi)容，

以迎合搜索引擎的規(guī)則。

當(dāng)智能體沒有什么用戶的時(shí)候，頭部APP不理，

當(dāng)智能體很火爆，

倒逼著APP廠商加入。

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

也就是，技術(shù)生態(tài)的啟動(dòng)困境和網(wǎng)絡(luò)效應(yīng)。

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

好比，城市道路四通八達(dá)了，

到交通法才有實(shí)施的意義。

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

交通法的意義也體現(xiàn)不出來。

當(dāng)下，是智能體的市場教育時(shí)期。

楊薈博士認(rèn)為：距離企業(yè)級智能體需求爆發(fā)，

還有些時(shí)日，但來日不遠(yuǎn)。

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

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

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

而智能體要復(fù)雜得多，

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

這個(gè)視角下，

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

而智能體像廚師團(tuán)隊(duì)。

要我說，電飯鍋（MCP Server），功能穩(wěn)定，

只要按鍵就工作，

不記得你之前讓它干啥，

也不會主動(dòng)去想你下一步要做什么。

而廚師團(tuán)隊(duì)能力強(qiáng)，也不好管。

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

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

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

像訂機(jī)票，訂酒店，

所以，當(dāng)下，而大多數(shù)工具（MCP Server），

都是“輕量型”的，

如何托管，如何設(shè)計(jì)這樣一整個(gè)“廚師團(tuán)隊(duì)”，

不是誰都有的能力，

這是智能體創(chuàng)業(yè)團(tuán)隊(duì)的機(jī)會。

第七節(jié)，哪種軟件系統(tǒng)擁抱MCP最積極？

答案是，數(shù)據(jù)庫。

這是楊薈博士的觀察，

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

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

為什么數(shù)據(jù)庫擁抱MCP最積極？

寫這節(jié)的時(shí)候，

“親愛的數(shù)據(jù)”讀者群有個(gè)群友問：

是數(shù)據(jù)庫擁抱MCP，

還是MCP擁抱數(shù)據(jù)庫？

這不是文字游戲，

在MCP面前，

MCP是一種協(xié)議或標(biāo)準(zhǔn)，本身是中立的，

它并不會主動(dòng)去“擁抱”某個(gè)具體的技術(shù)或系統(tǒng)。

相反，軟件（如數(shù)據(jù)庫、工具、應(yīng)用），

需要根據(jù)MCP的規(guī)范進(jìn)行改造，以實(shí)現(xiàn)兼容性。

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

英語來了，不是用“英語”把數(shù)據(jù)庫重寫一遍，

而是，數(shù)據(jù)庫“適配”英語，

好比，增加一個(gè)會說英語的接口，

套用這個(gè)比方，

數(shù)據(jù)庫了增加會講“MCP語言”的“服務(wù)窗口”，

數(shù)據(jù)庫不直接和消費(fèi)者互動(dòng)，

沒有用戶入口丟失的擔(dān)心。

數(shù)據(jù)庫希望被使用得多越多好，

擁抱MCP當(dāng)然積極。

楊薈博士還補(bǔ)充了一個(gè)觀點(diǎn)，

智能體有一個(gè)剛需——

長短期記憶，

加上數(shù)據(jù)庫就相當(dāng)于擴(kuò)展了智能體的記憶容量，

所以，智能體想做大，

可以沒有美團(tuán)的MCP，

可以沒有阿里天貓的MCP，

但不能沒有數(shù)據(jù)庫，

按說，大的數(shù)據(jù)庫的廠商動(dòng)作還沒有這么快，

不過，不包括Clickhouse，

人家原廠已發(fā)布MCP Server。

第八節(jié)，

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

是楊薈博士的一個(gè)觀察。

好遺憾，它們在等啥，

為何還沒把智能體放進(jìn)去。

因?yàn)椤肮ぞ摺币子谟?jì)費(fèi)、易于控制。

但智能體是行為復(fù)雜，

成本不易控，結(jié)果不確定的實(shí)體。

這正是體現(xiàn)技術(shù)團(tuán)隊(duì)價(jià)值之所在之處。

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

像API商店：

而不是“智能體服務(wù)市場”。

為什么？

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

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

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

智能體在外掛智能體，

禁止俄羅斯套娃梗。

不過，萬事都有開頭。

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

智能體作為“行動(dòng)層”，

真正做事的那一層，

它要靠什么爆發(fā)？

我們認(rèn)為：

智能體的蓬勃發(fā)展取決于，

它是否擁有，

“通用行動(dòng)能力+

高質(zhì)量工具生態(tài)+

可組合的系統(tǒng)結(jié)構(gòu)”

——這三者共同形成，

“AI動(dòng)作系統(tǒng)”的地基。

楊薈博士說，當(dāng)下看來，

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

第二波的影響力才作用于AI產(chǎn)品。

為什這么說？

美團(tuán)可能不愿意兼容MCP，

寧愿自己造智能體。

這是天然的阻礙。

怎么辦呢？

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

好比，你進(jìn)風(fēng)景去游玩的時(shí)候，

公共交通不會帶你直達(dá)景點(diǎn)核心地帶，

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

多數(shù)大景點(diǎn)都有“擺渡車”，

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

雖然美團(tuán)這類平臺不支持MCP，

但是可能會積極支持，

“智能體對智能體協(xié)議”，

例如谷歌剛剛發(fā)布的Agent to Agent（A2A）。

這就好比，

當(dāng)智能體A進(jìn)入美團(tuán)，

先遇見一個(gè)美團(tuán)前臺，

其實(shí)是智能體B。

后續(xù)，關(guān)于點(diǎn)外賣的一切相關(guān)事宜，

美團(tuán)前臺，

也就是智能體B，

接手了。

這時(shí)候，MCP沒用了，

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

于是，智能體對智能體的協(xié)議，

會日顯重要，

市場的情況，要過數(shù)月才能清楚，

不過我們引入了一個(gè)新概念。

A2A。

這是另外一套協(xié)議。

第九節(jié)，我們認(rèn)為：A2A更重要，為什么？

因?yàn)镸CP協(xié)議本身有些局限性，

接入這套協(xié)議的有兩個(gè)角色：

智能體的生產(chǎn)廠商和外部工具開發(fā)商。

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

為什么？

因?yàn)樗鼈兏Ｍ麑⒆约旱摹敖尤肽芰Α笨刂圃谑种小?/p>

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

美團(tuán)滴滴攜程去哪兒這種APP

越多接入越好。

尤其是APP平臺。

例如，美團(tuán)、滴滴、攜程，

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

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

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

被第三方工具取代。

智能體的生產(chǎn)商往往不愿意把自己的智能體，

封裝成MCP，

尤其是當(dāng)它們的智能體已有用戶群體時(shí)。

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

相當(dāng)于同時(shí)擁有兩種接入方式。

也就是說，

它們希望“工具”能夠主動(dòng)入局，

但并不是所有的“工具”都有動(dòng)力去接入MCP，

尤其是那些頭部的APP，

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

APP確實(shí)很強(qiáng)勢，

若被智能體繞過了入口，

麻煩很大。

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

可以提供點(diǎn)餐，下單，

吃貨評價(jià)，外賣等多個(gè)服務(wù)功能；

全世界的吃貨，

也都有手機(jī)智能體，

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

還需要美團(tuán)干嘛？

美團(tuán)情何以堪？

再總結(jié)一下，

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

第十節(jié)，阿里云拿什么樣的動(dòng)力擁抱MCP？

要我說，動(dòng)力可太多了，

國內(nèi)頭部云計(jì)算廠商里旗幟鮮明地支持MCP的，

確實(shí)只有阿里云了。

國內(nèi)其他廠商都沒玩MCP。

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

智能體在當(dāng)前的AI產(chǎn)品生態(tài)中，

占據(jù)了一個(gè)非常重要的地位，

不僅是新技術(shù)，

更是一種全新的產(chǎn)品形態(tài)。

對阿里云來說，

任何有利于智能體生態(tài)發(fā)展的事，

都應(yīng)該多做。

這樣就有了先發(fā)優(yōu)勢。

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

萬一智能體完全是個(gè)泡沫

我認(rèn)為，其他廠商現(xiàn)在沒吶喊支持，

一部分是因?yàn)橘Y源有限，

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

阿里云現(xiàn)有動(dòng)作：

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

二是無影云電腦搞了個(gè)智能體的運(yùn)行環(huán)境，

名叫AgentBay。

它倆是什么關(guān)系呢？

一個(gè)是智能體商城（百煉），

一個(gè)是商城里的旗艦店（AgentBay）。

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

新邏輯還在形成，

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

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

那么無影肯定爭先恐后，

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

AgentBay這個(gè)產(chǎn)品，

是帶電腦操作系統(tǒng)界面的虛擬機(jī)服務(wù)。

當(dāng)你在這個(gè)虛擬機(jī)環(huán)境里讓智能體操作電腦。

不就是一個(gè)“操作間”嗎，

有操作環(huán)境，且能在這里面加裝備。

阿里云就是開發(fā)環(huán)境和裝備的廠商。

現(xiàn)在智能體作坊，

明日智能體工廠。

智能體有這么強(qiáng)的剛需嗎？

有時(shí)候，一般的本地設(shè)備（辦公電腦），

難以支撐高并發(fā)，

高算力需求的智能體，

還有時(shí)候，任務(wù)執(zhí)行時(shí)，

會占用本地計(jì)算資源和操作權(quán)限，

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

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

嚴(yán)謹(jǐn)?shù)卣f，阿里云的目標(biāo)是，

讓開發(fā)者無需自己搭建和配置虛擬機(jī)，

而是直接用阿里的虛擬機(jī)環(huán)境來開發(fā)智能體。

省流版說法：

WeWork辦公區(qū)，

誰用誰留，用完就走。

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

如果不使用MCP協(xié)議，

智能體仍然可調(diào)用無影的虛擬操作間服務(wù)，

但前提是，

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

并手動(dòng)代碼調(diào)用這些服務(wù)。

也就是說，

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

該如何操作以及各種細(xì)節(jié)。

而如果使用MCP協(xié)議，

智能體則能自動(dòng)讀取，

MCP協(xié)議中的相關(guān)操作指南，

智能體自行決定如何調(diào)用。

像Manus這樣操作電腦的產(chǎn)品，

云上“包間”做得好，

高效和安全就都有了。

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

如果云廠商不做好，

會有人替你干好。

那就是大模型廠商，

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

就能繞開了云廠商。

所以，對智能體，

云計(jì)算廠商都會不遺余力，

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

云平臺按需計(jì)費(fèi)的模式，

為智能體開發(fā)者提供彈性計(jì)算資源，

從而增加收入。

此外，可從調(diào)用阿里云別的服務(wù)的API中收費(fèi)。

比如，智能體用了阿里云PolarDB數(shù)據(jù)庫，

阿里數(shù)據(jù)庫部門就可以賺到錢，

其他云廠商也一樣。

不僅能夠賺錢，取得規(guī)模效應(yīng)后，

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

就看阿里云有沒有實(shí)力運(yùn)營智能體時(shí)代的淘寶。

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

阿里現(xiàn)在支持MCP，

日后也會支持A2A嗎？

這是個(gè)好問題。

谷歌A2A博客說，

它和MCP的關(guān)系是補(bǔ)充關(guān)系，

但不夠本質(zhì)，

A2A協(xié)議意味著，

智能體服務(wù)里的兩個(gè)角色都是智能體，

智能體A和智能體B，

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

還需要MCP協(xié)議嗎？

為了干活的目標(biāo)，

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

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

B提供給A服務(wù)，B服務(wù)A，

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

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

有可能，因?yàn)樵诙巳肟冢?/p>

智能手機(jī)廠商話語權(quán)最大，

硬件控制軟件，這是房東和租客的關(guān)系，

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

我們暢想日后，

人形機(jī)器人的數(shù)量超過了手機(jī)的數(shù)量，

機(jī)器人廠商就是房東了。

楊薈博士和我討論時(shí)談到，

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

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

有個(gè)觀點(diǎn)是，智能體也許沒有瓶頸，

因?yàn)橹挥兄悄荏w大量被用戶使用，

積累真實(shí)的使用數(shù)據(jù)后，

智能體改進(jìn)的過程中，

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

A2A協(xié)議還得再新開一篇，

歡迎專家前來交流。

第十二節(jié)，舉個(gè)西湖醋魚的例子，

體會MCP的方便之處，

尤其體會，

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

以前：手動(dòng)查高德和美團(tuán)，

以后：智能體，

這時(shí)候，

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

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

那到底什么是上下文？

智能體需要理解的，

為了達(dá)成用戶的（楊薈博士和譚老師）目標(biāo)，

用戶雖然沒說，智能體也應(yīng)該知道的信息。

MCP協(xié)議通過標(biāo)準(zhǔn)化的數(shù)據(jù)結(jié)構(gòu)和接口，

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

智能體的常識里有：

1.知道杭州離上海不遠(yuǎn)；

2.西湖醋魚是杭幫菜；

智能體“調(diào)用”高德，“上下文”里有：

第一，城市地區(qū)，

出行看天氣，出發(fā)和到達(dá)城市天氣；

第二，推薦餐廳，

地點(diǎn)在杭州西湖景區(qū)，

第三，口味，

杭幫菜。

第四，選擇出行方式，

比如開車、騎車、步行。

再次確認(rèn)杭州到上海精確距離182公里，

開車大約三小時(shí)可到達(dá)，

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

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

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

挑選自駕的方式。

接下來，

智能體“調(diào)用”美團(tuán)，

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

解釋一下，

這是美團(tuán)內(nèi)部評分排序算法得出的結(jié)果，

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

這取決于美團(tuán)寫MCP協(xié)議的時(shí)候，

至于返回幾個(gè)最佳上榜餐廳，

至于是取前三強(qiáng)，

或者前五強(qiáng)，

由美團(tuán)決定；

也就是說，

MCP協(xié)議只規(guī)定格式，

格式里的細(xì)節(jié)由美團(tuán)決定，

由美團(tuán)的工程師在開發(fā)MCP工具時(shí)考慮。

還可以調(diào)用Agentbay里的瀏覽器能力，

搜索下小紅書相關(guān)話題下面的口碑評價(jià)，

添點(diǎn)笑料，

最后，西湖醋魚上桌。

最后的最后，

作為一個(gè)杭州人，

譚老師告訴楊薈博士，

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

那一定不正宗，

因?yàn)檎诘母y吃。

（完）