OpenAI與Anthropic聯手力推：MCP Apps提案發布，告別純文本交互

機器之心報道

編輯：Panda

作為連接 AI 模型與廣闊數字生態的「神經中樞」，MCP 協議已然成為智能體（AI Agent）不可或缺的基礎設施。然而，長期以來，MCP 的交互僅限于文本和結構化數據，這種「盲人摸象」般的體驗限制了更復雜應用場景的落地。

變革正在發生。

近日，MCP 社區正式提出了MCP Apps提案（SEP-1865），旨在填補這一關鍵拼圖：規范對交互式用戶界面（UI）的支持，使 MCP 服務器能夠直接向主機提供可視化的操作界面。

具體來說，MCP Apps Extension 引入了一種標準化的模式，用于聲明 UI 資源、將它們鏈接到工具，并實現嵌入式接口和主機應用之間的雙向通信。

通俗地解釋一下：過去的 MCP 就像是只能通過「發短信」來溝通的客服，它只能給你發送文字或數據代碼；而 MCP Apps 則是把這個客服升級成了能給你發送「小程序」的智能助理。 試想一下，當你要求 AI 分析服務器日志時，它不再是吐出一堆枯燥的 JSON 文本，而是直接在對話框里變出一個可視化的儀表盤，你甚至可以直接點擊圖表進行篩選和縮放；當你需要配置參數時，它直接彈出一個表單讓你勾選，而不是讓你輸入復雜的命令。這讓 AI 不再僅僅是陪聊，而是真正擁有了類似操作系統圖形界面的交互能力。

這一提案一經發布便引發了社區好評：

不僅因為它解決了開發者最迫切的需求，更因為其背后的推手陣容極其豪華 —— 該提案由 OpenAI 和 Anthropic 的 MCP 核心維護者，聯手 MCP-UI 創建者及社區主力共同編寫。

這強烈的信號表明：MCP Apps 這個基于 MCP-UI 和 OpenAI Apps SDK 的交互標準，極有可能成為未來行業的通用范式。

從「命令行」邁向「圖形化」，MCP Apps 將如何重塑 AI 交互體驗？讓我們來看看詳細解讀。

交互式界面標準化

目前，MCP 服務器僅限于與主機交換文本和結構化數據。雖然這在許多應用場景下都能很好地滿足需求，但當工具需要呈現可視化信息或收集復雜的用戶輸入時，就會產生阻礙。

官方舉了個例子：假設有一個數據可視化 MCP 服務器，它以 JSON 格式返回圖表數據。主機應用必須解析這些數據并進行渲染。在這種情況下，處理各種特殊數據會給客戶端開發者帶來沉重的負擔，他們需要構建自己的邏輯來渲染用戶界面。隨著用戶界面需求的增加，例如需要收集用戶的多個相關設置，復雜性會急劇上升。或者，如果沒有用戶界面支持，這些交互將變成笨拙的文本提示和響應交換。

MCP 社區雖然一直在積極探索如何克服這些限制，但由于不同的實現方式采用了不同的約定和架構，服務器難以在不同客戶端之間保持一致性。這種缺乏標準化的現狀會造成生態系統碎片化的風險。

共同構建中

由 Ido Salomon 和 Liad Yosef 創建并由一個活躍的社區維護的 MCP-UI 項目 ，引領了具有交互式界面的智能體應用的愿景。

該項目開發了將豐富的用戶界面作為一流的 MCP 資源交付的模式，證明了智能體應用能夠自然地融入 MCP 架構。該項目擁有龐大的社區支持，并提供豐富的 SDK ，已被 Postman、Shopify、Hugging Face、Goose 和 ElevenLabs 等領先公司和項目采用。

OpenAI Apps SDK 進一步驗證了對話式 AI 界面對豐富用戶界面體驗的需求。該 SDK 使開發者能夠以 MCP 為基礎，在 ChatGPT 內部構建豐富的交互式應用。為了確保互操作性，并在整個生態系統中建立一致的安全性和使用模式，Anthropic、OpenAI 和 MCP-UI 也正在合作開發官方的 MCP 交互式界面擴展。

MCP Apps Extension 規范

MCP 社區博客表示：「我們正在為 MCP 中的 UI 資源提出一項規范，但其影響遠不止于一系列模式轉移。MCP Apps Extension 正逐漸演變成一個智能體應用運行時（agentic app runtime）：為 AI 模型、用戶和應用之間全新的交互奠定基礎。」

該提案有意保持精簡，首先從核心模式入手，MCP 社區計劃隨著時間的推移逐步擴展。

下面介紹其關鍵設計決策。

預先聲明的資源

UI 模板是具有 ui:// URI 方案的資源，可在工具元數據中引用。

// Server registers UI resource

uri: "ui://charts/bar-chart",

name: "Bar Chart Viewer",

mimeType: "text/html+mcp"}

// Tool references it in metadata

name: "visualize_data_as_bar_chart",

description: "Plots some data as a bar chart",

inputSchema: {

type: "object",

properties: {

series: {type: "array", items: ....}

},

_meta: {

"ui/resourceUri": "ui://charts/bar-chart",

這種方法使主機能夠在工具執行前預取和審查模板，從而提高性能和安全性。它還將靜態呈現（模板）與動態數據（工具結果）分離，從而實現更好的緩存。

MCP 傳輸通信

UI 組件無需創建自定義消息協議，而是通過 postMessage 使用現有的 MCP JSON-RPC 基礎協議與主機通信。這意味著：

• UI 開發者可以使用標準的 @modelcontextprotocol/sdk 來構建他們的應用。
• 所有溝通都結構化且可審計。
• 未來的 MCP 功能將自動與 UI 擴展程序協同工作。

從 HTML 開始

初始擴展規范僅支持在沙盒化的 iframe 中渲染的 text/html 內容。這提供了以下功能：

• 通用瀏覽器支持
• 易于理解的安全模型
• 屏幕截圖和預覽生成功能
• 為未來的擴展奠定清晰的基礎

其他內容類型，例如外部 URL、遠程 DOM 和原生小部件，都將在未來的版本中實現。

安全第一

從 MCP 服務器托管交互式內容需要謹慎考慮安全性。該方案通過多層措施來解決這個問題：

• iframe 沙盒 ：所有 UI 內容都在權限受限的沙盒 iframe 中運行。
• 預先聲明的模板 ：主機可以在渲染之前查看 HTML 內容。
• 可審計消息 ：所有 UI 與主機之間的通信都通過可記錄的 JSON-RPC 進行。
• 用戶同意 ：主機可以要求用戶明確批準通過用戶界面發起的工具調用。

這些緩解措施可以構建針對惡意服務器的縱深防御，同時保持開發人員所需的靈活性。

向后兼容性

MCP Apps 是一個可選擴展。現有實現無需更改即可繼續運行，主機可以根據自身情況逐步采用 UI 支持。服務器應為所有啟用 UI 的工具提供純文本回退方案，并在 UI 不可用時返回有意義的內容，以便同時服務于支持 UI 和僅支持文本的主機。

你也可以參與進來！

為了演示規范提案中描述的模式和類型，目前該社區已經構建了早期訪問 SDK：

https://github.com/modelcontextprotocol/ext-apps

MCP-UI 客戶端和服務器 SDK 均支持這些模式。

如果你有興趣，也可參與貢獻：

https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1865

https://x.com/MCP_Community/status/1992109099434353045

https://blog.modelcontextprotocol.io/posts/2025-11-21-mcp-apps/