除了通用性外，MCP在其他方面的表現(xiàn)都難以令人滿意。

前不久的11月25日，AI獨(dú)角獸企業(yè)Anthropic發(fā)文慶祝MCP協(xié)議（模型上下文協(xié)議）誕生一周年。然而，如今整個(gè)AI行業(yè)對Anthropic的這一舉動即便稱不上視而不見，也可說是漠不關(guān)心，該消息在社交平臺的討論熱度幾乎為零。

但有意思的是，就在今年年初，MCP還曾一度占據(jù)AI界的頭版頭條，幾乎所有從業(yè)者都高呼“MCP讓AI連接萬物”“AI終于有了自己的USB接口”“Agent時(shí)代的基礎(chǔ)設(shè)施”?？蓛H僅半年過去，MCP就從圈內(nèi)人眼中的“香餑餑”，迅速變成了“無人問津的角落”。

那么，MCP為何會被捧上神壇，又為何迅速隕落呢？其實(shí)，這是因?yàn)镸CP的走紅本身就很反常，是“期望膨脹期”的典型產(chǎn)物。此外需要注意的是，MCP并非一推出就達(dá)到巔峰，它的走紅過程與ChatGPT、DeepSeek截然不同。

Anthropic在2024年冬季發(fā)布了MCP，但它真正被廣泛關(guān)注是在今年春季。以當(dāng)下AI的受關(guān)注程度，如果一個(gè)產(chǎn)品真有“爆點(diǎn)”，短則幾天、長則幾周就會迅速風(fēng)靡全球，比如谷歌的Nano Bonana。而MCP之所以能在春季成為AI圈的焦點(diǎn)，更像是Anthropic、谷歌、微軟等大廠共同策劃的一場“默契行動”，屬于“預(yù)先打造的爆款”。

MCP想要解決的是不同廠商的AI產(chǎn)品各自獨(dú)立、缺乏統(tǒng)一標(biāo)準(zhǔn)的混亂局面，這種局面導(dǎo)致AI模型與外部工具的交互變得復(fù)雜且不穩(wěn)定。當(dāng)時(shí)，基于不同模型的智能體（AI Agent）要想發(fā)揮作用，需要為不同功能編寫單獨(dú)的API，可不同智能體使用的“語言”各不相同。

鑒于此，Anthropic設(shè)計(jì)了MCP（Model Context Protocol），旨在通過標(biāo)準(zhǔn)化接口實(shí)現(xiàn)大語言模型（LLM）與外部數(shù)據(jù)源及工具的無縫集成。MCP就像AI應(yīng)用的USB-C接口，通過能力協(xié)商、能力發(fā)現(xiàn)、訂閱/通知等一系列機(jī)制，讓AI模型了解有哪些工具、哪些數(shù)據(jù)可用，以及如何使用這些資源。

MCP能夠直接在AI與數(shù)據(jù)、工具之間搭建起一座橋梁，通過MCP服務(wù)器和MCP客戶端實(shí)現(xiàn)AI領(lǐng)域的“萬物互聯(lián)”。要知道，當(dāng)今的互聯(lián)網(wǎng)世界正是建立在開放、互聯(lián)的基礎(chǔ)之上，所以MCP相當(dāng)于沿著TCP/IP、HTTP、USB等標(biāo)準(zhǔn)化協(xié)議的路徑前行。

不難看出，MCP是一個(gè)為智能體服務(wù)的協(xié)議，它給了智能體獲得“真本領(lǐng)”的機(jī)會，這也是MCP在今年年初走紅的原因。從某種意義上說，先有“2025年是智能體之年”的說法，之后才有MCP走到舞臺中央，而力推MCP是一眾AI大廠的共識。

在2024年的最后一天，OpenAI首席執(zhí)行官山姆·奧特曼公布了2025年該公司即將發(fā)布的技術(shù)和產(chǎn)品，當(dāng)時(shí)他將AGI（通用人工智能）排在第一位，緊隨其后的就是智能體，并且讓ChatGPT能夠自主執(zhí)行任務(wù)是2025年的一大重點(diǎn)。

如果沒有MCP，智能體要想發(fā)揮作用，開發(fā)者需要投入大量的時(shí)間和精力。MCP則為智能體提供了統(tǒng)一的工具調(diào)用規(guī)范，讓開發(fā)者從繁瑣的適配工作中解脫出來。短短三個(gè)月，就有數(shù)千個(gè)工具自發(fā)接入MCP，再加上OpenAI、AWS、HuggingFace的大力支持，似乎MCP真的要成功了。

然而，將MCP視為“萬能鑰匙”的開發(fā)者很快發(fā)現(xiàn)，事情的發(fā)展與想象的不太一樣。MCP沒有跟蹤上下文傳播，這意味著開發(fā)者無法知道AI的決策路徑中到底調(diào)用了哪些工具。此外，它也沒有截止時(shí)間傳播機(jī)制，也就是說，如果一個(gè)被調(diào)用的工具出現(xiàn)問題，智能體就會陷入停滯。

MCP在工程落地方面的挑戰(zhàn)主要體現(xiàn)在云端部署上。對于企業(yè)級用戶來說，為了應(yīng)對高并發(fā)調(diào)用，MCP服務(wù)往往需要擴(kuò)展到多服務(wù)器架構(gòu)，此時(shí)MCP的雙連接模型帶來了跨機(jī)器尋址的復(fù)雜性。當(dāng)長連接建立在一臺服務(wù)器上，而請求可能被路由到另一臺服務(wù)器時(shí)，就需要額外的廣播隊(duì)列機(jī)制來協(xié)調(diào)分散的連接，這大大增加了實(shí)施難度和維護(hù)成本。

除此之外，MCP的成本還很高。智能體在使用外部工具時(shí)，需要先收集信息并回傳給基座模型來完成決策，所以MCP要求所有工具定義、調(diào)用請求和返回結(jié)果都必須經(jīng)過模型的上下文窗口，這直接導(dǎo)致模型需要處理的上下文容量隨著MCP調(diào)用數(shù)量的增加而呈指數(shù)級上升。

簡單來說，開發(fā)者發(fā)現(xiàn)MCP雖然確實(shí)能讓自己的智能體隨意調(diào)用不同工具，但調(diào)用的工具越多，消耗的Tokens也越多。如果要減少Tokens的消耗，就必須按照非常規(guī)范的流程調(diào)用特定工具，可這樣一來，MCP的靈活性和通用性優(yōu)勢就無法體現(xiàn)出來。

實(shí)際上，這些問題還只是小毛病，MCP真正的缺陷在于，隨著調(diào)用工具的增加，智能體出現(xiàn)幻覺的概率也會同步上升。這是因?yàn)檎{(diào)用的工具越多，模型的注意力就越分散，進(jìn)而開始做出錯(cuò)誤的決策。畢竟智能體和AI聊天機(jī)器人不同，它是要“做事”的，過高的幻覺問題讓它變得食之無味、棄之可惜。

當(dāng)開發(fā)者發(fā)現(xiàn)MCP除了通用性外，其他方面都表現(xiàn)平平后，過多的缺陷讓大家紛紛選擇放棄。

【本文圖片來自網(wǎng)絡(luò)】

本文來自微信公眾號 “三易生活”（ID：IT-3eLife），作者：三易菌，36氪經(jīng)授權(quán)發(fā)布。

本文僅代表作者觀點(diǎn)，版權(quán)歸原創(chuàng)者所有，如需轉(zhuǎn)載請?jiān)谖闹凶⒚鱽碓醇白髡呙帧?/p>

免責(zé)聲明：本文系轉(zhuǎn)載編輯文章，僅作分享之用。如分享內(nèi)容、圖片侵犯到您的版權(quán)或非授權(quán)發(fā)布，請及時(shí)與我們聯(lián)系進(jìn)行審核處理或刪除，您可以發(fā)送材料至郵箱：service@tojoy.com