隨著AI技術(shù)的飛速發(fā)展，智能體和相關(guān)協(xié)議成為了行業(yè)關(guān)注的焦點。MCP（Model Context Protocol，模型上下文協(xié)議）作為一種新興的協(xié)議，正在引發(fā)廣泛討論。它不僅關(guān)乎技術(shù)實現(xiàn)，更涉及商業(yè)戰(zhàn)略和未來應(yīng)用生態(tài)的構(gòu)建。

———— / BEGIN / ————

在和楊薈博士幾十個小時的討論，十幾日寫作之后，我也不由喟嘆一句，一看MCP，是個協(xié)議，是技術(shù)，二看MCP，是商業(yè)，三看MCP，是爭奪下一代應(yīng)用入口。

那么故事就開始了。

第一節(jié)

當(dāng)下是智能體蠻荒時期，為什么MCP協(xié)議火了？

大家對智能體的好感，被Manus這種操作電腦的智能體，加了一把柴火。

還有深度研究（DeepResearch），這種擅長信息檢索、匯總、推理、定性定量分析的智能體產(chǎn)品，也帶了好頭，好產(chǎn)品起到示范作用，帶動智能體概念。進而帶動MCP討論熱度。

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

觀點1.兩個月后就有更好的模型出現(xiàn)，我們不應(yīng)該在“腳手架”上花更多時間精力。

觀點2.現(xiàn)在的模型已經(jīng)能讀懂API文檔了，能生成調(diào)用API的代碼了，為啥還要出來個MCP？

觀點3.人來操作API都有信息安全問題，何況智能體？

觀點4.MCP出來大半年了，大的服務(wù)商沒有幾個真的為它適配。

對待垃圾產(chǎn)品應(yīng)該一致吐槽，真正有價值的東西，表面看似吐槽，本質(zhì)是辯論：

為什么MCP如此重要？

先講個好理解的。

都知道，數(shù)據(jù)對大模型非常重要，除了已經(jīng)“喂給”模型的數(shù)據(jù)，推理時，訪問到外部的數(shù)據(jù)也非常重要，但唯一是“喂進去訓(xùn)練”這個形式嗎？

肯定不是。

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

且不只數(shù)據(jù)，文件，工具，往大了說某個系統(tǒng)的能力，都可以“接入”給大模型。

“接入”的本質(zhì)是“集成”，當(dāng)下有關(guān)AI的集成高度碎片化，這是一件極為糟糕的事情。

各界人士只要想讓AI有個好發(fā)展，好前程，都想讓局面有個根本型的改變。

MCP應(yīng)運而出，而且會在這個方向上迅速迭代。

任何開放協(xié)議之類的東西天然受到開源社區(qū)歡迎，后面我們還會介紹。

Anthropic公司推出MCP，確實為模型發(fā)展“計深遠”，OpenAI緊跟而上，也顯示了其胸懷。

北美AI模型的兩架馬車，均拿出了態(tài)度和行動。

現(xiàn)在真有點，且看下回分解的味道了。

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

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

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

還有一個有趣的問題，誰在研究MCP？

第一波人鐵定是程序員，程序員是API最直接的“消費者”，而第二波關(guān)心的MCP人才更關(guān)鍵——創(chuàng)業(yè)公司創(chuàng)始人，產(chǎn)品負責(zé)人，技術(shù)負責(zé)人。

因為他們得決定一件事——“我的AI產(chǎn)品要不要也用MCP？”

第二節(jié)

MCP是啥？

MCP，全稱Model Context Protocol。

模型上下文協(xié)議，熱門詞匯，不能慢一步。

吃瓜最前線，若想挖得深，“USB插頭”“橋梁”，這種比喻就潦草了。

“MCP是啥”這個問題，我也問了GPT，千問，豆包不少問題，MCP這個話題，幻覺程度前所未有，高達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實時交通信息

3位置搜索

4地點詳情查詢

5公共交通查詢

6打車服務(wù)對接

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

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

9吃喝玩樂推薦

10周邊公共交通工具推薦

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

以前是APP之間調(diào)用，比如：滴滴打車可用高德實時交通信息優(yōu)化路線，只是一個比方，其實滴滴并不舍得這筆費用，滴滴有自己的地圖部門，我認識他們部門的算法小哥哥，怎么說呢，滴滴地圖的服務(wù)一言難盡……

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

對智能體來說，高德里的信息，功能，它都需要，高德是智能體的“工具”，也是MCP Server，MCP官網(wǎng)說了，有三種MCP Server。

第三節(jié)

API為何不夠用，非要MCP？

從某個角度講，雖然MCP是Anthropic公司推出的，近期也得到了OpenAI公司的支持，但要成為行業(yè)通行的標(biāo)準(zhǔn)，它還需要贏得多方支持：終端用戶，開發(fā)者，傳統(tǒng)軟件工具，線上服務(wù)平臺。

每個利益相關(guān)方都有自己的訴求。比如，開發(fā)者希望減少開發(fā)工作量，MCP的設(shè)計天然考慮了開發(fā)者的訴求。

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

最大的原因是，如果讓模型自己讀API的話，理解和執(zhí)行的能力千差萬別。因為API寫的人，寫的方式也千差萬別。

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

智能體需要調(diào)用APP的功能，但是APP的類型太多了，訴求也各不相同。

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

比如高德。值得注意，這時候，高德和智能體比起來，高德“權(quán)力”更大。

是高德允許智能體查路線、算距離，是高德允許智能體使用它的API功能，兼容MCP是高德“做出”動作配合AI，把這些功能“變成一種MCP服務(wù)“，發(fā)布出去，這樣，智能體才能來“調(diào)用”。

我們稱高德為MCP Server，能被智能體調(diào)用。

此刻，你會問，不就是新的API嗎？有啥好吹？

關(guān)鍵在于，智能體比較以前的軟件，多了個腦子，腦子是個好東西，希望你有，我有，大家有。沒腦子的軟件，給它一套工具，“選用哪個”全憑代碼。

拿API來說，10個功能對應(yīng)10個API，開發(fā)者手動添加10次URL。而智能體能自己選，甚至給它一個工具箱入口就夠了，因為它能判斷工具箱里10個工具用哪個合適。

工具列表里有系列說明性文字，比如，工具信息，工具描述，是一種智能體所需要的“背景信息”。

比如，楊薈博士和譚老師打算，“從上海到杭州吃西湖醋魚。”大模型有上海到杭州的常識——不遠，但是為了精確，它會從高德里“查”一下距離，這也是一種“背景信息”。

第四節(jié)

為什么Uber還不支持MCP？

并不是在技術(shù)上有難度，實話說，MCP沒啥技術(shù)挑戰(zhàn)。

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

人家才不愿意這樣做。

假如，美團接入MCP協(xié)議，某個智能體就能幫著點外賣。

且這個智能體很熱門，用戶超級多，美團可能就扛不住了。

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

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

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

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

再講一個例子，網(wǎng)頁解析器是一種服務(wù)，能讀取和分析網(wǎng)頁內(nèi)容。

例子：假設(shè)你想在所有電商平臺里比價，以確保買到最便宜商品，那得知道多個電商平臺該商品的價格變化，手動比價很費事。

但是，智能體有調(diào)用網(wǎng)頁解析器服務(wù)的能力，讓智能體“看”網(wǎng)頁上的價格信息，并定期通知你價格的變化。淘寶，京東，PDD自動比價。

你覺得，電商平臺會允許這種全平臺比價智能體，拿到真實且實時的價格嗎？

價格，多敏感的商業(yè)信息，很可能成立專門的團隊，“阻止”任何組織或個人成批量“拿走價格”，別問我怎么知道的。

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

當(dāng)這些互聯(lián)網(wǎng)門戶級APP，考慮要不要做MCP Server的時候，他們擔(dān)心的是：這么多年砸錢無數(shù)積攢下來的用戶入口地位，把用戶入口讓給了調(diào)用這個服務(wù)的廠商，那要問一句，憑什么讓給你？

愿意支持MCP的 APP，往往是開放接口吸引更多用戶，推動標(biāo)準(zhǔn)化并構(gòu)建生態(tài)系統(tǒng)的公司。不愿意支持MCP的APP，則是那些核心競爭力依賴數(shù)據(jù)敏感性，用戶入口是核心資產(chǎn)，或傾向于封閉生態(tài)的公司。

這種差異反映了不同企業(yè)，在面對技術(shù)變革時的戰(zhàn)略選擇，也揭示了技術(shù)標(biāo)準(zhǔn)推廣過程中不可避免的博弈。

第五節(jié)

“入口大戰(zhàn)”又來了？

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

原本由平臺APP掌控的“商業(yè)模式設(shè)計權(quán)”，現(xiàn)在有可能轉(zhuǎn)移到智能體開發(fā)者手中。

平臺必須重新思考如何適應(yīng)這種變化，否則可能被淘汰。

表面上，MCP的出現(xiàn)是為了提升效率和開放性，但實際上它觸及了商業(yè)深層邏輯：數(shù)據(jù)控制權(quán)、生態(tài)系統(tǒng)主導(dǎo)權(quán)、商業(yè)模式設(shè)計權(quán)，以及行業(yè)規(guī)則制定權(quán)。

誰能主導(dǎo)MCP或者類似協(xié)議的發(fā)展，誰就能在未來商業(yè)版圖中占據(jù)有利位置。

只要智能體做大了，誰不兼容這款“智能助理”，誰就損失銷售機會。

MCP這個事情的成敗，取決于智能體繁不繁榮了。

然而，這是一個雞生蛋，蛋生雞的問題。

首先，智能體要能切實給用戶解決真正的問題，生活方便，上班簡便。

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

智能體想有用戶，想普及，就得能干很多活；但是反過來，而人類大部分的需求：出行（滴滴），購物（淘寶），點外賣（美團），都有大型APP占據(jù)，遠看星辰大海，近看全是紅海，看上去智能體想找份“體面工作”，就業(yè)機會不多，智能體若是沒有工作機會，自然沒有用戶。

這是什么局面？

有點像早期互聯(lián)網(wǎng)：網(wǎng)頁少的時候給，搜索引擎的價值小；有海量網(wǎng)頁的時候，搜索引擎才有江湖地位，網(wǎng)頁創(chuàng)作者也會主動優(yōu)化內(nèi)容，以迎合搜索引擎的規(guī)則。

當(dāng)智能體沒有什么用戶的時候，頭部APP不理，當(dāng)智能體很火爆，倒逼著APP廠商加入。

這是一個典型的“先有雞還是先有蛋”的問題，也就是，技術(shù)生態(tài)的啟動困境和網(wǎng)絡(luò)效應(yīng)。

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

好比，城市道路四通八達了，到交通法才有實施的意義。

如果某個小地方只有一條10米的路，交通法的意義也體現(xiàn)不出來。

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

楊薈博士認為：距離企業(yè)級智能體需求爆發(fā)，還有些時日，但來日不遠。

第六節(jié)

哪種軟件最適合封裝成MCP？

看上去，你跟一個工具（MCP Server）說話，它不會“思考”，只會干它會做，且有限的幾件事。

而智能體要復(fù)雜得多，擅長理解，記憶，邏輯推理，這個視角下，大部分工具（MCP Server）像一個電飯鍋，而智能體像廚師團隊。

要我說，電飯鍋（MCP Server），功能穩(wěn)定，只要按鍵就工作，不記得你之前讓它干啥，也不會主動去想你下一步要做什么。

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

這種最適合封裝的“工具（MCP Server）”，其實是那種本身不需要智能的工具，或者說，不需要智能決策和判斷的工具。

像訂機票，訂酒店，所以，當(dāng)下，而大多數(shù)工具（MCP Server），都是“輕量型”的，如何托管，如何設(shè)計這樣一整個“廚師團隊”，不是誰都有的能力，這是智能體創(chuàng)業(yè)團隊的機會。

第七節(jié)

哪種軟件系統(tǒng)擁抱MCP最積極？

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

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

擁抱MCP的軟件（服務(wù)商）的數(shù)量還在快速增加，那么問題來了：為什么數(shù)據(jù)庫擁抱MCP最積極？

寫這節(jié)的時候，有個群友問：是數(shù)據(jù)庫擁抱MCP，還是MCP擁抱數(shù)據(jù)庫？

這不是文字游戲，在MCP面前，MCP是一種協(xié)議或標(biāo)準(zhǔn)，本身是中立的，它并不會主動去“擁抱”某個具體的技術(shù)或系統(tǒng)。

相反，軟件（如數(shù)據(jù)庫、工具、應(yīng)用），需要根據(jù)MCP的規(guī)范進行改造，以實現(xiàn)兼容性。

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

英語來了，不是用“英語”把數(shù)據(jù)庫重寫一遍，而是，數(shù)據(jù)庫“適配”英語，好比，增加一個會說英語的接口，套用這個比方，數(shù)據(jù)庫了增加會講“MCP語言”的“服務(wù)窗口”，數(shù)據(jù)庫不直接和消費者互動，沒有用戶入口丟失的擔(dān)心。

數(shù)據(jù)庫希望被使用得多越多好，擁抱MCP當(dāng)然積極。

楊薈博士還補充了一個觀點，智能體有一個剛需——長短期記憶，加上數(shù)據(jù)庫就相當(dāng)于擴展了智能體的記憶容量，所以，智能體想做大，可以沒有美團的MCP，可以沒有阿里天貓的MCP，但不能沒有數(shù)據(jù)庫，按說，大的數(shù)據(jù)庫的廠商動作還沒有這么快，不過，不包括Clickhouse，人家原廠已發(fā)布MCP Server。

第八節(jié)

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

是楊薈博士的一個觀察。

好遺憾，它們在等啥，為何還沒把智能體放進去。

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

但智能體是行為復(fù)雜，成本不易控，結(jié)果不確定的實體。

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

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

像API商店：而不是“智能體服務(wù)市場”。

為什么？

智能體玩的是，我有一群助理，能一起幫你想事、做事、配合安排。

就好比，大模型外掛智能體，智能體在外掛智能體，禁止俄羅斯套娃梗。

不過，萬事都有開頭。

在“大模型只輸出想法”的前提下，智能體作為“行動層”，真正做事的那一層，它要靠什么爆發(fā)？

我們認為：智能體的蓬勃發(fā)展取決于，它是否擁有，“通用行動能力+高質(zhì)量工具生態(tài)+可組合的系統(tǒng)結(jié)構(gòu)”——這三者共同形成，“AI動作系統(tǒng)”的地基。

楊薈博士說，當(dāng)下看來，第一波的影響力作用于APP。第二波的影響力才作用于AI產(chǎn)品。

為什這么說？

美團可能不愿意兼容MCP，寧愿自己造智能體。

這是天然的阻礙。

怎么辦呢？

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

好比，你進風(fēng)景去游玩的時候，公共交通不會帶你直達景點核心地帶，比如，公交車會停在八達嶺長城烽火臺門口嗎？

多數(shù)大景點都有“擺渡車”，一般來說，干一件大事哪怕里面有好幾件小事，雖然美團這類平臺不支持MCP，但是可能會積極支持，“智能體對智能體協(xié)議”，例如谷歌剛剛發(fā)布的Agent to Agent（A2A）。

這就好比，當(dāng)智能體A進入美團，先遇見一個美團前臺，其實是智能體B。后續(xù)，關(guān)于點外賣的一切相關(guān)事宜，美團前臺，也就是智能體B，接手了。這時候，MCP沒用了，請用智能體和智能體的“語言體系”來溝通。于是，智能體對智能體的協(xié)議，會日顯重要，

市場的情況，要過數(shù)月才能清楚，不過我們引入了一個新概念。

A2A。

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

第九節(jié)

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

因為MCP協(xié)議本身有些局限性，接入這套協(xié)議的有兩個角色：智能體的生產(chǎn)廠商和外部工具開發(fā)商。

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

為什么？

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

比如，智能體廠商希望工具封裝成MCP，美團滴滴攜程去哪兒這種APP越多接入越好，尤其是APP平臺。

例如，美團、滴滴、攜程，這些平臺越多外部工具接入，它們就越能獲得更多的流量，但它們又不希望自己的核心能力，被第三方工具取代。

智能體的生產(chǎn)商往往不愿意把自己的智能體，封裝成MCP，尤其是當(dāng)它們的智能體已有用戶群體時。

可以說，它們更愿意選擇MCP+A2A雙重封裝，相當(dāng)于同時擁有兩種接入方式。

也就是說，它們希望“工具”能夠主動入局，但并不是所有的“工具”都有動力去接入MCP，尤其是那些頭部的APP，智能體的崛起也可能會削弱APP平臺的控制力。

APP確實很強勢，若被智能體繞過了入口，麻煩很大。

假如全世界的大小餐廳老板手機里就有智能體，可以提供點餐，下單，吃貨評價，外賣等多個服務(wù)功能；全世界的吃貨，也都有手機智能體，這吃貨們的手機智能體對接大量餐廳智能體，還需要美團干嘛？美團情何以堪？

再總結(jié)一下，如果終端用戶（消費者）擁有的智能體和商品/服務(wù)真正提供方的智能體能用A2A協(xié)議直連，那么它們就繞過了APP平臺。

因此，A2A協(xié)議可能成為智能體沖破發(fā)展障礙的關(guān)鍵。

第十節(jié)

阿里云拿什么樣的動力擁抱MCP？

要我說，動力可太多了，國內(nèi)頭部云計算廠商里旗幟鮮明地支持MCP的，確實只有阿里云了。

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

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

智能體在當(dāng)前的AI產(chǎn)品生態(tài)中，占據(jù)了一個非常重要的地位，不僅是新技術(shù)，更是一種全新的產(chǎn)品形態(tài)。

對阿里云來說，任何有利于智能體生態(tài)發(fā)展的事，都應(yīng)該多做。

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

這波阿里云吃虧只有一種可能：萬一智能體完全是個泡沫

我認為，其他廠商現(xiàn)在沒吶喊支持，一部分是因為資源有限，或者，還在考慮怎么支持，如何支持。

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

一是百煉開了智能體商城，二是無影云電腦搞了個智能體的運行環(huán)境，名叫AgentBay。

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

一個是智能體商城（百煉），一個是商城里的旗艦店（AgentBay）。

舊邏輯里，云廠商的價值就是讓IT更簡單，新邏輯還在形成，我觀察，無影是阿里云原廠原裝的云電腦，既然智能體需要操作一個“電腦”，那么無影肯定爭先恐后，也就是說，就有很多事情可以做。

AgentBay這個產(chǎn)品，是帶電腦操作系統(tǒng)界面的虛擬機服務(wù)。

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

不就是一個“操作間”嗎，有操作環(huán)境，且能在這里面加裝備。阿里云就是開發(fā)環(huán)境和裝備的廠商。現(xiàn)在智能體作坊，明日智能體工廠。

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

有時候，一般的本地設(shè)備（辦公電腦），難以支撐高并發(fā)，高算力需求的智能體，還有時候，任務(wù)執(zhí)行時，會占用本地計算資源和操作權(quán)限，也就是一種“我的電腦”，被智能體“霸占”的即視感。

嚴(yán)謹?shù)卣f，阿里云的目標(biāo)是，讓開發(fā)者無需自己搭建和配置虛擬機，而是直接用阿里的虛擬機環(huán)境來開發(fā)智能體。

省流版說法：WeWork辦公區(qū)，誰用誰留，用完就走。

以無影云電腦為例，對比一下，如果不使用MCP協(xié)議，智能體仍然可調(diào)用無影的虛擬操作間服務(wù)，但前提是，智能體開發(fā)者需要閱讀虛擬操作間的API文檔，并手動代碼調(diào)用這些服務(wù)。

也就是說，開發(fā)者需要在代碼中明確“告訴”智能體，該如何操作以及各種細節(jié)。

而如果使用MCP協(xié)議，智能體則能自動讀取，MCP協(xié)議中的相關(guān)操作指南，智能體自行決定如何調(diào)用。

像Manus這樣操作電腦的產(chǎn)品，云上“包間”做得好，高效和安全就都有了。

這件事對云廠商有多重要呢？如果云廠商不做好，會有人替你干好。

那就是大模型廠商，干得好，且取得壟斷地位后，就能繞開了云廠商。

所以，對智能體，云計算廠商都會不遺余力，而且，要我說，一舉兩得，云平臺按需計費的模式，為智能體開發(fā)者提供彈性計算資源，從而增加收入。

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

比如，智能體用了阿里云PolarDB數(shù)據(jù)庫，阿里數(shù)據(jù)庫部門就可以賺到錢，其他云廠商也一樣。

不僅能夠賺錢，取得規(guī)模效應(yīng)后，有機會成為“智能體商店”的所有者，就看阿里云有沒有實力運營智能體時代的淘寶。

第十一節(jié)

有MCP，為什么谷歌還出A2A？

阿里現(xiàn)在支持MCP，日后也會支持A2A嗎？

這是個好問題。

谷歌A2A博客說，它和MCP的關(guān)系是補充關(guān)系，但不夠本質(zhì)，A2A協(xié)議意味著，智能體服務(wù)里的兩個角色都是智能體，智能體A和智能體B，甚至就可以人類自然語言交流，還需要MCP協(xié)議嗎？

為了干活的目標(biāo)，智能體B在理解了智能體A的意圖之后，智能體B自己決定的如何提供服務(wù)。

B提供給A服務(wù)，B服務(wù)A，這里用甲乙方的比喻比較貼切。

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

有可能，因為在端入口，智能手機廠商話語權(quán)最大，硬件控制軟件，這是房東和租客的關(guān)系，手機廠商對APP廠商始終有降維打擊的能力。

我們暢想日后，人形機器人的數(shù)量超過了手機的數(shù)量，機器人廠商就是房東了。

楊薈博士和我討論時談到，悲觀的專家也在發(fā)聲，智能體泡沫太大。

智能體的瓶頸沒有暴露出來，有個觀點是，智能體也許沒有瓶頸，因為只有智能體大量被用戶使用，積累真實的使用數(shù)據(jù)后，智能體改進的過程中，才能看清天花板到底在哪。

A2A協(xié)議還得再新開一篇，歡迎專家前來交流。

第十二節(jié)

舉個例子

舉個西湖醋魚的例子，體會MCP的方便之處，尤其體會，

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

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

以后：智能體，

這時候，我想再聊聊MCP里的字母C是什么？

是Context，直接翻譯是“上下文”，那到底什么是上下文？

智能體需要理解的，為了達成用戶的（楊薈博士和譚老師）目標(biāo)，用戶雖然沒說，智能體也應(yīng)該知道的信息。

MCP協(xié)議通過標(biāo)準(zhǔn)化的數(shù)據(jù)結(jié)構(gòu)和接口，將“上下文”傳遞給智能體。

智能體的常識里有：

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

2.西湖醋魚是杭幫菜；

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

第一，城市地區(qū)，出行看天氣，出發(fā)和到達城市天氣；第二，推薦餐廳，地點在杭州西湖景區(qū)，第三，口味，杭幫菜。第四，選擇出行方式，比如開車、騎車、步行。

再次確認杭州到上海精確距離182公里，開車大約三小時可到達，但只有約1/10000的用戶喜歡騎車去，幾乎沒有人喜歡從走路去。

所以，智能體會幫楊薈博士和譚老師，挑選自駕的方式。

接下來，智能體“調(diào)用”美團，第五，選擇“樓外樓”（孤山店）餐廳；

解釋一下，這是美團內(nèi)部評分排序算法得出的結(jié)果，到底智能體能獲取前三名，還是前五名，這取決于美團寫MCP協(xié)議的時候，至于返回幾個最佳上榜餐廳，至于是取前三強，或者前五強，由美團決定；也就是說，MCP協(xié)議只規(guī)定格式，格式里的細節(jié)由美團決定，由美團的工程師在開發(fā)MCP工具時考慮。

還可以調(diào)用Agentbay里的瀏覽器能力，搜索下小紅書相關(guān)話題下面的口碑評價，添點笑料，最后，西湖醋魚上桌。

最后的最后，作為一個杭州人，譚老師告訴楊薈博士，如果你覺得西湖醋魚難吃，那一定不正宗，因為正宗的更難吃。

本文來自微信公眾號：親愛的數(shù)據(jù)，作者：楊薈博士，親愛的數(shù)據(jù)（譚婧）

想要第一時間了解行業(yè)動態(tài)、面試技巧、商業(yè)知識等等等？加入產(chǎn)品經(jīng)理進化營，跟優(yōu)秀的產(chǎn)品人一起交流成長！