MCP 在網路巨頭中反應平淡:解析

隨著人工智能(AI)互操作性的討論日益激烈,繼百度在上週的開發者大會上宣布其全面的 MCP 服務後,阿里巴巴、字節跳動和騰訊等中國主要科技公司也都開始了 MCP 之旅。

MCP,或模型上下文協議(Model Context Protocol),被設想為一種統一的標準,使 AI 能夠與眾多應用程式和服務無縫連接。它可以比作電腦和智能手機中普遍存在的 USB 接口,允許各種外部設備的即插即用集成。 本質上,MCP 旨在為 AI 提供一個通用的 ‘USB 端口’,以訪問工具和執行任務。

2024 年 11 月,美國 AI 公司 Anthropic 推出了 MCP 標準,該標準迅速被 OpenAI 和 Google 等競爭對手所採納,這標誌著與傳統的專有生態系統競爭慣例背道而馳。 從 4 月開始,包括阿里巴巴雲的百煉、騰訊雲的知識引擎、字節跳動的扣子空間和百度 AI 雲在內的中國領先科技公司都推出了自己的全面 MCP 服務。

統一的承諾與挑戰

MCP 的主要目標是促進統一,但這項工作面臨著重大的挑戰。 根據多位開發人員和研究人員的說法,雖然 MCP 在訪問本地企業數據方面有效,但在嘗試與互聯網應用程式集成以執行諸如預訂航班、查詢價格和創建旅行指南等任務時會遇到障礙。 這些挑戰源於 AI 調用過程的不成熟以及互聯網工具的可用性有限,許多平台僅提供對外圍功能的訪問。

並非所有互聯網平台都同樣熱衷於採用這種通用標準並加入 MCP 服務提供商網絡。 中國互聯網生態系統的封閉性質,加上對數據隱私的高度敏感,使得許多平台持謹慎態度。 他們更願意在完全致力於此之前評估 MCP 生態系統的可行性和發展。

AI 領域以其快速發展的術語和概念而聞名。 當 Anthropic 去年年底最初開源 MCP 協議時,該行業在很大程度上採取了觀望態度。 然而,Manus 的爆炸性普及從那以後推動了中國國內對 MCP 的興趣。

MCP 作為 AI 代理的催化劑

根據華中科技大學的侯欣怡的說法,超越 ‘聊天機器人’ 局限性的關鍵步驟在於使 AI 能夠與外部數據和工具進行交互,這正是 MCP 試圖促進的。

在 MCP 之前,人們探索了其他方法來解決人們認為缺乏 ‘AI 代理’ 的問題。 2023 年底,OpenAI 推出了應用程式商店(GPT Store)的概念,允許 ChatGPT 通過基於一組定義標準的插件來利用外部工具。 類似的 AI 應用程式商店,例如字節跳動的扣子、百度的千帆和阿里巴巴的百煉,也紛紛效仿。

然而,這些方法最終達到了極限。 插件和應用程式商店面臨一個共同的問題:孤島化。 每個工具都擁有自己獨特的開發文檔、參數格式和接口規範。 這意味著開發人員每次將新工具集成到 AI 中時都必須重新發明輪子,從而導致效率低下。

隨著時間的推移,添加到應用程式商店的新工具的數量減少,並且插件的質量差異很大,從而阻礙了解決複雜任務的能力。 這表明現有方法正在接近極限。

MCP 作為一種統一的解決方案

MCP 被視為一種有希望的解決方案,因為它強調統一。 在其官方文檔中,Anthropic 將 MCP 比作 AI 世界的通用 USB-C 接口。 侯欣怡更喜歡將其描述為 ‘對接站’,一種多功能的適配器,允許 AI 同時連接到多個外部工具,而無需格式轉換。

許多人預計 MCP 將產生變革性的影響,類似於秦始皇統一度量衡,這促進了春秋時期各個分裂國家之間的貿易和交流。

根據一家大型科技公司的智能互連工作組的技術負責人的說法,MCP 還優化了 AI 的語言交互。 以前,AI 需要用戶精確地說 ‘我想導航’ 才能使用導航服務的 API。 即使是輕微的偏差也可能導致 AI 失敗。 現在,每個工具都必須提供標準化的名稱、參數和功能描述。 因此,AI 只需要理解用戶的意圖,然後根據描述將其與最合適的 MCP 服務器進行匹配。

這種方法更符合大型語言模型的固有能力,使用戶只需一句話即可調用服務,而擺脫了以前對直接接口到接口通信的要求。

MCP 目前的採用和局限性

儘管 MCP 具有公認的潛力,但尚未得到廣泛採用,並且其實際應用仍然有限。 目前,MCP 在企業技術人員和獨立開發人員中最受歡迎。

作為一名前端工程師,龔典非常依賴 AI 編程助手 Cursor。 然而,Cursor 一直難以與他公司的內部項目系統無縫集成,需要人工干預。 雖然以前可以使用插件或函數調用,但外部 AI 無法訪問公司的內部系統,並且實時調用引發了安全問題。 另一方面,MCP 可以在公司內部網絡中啟動,使其更加可靠和合規。

獨立開發者 Zhu Mama 最近指示 Cursor 學習 MCP 文檔並將 Google Maps 和 Search API 打包到 MCP 服務器中,然後該服務器用於調用 Google 的 Gemini 大型語言模型。 由此產生的配備 MCP 的 Gemini 被轉換為旅行指南助手。 當被問及從新加坡機場到各個景點的公共交通路線時,與 Doubao 的回答相比,該助手提供了更詳細和準確的信息。

各種旅行助手正在開發人員社區中湧現。 當字節跳動的扣子空間於 4 月 19 日推出其內部測試版時,演示案例也是一個旅行 AI 助手,促使一些人開玩笑說該行業痴迷於旅行。

Zhu Mama 坦率地承認,對旅行場景的關注主要是因為它們與日常消費者需求相關。 另一個原因是中國 MCP 兼容的互聯網軟件的可用性有限,這限制了市場的潛力。

根據導航平台 MCP.so 的最新統計數據,全球有超過 11,028 家 MCP 服務提供商,並且數量正在迅速增長。 然而,在中國,目前只有少數主要的地理位置應用程式(例如 AutoNavi、Baidu Maps 和 Tencent Maps)充當大型 MCP 服務器。

這種局限性就是 Zhu Mama 創建中文版旅行助手的計劃很快停滯的原因。 為了開發中文旅行指南,理想情況下是利用國內地圖服務。 然而,Zhu Mama 發現 AutoNavi 提供的官方 MCP 服務器提供的信息非常有限。 雖然它可以提供兩個位置之間的路線查詢,但它缺乏有關地標、評論、酒店票價和其他基本細節的詳細信息。

相比之下,Google Maps API 提供了詳細的預訂方法、酒店價格、酒店評論、酒店設施,甚至跨多個平台的價格比較,這種詳細程度在中國生態系統中很難想像。

雖然騰訊、阿里巴巴、字節跳動和百度的產品都在擁抱 MCP,但他們的高頻應用程式尚未正式加入 MCP 服務提供商網絡。 微信、小紅書和抖音等平台,以及餓了麼、美團和攜程等生活方式服務平台明顯缺席。

工具可用性和 AI 調度方面的挑戰

除了工具的可用性有限之外,AI 的調度能力也構成了一種限制。 Zhu Mama 將 6-8 個 API 接口(包括 Google Hotels、Maps 和 Search)打包到一個 MCP 服務器中,遠低於最大限制(Cursor 允許每個代理最多 40 個工具)。 然而,AI 已經難以確定要調用哪個工具。 當面臨複雜請求時,AI 無法分解該過程並分階段調用 MCP,而是試圖一次處理所有事情。

根據龔典的說法,MCP 的價值取決於客戶端和服務器端的質量。 正如 USB 端口沒有固有的功能並且依賴於其背後的服務一樣,MCP 需要強大的服務才能實現其潛力。

MCP 為 AI 代理奠定了基礎,但它並不能解決所有問題。 一個未被使用的標準只是一張紙。

上述技術負責人表示,Anthropic 的 MCP 標準得到廣泛採用是因為它的開源、非營利性質及其創建者的信譽。 其他組織願意遵循信譽良好的實體制定的標準。

目前,尋求多元化收入來源的中小型公司和大型互聯網公司是 MCP 標準的主要採用者。

AI 陪伴公司 MiniMax 最近推出了一個 MCP 服務器,社區經理蔡佳人表示,開發人員可以使用 MCP 調用 MiniMax 的多模式功能,用於視頻生成、語音生成和語音克隆。 MCP 包括嚴格的訪問控制機制,以確保企業訪問內部數據時的合規性。 整體調用過程也得到了簡化,而沒有增加額外的 token 成本。

MiniMax 決定推出 MCP 服務器的推動力是希望使全球開發人員能夠輕鬆利用 MiniMax 的模型功能,並釋放更靈活和高效的創作。

其他初創公司也有類似的願望。 Biu Technology 在一次採訪中提到,開發人員可以使用 AutoNavi MCP 獲取交通數據,然後使用 Biu 的產品生成 PPT。 MCP 通過提供對 AutoNavi 接口的訪問來降低了進入門檻,否則他們將無法使用該接口。

上述技術負責人認為,MCP 本質上是一個關於服務提供商的故事。 通過根據 MCP 標準封裝其 API,應用程式服務提供商可以使其服務可供所有 AI 訪問。

服務提供商之間的分歧和擔憂

然而,服務提供商之間出現了分歧。 許多公司並未完全致力於這一想法。 雖然像 AutoNavi 和 Baidu Maps 這樣的平台已經推出了 MCP 服務器,但它們主要重新包裝現有的 API 接口,提供傳統的功能,同時保持對核心用戶權限和交易數據的嚴格控制。

除了地圖定位服務外,第三方開發人員的小紅書自動發佈器(可自動搜索和發佈內容)目前是 Modeng 社區 MCP 廣場上最受歡迎的項目。 侯欣怡表示,這可能對像小紅書這樣的社交內容平台影響有限,但在食品配送平台等交易密集型場景中,數據和權限變得尤為敏感。

服務提供商的主要擔憂之一是用戶體驗的控制。

例如,開放完整的食品配送服務需要授予 AI 代理訪問敏感個人數據的權限,例如價格、商店信息以及用戶地址和聯繫方式。 Anthropic 已經承認 MCP 的安全系統(包括權限管理和調用審計)仍在開發中。 因此,一些平台擔心連接到 MCP 時存在未經授權調用的風險。

一些平台正在測試相對安全的交易場景。 例如,支付寶最近推出了一個 MCP 服務器,聲稱讓 AI 代理 ‘一鍵訪問支付功能’。 然而,仔細觀察發現,它主要提供收款而非支付服務。

根據侯欣怡的說法,支付寶的方法側重於促進商戶的收款,而不是允許 AI 代表消費者進行支付。 這是一個可行的選擇,因為允許 AI 控制錢包並自由下訂單對於每個人來說還不夠安全。 這也是交易服務無法廣泛推廣的關鍵原因。

一個更深層次的問題是,如果 AI 自由參與交易過程(幫助用戶比較價格或推薦最具成本效益的餐廳),無疑會為用戶提供極大的便利。 然而,這也意味著服務平台將失去對用戶選擇過程的控制,並且其核心算法優勢將被邊緣化,從而將其降低為普通供應商。

解決安全問題並促進普及性

多位受訪者認為,MCP 需要解決兩個關鍵問題:安全性和普及性。

首先,安全性。 侯欣怡指出,MCP 面臨兩個安全挑戰:缺乏集中的安全監督以及不完整的身份驗證和數據授權機制。 目前,沒有 MCP 的官方 ‘發現廣場’。 許多第三方導航平台通過直接從 GitHub 上拉取代碼項目來收集 MCP 服務,這既快速又直接,但缺乏正式的審查過程。 Anthropic 表示,今年將正式解決 MCP 託管機制和可發現性問題。 Anthropic 最近更新的協議草案正在努力解決這一缺點。 此外,IIFAA(互聯網可信身份驗證聯盟)等國內組織正在嘗試填補安全漏洞。

AI 代理領域也存在一些長期存在的問題,例如提示劫持和工具組合攻擊。 然而,上述技術負責人認為,這些不是 MCP 漏洞,而是任何 AI 代理都存在的風險。 目前,在 MCP 協議本身中沒有發現明顯的安全漏洞,並且數據傳輸和交互機制通常是可靠的。

安全性只是第一個障礙。 真正的挑戰是克服製造商的利益防禦,並說服更多的製造商成為 MCP 服務器。

根據侯欣怡的說法,這與對互聯網平台 ‘圍牆花園’ 性質的理解有關。 數據是各種平台的重要競爭壁壘,因此許多製造商可能僅開放一些外圍功能作為 MCP 服務器進行測試。 製造商可能需要等待並觀察 MCP 生態系統將產生多大影響。

上述負責人表示,如果作為 MCP 服務器連接到 AI,它可以獲得更多的用戶數據和習慣,並反饋到自己的基礎模型,這可能成為製造商積極加入的最大動力。

當 MCP 服務器市場真正豐富時,必須考慮更遙遠的問題。

例如,智能體如何調用手機上的不同應用程式? 負責人提到,要通過手機的本地 AI 智能體喚醒另一個應用程式,將會增加一層應用程式授權和身份驗證,這不像 MCP 調用雲服務那麼簡單,目前沒有特別合適的解決方案。

再例如,當服務供應過剩時,智能體如何做出選擇 - 調用京東外賣還是美團外賣? 使用高德地圖還是百度地圖? 多位受訪者提到,今天的 MCP 調用邏輯仍然非常基本,主要由服務提供商的 ‘功能描述’ 決定,沒有排序和優化機制。 如果服務提供商故意在描述中添加誘導性語言,例如 ‘最有效’ 和 ‘必選’,則 AI 可能會被誤導並轉移到不應去的地方。

正如上述技術負責人解釋的那樣,’就像你在搜索引擎中找不到你想要的服務,但彈出了一堆混亂的信息。 如何準確匹配用戶最需要的服務,未來的 MCP 生態系統也將面臨同樣的問題。’

最終,任何標準的實施過程都充滿挑戰。 侯欣怡表示,為了推動 MCP 的普及,可能需要類似於 Manus 的關鍵機會,才能真正使整個行業認識到 MCP 的力量。