機器之心報道
編輯：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 模型、用戶和應用之間全新的交互奠定基礎?！?/p>
該提案有意保持精簡，首先從核心模式入手，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 是一個可選擴展?，F有實現無需更改即可繼續運行，主機可以根據自身情況逐步采用 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/
京公網安備 11011402013531號