MCP被Linux基金會托管！智能體互聯互通，豆包手機有救了？

最近封禁「豆包手機」（nubia M53）的 App 名單越拉越長了。不只是微信、支付寶，拼多多、淘寶等電商平臺以及更多銀行類應用，也都開始不同程度禁止用戶在豆包手機上登錄和使用。

這不是簡單的產品之爭。

一句「幫我比價下單」，手機頁面開始自動跳轉、識別界面、點擊按鈕、領券、結算，全程不依賴任何官方接口。豆包手機助手走的是典型的 GUI Agent 路線——讓 AI 看懂手機界面，直接模擬用戶在 GUI（圖形用戶界面）上進行操作。

類似的還有被亞馬遜嚴正警告的 Comet AI（知名 AI 搜索初創公司 Perplexity 旗下），尚且還是在相對開放的 Web 世界，而豆包手機助手面對的則是巨頭林立的 App 世界。

Perplexity 對亞馬遜的回應，圖片來源：Perplexity

關鍵在于，整個互聯網生態都還沒有準備好承接 GUI Agent 對系統權限、平臺秩序和安全邊界的「野蠻沖擊」。

相較之下，基于 MCP（Model Context Protocol，大模型上下文協議）的 Agent 模式，雖然也不可能從解決 AI 時代的所有平臺矛盾，卻給出了一條「通往共贏之路」。

就在 12 月 10 日，Anthropic（開發了 Claude）宣布將 MCP 正式捐贈給新成立 Agentic AI（智能體 AI）基金會，由 Linux 基金會統一托管。如果說 GUI Agent 依舊沿用的是「AI 模仿人類點手機」的舊邏輯，那么 MCP 嘗試回答的是：

智能體時代的互聯網，必須擁有一套屬于 AI 的開放互聯協議。

從小眾到共識，「真·AI 互聯網協議」來了

MCP 協議不是一個新的概念。今年 4 月接受財聯社采訪時，阿里云智能集團資深副總裁劉偉光就表示，MCP 是今天公認的業界標準：

「在 MCP 之前有很多人嘗試過函數調用、提示詞工程、插件等方式，今天 MCP 通過統一標準接口，類似于今天電腦手機當中看到 USB-C 接口，這樣一種標準接口降低大模型和外部系統的集成門檻。」

毫無疑問的是，在 Anthropic 正式捐贈之前，MCP 協議其實就初步成為了一種「事實標準」。

最開始，MCP 只是 Anthropic 工程師為 Claude 做的一個「統一工具接入規范」。為了解決大模型在調用外部工具、讀取本地數據時必須反復編寫適配代碼的問題。開發者只要遵循 MCP 這一套 JSON-RPC 協議，就能用一個統一方式把文件系統、數據庫、業務工具接入 Claude。

一種形象的解釋，圖片來源：Norah Sakal

簡單、直接、可復用，是 MCP 在早期被工程師口口相傳的原因。可從 2024 年中開始，這套規范開始在行業內迅速蔓延：

- VS Code、Cursor、Windsurf 等新一代開發環境集成 MCP；

- OpenAI 在官方文檔里將 MCP 視作首選擴展路徑；

- Google 的部分內部 Agent 工具鏈也開始基于 MCP ；

- 阿里、字節、騰訊的工程團隊也在項目中用 MCP 作為 AI 系統的互聯方式；

到了 2025 年，「支持 MCP」已經成為 Agent 類產品的標配。事實標準，就是在這種群體無意識的默契中自然形成的。

過去二十年，互聯網的運行依賴 HTTP、TCP/IP、OAuth 這些共識。而智能體要想在手機、PC、云服務乃至企業系統間自由地交換信息、調用工具，也必須擁有自己的「協議層」。今天來看，MCP 就是目前的最佳答案。

盡管 MCP 早已開源，但協議被捐贈給 Linux 基金會（目前全球最負盛名的開源基金會），更意味著 MCP 不再屬于某家公司，而是像 Linux、Kubernetes、OpenAPI 等開源項目進入更中立的治理體系。

AI 的世界，需要一套不依賴任何巨頭、可被所有模型與平臺共同遵循的底層協議。這大概就是這次 MCP 捐贈發出的一個強烈信號。

另一方面，Agentic AI 基金會的「開山項目」其實不只是 MCP，還有 OpenAI 捐贈的 AGNTS.md ——網站和應用給 Agent 寫「使用說明」的標準，以及 Google 捐贈的 Block——構建智能體和工作流的框架。

此外，Google 隨后也推出了自家完全托管的遠程 MCP 服務器，可以將智能體 AI 更輕松地接入 Google 及其云端服務（如地圖、BigQuery 等），直接調用如 Google 地圖的真實數據和工具。而今年更早時候，阿里云百煉平臺其實就已經推出了全生命周期的 MCP 服務，包括 MCP 服務器。

比如高德 MCP 服務器，圖片來源：高德地圖

今天不是某一家押注 MCP，而是整個 AI 行業在「底層連接方式」上形成了普遍共識：未來的 AI 體驗不會只依賴某個模型，而是依賴一種可互操作、可治理、可跨平臺流動的語言。

從這個角度，MCP 則是那個「被選召的孩子」。

理想情況下，未來智能體 AI 不用偽裝成人類點擊網頁，而可以直接、合法地「幫用戶比價下單」，平臺也能保留監管與服務能力。不過，基于 GUI 的 Agent 是不是作為一種過渡手段就要走入歷史？恐怕也不然。

GUI 走不通的路，只能交給 MCP

上月初，雷科技報道了《亞馬遜警告 Perplexity，智能體與互聯網平臺終于一戰？》，Comet AI 通過爬取商品頁、解析頁面，把「購買建議」「價格趨勢」「商品篩選」直接呈現給用戶，繞過了在線購物平臺的推薦體系和廣告鏈路，也引起了亞馬遜的強烈反對。

本月初，雷科技也報道了《豆包手機助手調整權限！AI 手機是洪水，但不是猛獸？》，豆包手機助手在 GUI 層執行的 App 操作引發了更大程度的爭議。

事實上，這種矛盾也不是這兩個月才有的。微信很早就旗幟鮮明地反對 GUI 路線，早在 3 月就有網友發現榮耀 YOYO 智能體無法再「操作」微信，華為、vivo、魅族等其他手機廠商的「智能體 AI」也不例外。

在宣傳時還有微信，圖片來源：榮耀

要理解這種沖突，首先必須理解從智譜 AutoGLM 到 Comet、豆包手機助手，為什么都要基于 GUI 路線？

核心不難理解：互聯網并沒有準備好擁抱智能體 AI。

MCP 雖然已經初步獲得了各大 AI 公司的認可，但整個互聯網生態還有太多功課要補，而基于 GUI 的通用方案則是早期階段唯一能大規模跑起來的方式——不依賴平臺配合，不等待改造，只要有用戶界面就能「操作」。

但正因為它「無所不通」，現實中的矛盾也來得同樣迅速。基于GUI 交互的智能體 AI 跳過了產品邏輯、商業鏈路和風控體系，讓平臺無法控制智能體 AI 在什么場景、以什么方式與用戶數據和關鍵操作發生關系，一旦出現誤操作，責任邊界立刻模糊。

就在豆包手機助手引發爭議的同時，工信部下屬中國信通院也牽頭發布了《端云協同智能體交互雙重授權安全指引》，重點提到了「構建由用戶和應用雙重授權的安全機制」，明確智能體 AI「需同時獲得應用授權與用戶授權，才能合法訪問第三方應用」。

圖片來源：中國互聯網協會

不是豆包手機助手「太激進」，而是 GUI 路線與平臺生態天然難以長期共存。一個耐人尋味的例子是，去年 10 月最早基于 Claude 推出「Computer Use」（同樣基于 GUI 路線）的 Anthropic，在 MCP 之后基本放棄了這條路線的對外更新。

圖片來源：Youtube

而與 GUI 試圖「模擬用戶」不同，MCP 試圖為智能體 AI 建立一條「正式入口」，讓平臺第一次可以把與智能體 AI 互動的邊界顯性化：哪些能力可讀、哪些操作必須二次確認、哪些業務永遠不開放，都可以在協議層直接寫清楚。

更重要的是，MCP 將智能體與系統之間的關系，從「依賴 UI」提升為「依賴能力」。比如 GUI 路線下「查訂單」，需要打開 App 讀取界面、解析文本、定位按鈕，再經過多次操作才能知道；但在 MCP 模式下，可能只是一次明確的能力請求：查詢、返回、處理。

當然，MCP 意味著整個互聯網生態需要經歷「一場漫長的改造」，也意味著基于 GUI 路線的智能體 AI 的體驗不可能完全放棄。

接下來很可能不會是二者的簡單取舍。

GUI 會繼續作為「兜底」，讓智能體在未改造完的舊世界里繼續前行；MCP 則會成為跨系統、跨平臺的底層互聯方式，為智能體建立清晰的權限、邊界與秩序。

而在這兩者之上，終端設備上新的系統級智能體能理解用戶的目標，協調設備、平臺與服務，并在平臺規則之內完成跨生態、跨智能體任務。簡言之：

OS 提供統一智能體入口和權限管理，MCP 等協議負責和各家服務溝通，Qwen、Gemini、GPT 之類模型可以被插拔，變成「換大腦但不拆線管」的狀態。

這可能才是智能體 AI 的終局。

雷科技2025“年度燈塔產品榜”評選啟動！致敬堪稱“科技之光、時代大作”的科技產品，歡迎關注～