MCP Apps深度解读：AI工具从文本交换迈入交互协作时代

2026年1月26日，MCP（Model Context Protocol）迎来了它的第一个官方扩展——MCP Apps。Anthropic和OpenAI联手将一个社区项目推进成了行业标准。从这一天起，AI工具不再只能返回文本，它们可以返回交互式的用户界面。这意味着什么？让我们一步步来看。

MCP协议：从碎片化集成到统一标准

MCP（Model Context Protocol）是Anthropic于2024年11月发布的开放协议，旨在标准化AI模型与外部工具、数据源之间的通信方式。在MCP出现之前，每个AI应用都需要为每个外部工具单独编写集成代码，形成大量重复的"M×N"集成问题——M个AI客户端乘以N个工具，每一对组合都需要独立维护。MCP通过定义统一的客户端-服务器架构，让任何支持MCP的AI客户端都能调用任何MCP服务器提供的工具，将集成复杂度从M×N降低到M+N。这个基础解决了工具互联互通的问题，但随着使用深入，一个新的瓶颈浮现出来。

MCP的"上下文差距"问题

MCP协议让AI模型可以调用外部工具——查数据库、读文件、调API，但工具返回的始终是纯文本或JSON。当你问"查一下季度营收"，工具返回500行数据，模型只能总结成几段文字。想筛选？再问一轮。想排序？再问一轮。想看趋势图？又是一轮。每一次"看一看"都要花一轮对话。

MCP的创建者把这个问题叫做上下文差距（Context Gap）——模型知道数据，但用户看不到、碰不到。

来看一个具体对比：

• 传统MCP工具：你问"看一下一季度营收"，工具返回数据，模型总结成一段文字。想按区域看？再问一轮。想排序？再来。想看柱状图？又来一轮。五轮对话，30秒延迟，每次都是静态文本。
• MCP Apps方式：同样一个问题，工具直接返回一个交互式仪表盘，柱状图就在对话窗口里。你可以点击、筛选、排序、钻取，一次提问，所有探索都在UI里完成。

类似的场景还有很多。比如部署配置，工具直接展示一个配置表单，选择生产环境自动出现安全选项（TLS、WAF、审计日志），表单里的依赖关系和联动逻辑用文本对话很难表达，但用UI一目了然。再比如合同审查，合同PDF直接内嵌在对话中，关键条款高亮显示，旁边有"批准"和"标记"按钮，你点击标记，模型立刻知道你对这一条有顾虑，自动帮你起草修改建议。

MCP Apps的工作原理

MCP Apps的运行机制可以拆解为四步：

第一步：工具声明。 开发者在定义工具时加一个meta.ui字段，指向一个UI地址。就这一个字段，把普通工具变成了App。

第二步：LLM调用。 模型看到工具的描述，判断需要调用它，发送请求到MCP服务器。

第三步：宿主渲染。 Claude、ChatGPT这些客户端获取UI地址指向的HTML文件，在沙盒化的iframe中渲染出来。这里的"沙盒化iframe"是Web安全的成熟机制——iframe（内联框架）通过HTML5的sandbox属性限制嵌入内容的权限，提供进程级隔离。MCP Apps选择iframe而非WebComponent或Shadow DOM，正是因为即使嵌入内容存在安全漏洞，也无法突破宿主页面的安全边界。

第四步：双向通信。 UI和宿主通过PostMessage和JSON-RPC双向通信。PostMessage是浏览器提供的跨域消息传递API，允许不同源的窗口之间安全通信；JSON-RPC是MCP协议本身也在使用的轻量级远程调用协议，使消息结构化且可审计。UI可以调用其他工具，也可以告诉模型用户做了什么。

代码层面的关键变化

和普通MCP工具的区别只有一个地方：在工具定义里加上meta.ui.resourceUri，指向一个UI地址。name是工具名（LLM用它来决定什么时候调用），description是工具描述，inputSchema定义输入参数。关键的新增字段就是meta.ui，它指向一个HTML打包文件的地址。有了这个字段，宿主就知道这不是一个普通的文本工具，而是一个带UI的App。

UI端的代码使用@anthropic/mcp-ext这个SDK，核心有三个方法：

• onToolResult：接收工具返回的数据，比如查询结果来了，用它来渲染图表
• callServerTool：从UI中调用服务器上的其他工具，比如用户点击了"查看详情"，UI直接调用详情工具
• updateModelContext：静默告诉模型用户做了什么，比如用户选择了"亚太区域"，模型下次回复就会聚焦亚太的数据

所有通信走标准的PostMessage，不锁定任何前端框架。

安全架构：四层防护

在AI对话中运行来自第三方服务器的代码，安全问题至关重要。MCP Apps设计了四层防护机制：

第一层：iframe沙盒隔离。 UI代码跑在受限的iframe里，无法访问宿主页面的DOM、Cookie、LocalStorage。被禁止的操作包括：访问宿主页面、读取Cookie、使用摄像头麦克风、弹出新窗口。被允许的操作包括：渲染HTML/CSS/JS、通过PostMessage和宿主通信。

第二层：预渲染审查。 宿主可以在渲染之前检查HTML内容，发现可疑代码直接阻止。

第三层：可审计的消息通道。 所有通信都走JSON-RPC，每条消息都可以记录、回溯、审计。JSON-RPC 2.0是MCP协议底层通信的基础规范，其结构化的请求/响应格式天然支持日志记录和安全审计。

第四层：用户授权确认。 UI想调用工具，需要用户明确点击同意。

值得一提的是，MIME类型最终定为text/html; profile=mcp-app。原来提案写的是自定义类型，社区审查时发现这违反了媒体类型语法标准，所以改用了RFC 6906的Profile参数机制——RFC 6906是IETF发布的技术规范，允许在标准媒体类型中附加profile参数来描述资源的额外语义约束，既遵守了RFC 2045对媒体类型语法的规定，又传达了"这是一个MCP App"的语义信息。这体现了标准化的严谨性：在创新与互联网标准兼容之间寻求平衡。

真正的Human-in-the-Loop

MCP Apps最核心的价值是实现了真正的Human-in-the-Loop（人在回路中）。Human-in-the-Loop是AI系统设计中的核心概念，指在自动化流程中保留人类判断和干预的节点。传统HITL通常是线性的检查点模式：AI执行→人类审核→继续执行。MCP Apps将其升级为持续循环模式——不是简单的"AI输出，人说行不行"，而是一个持续运转的状态循环：

1. 用户提问 → Agent调用工具 → 返回数据和UI
2. 用户看到交互界面 → 点击操作
3. UI通知Agent → Agent据此调用下一个工具 → 又一轮循环

人类的每一次UI交互都成为Agent决策的输入信号，形成真正的人机协作闭环。

你可能会问：这不就是在对话里嵌了个网页吗？并非如此。MCP App比普通iframe多了和Agent交互的关键能力。普通iframe能渲染HTML，但和外部完全隔离，不知道对话在聊什么，也没法影响对话。MCP App可以调用服务器工具、更新模型上下文、发送后续消息、在浏览器中打开链接、记录调试日志。UI中用户的每一次操作都能驱动整个对话流程。

生产案例：Monday.com与Excalidraw

Monday.com的项目管理场景

Monday.com在ChatGPT和Claude中内置了MCP App。产品经理在ChatGPT中问"Q2产品上线进度怎么样了"，对话中出现一个项目进度条——绿色代表已完成45%，黄色代表进行中30%，红色代表卡住15%。点击红色区域，任务列表展开；再点击"数据库迁移"，Agent自动查了邮件和日历，建议分配给DBA。三次点击，从发现问题到找到解决方案。

Monday.com团队总结了五条设计原则：

1. 选择性展示——不是所有响应都需要UI
2. 临时性上下文——组件服务于当前对话，用完即走
3. 点击代替提问——减少用户输入成本
4. Agent驱动数据流——UI不做业务逻辑
5. 利用Agent上下文——充分利用对话历史信息

生产中也踩了不少坑：流式数据不完整（用300毫秒防抖解决）、模型不知道该选哪个工具（工具描述必须明确写"这是一个UI展示工具"）、不同客户端行为不一致（做了一个薄适配层统一接口）等。

Excalidraw的画板场景

你在Claude或ChatGPT中说"画一个架构图：用户→负载均衡→三个API服务→Redis缓存→PostgreSQL数据库"，对话窗口中一个Excalidraw画板直接出现，方块和箭头一个一个画出来，是流式动画，像有人在实时画一样。你可以直接拖动方块、双击修改文字、添加新元素。更酷的是你还可以继续对话"把数据库画大一点，加上读写分离"，AI会在现有图上修改，不会从头画。

部署特别简单，一份代码跑所有客户端——Claude、ChatGPT、VS Code、Goose，零客户端特定代码。这正是服务化架构的核心价值：UI作为独立的静态资源托管在URL上，任何支持MCP Apps标准的客户端都能获取并渲染同一份代码。

从MCP UI到MCP Apps：架构的关键转变

MCP Apps不是凭空出现的。2025年5月，Ido Salomon发布了MCP UI，最初只在Block的开源Agent框架Goose中运行。它证明了AI工具可以返回交互式UI，但很快遇到问题——在Goose上做的UI不能在ChatGPT里用。

核心问题是MCP UI把UI直接嵌在工具返回值里（内联模式），UI格式和客户端紧耦合。这类似于早期Web开发中把样式直接写在HTML标签里——功能可用，但无法复用。MCP Apps的解法是改为服务化模式——UI作为独立资源放在URL上，任何客户端都能获取和渲染同一份UI。这借鉴了微服务和CDN的设计思想：将UI提供方与消费方解耦，是Web技术三十年来证明有效的分离关注点原则。从"返回UI"变成"服务UI"，这个架构转变让跨客户端成为可能。

目前支持MCP Apps的客户端包括：Claude（Web和桌面端）、ChatGPT（通过Apps SDK）、VS Code（Insiders版本）、Goose（最早的支持者），还有JetBrains、AWS Kero、Postman等正在探索中。

范式反转：应用嵌入AI

Block的Goose团队说了一句很精辟的话：行业把AI助手嵌入单个应用，创造了碎片化的体验。MCP反转了这一点——应用变成了Agent内的可插拔组件。

过去的模式是把AI嵌入应用——Word里有Copilot，Excel里有Copilot，每个应用各搞各的，AI体验割裂。现在的模式是把应用嵌入AI——Excalidraw在Claude里，Monday.com在ChatGPT里，应用变成Agent内的可插拔组件，统一、可组合。

Monday.com的Omri Levy说了一句话：对话正在成为工作发生的地方。

这就是MCP Apps的意义——它标志着AI工具生态从文本交换进入交互协作时代。MCP Apps作为MCP协议的第一个官方扩展，不仅解决了"上下文差距"的技术问题，更代表了一种范式转变：AI不再是被嵌入应用的附属功能，而是成为了应用运行的平台本身。

核心要点

• MCP Apps是MCP协议的第一个官方扩展，由Anthropic和OpenAI联合推动，让AI工具可以返回交互式UI而非纯文本
• 核心架构采用服务化模式：UI作为独立资源托管在URL上，通过iframe沙盒渲染，实现一份代码跨所有AI客户端运行
• 四层安全防护体系（iframe隔离、预渲染审查、可审计消息通道、用户授权确认）确保第三方代码安全执行
• Monday.com和Excalidraw等生产案例验证了MCP Apps在项目管理和可视化场景中的实际价值
• 范式反转：从"把AI嵌入应用"转变为"把应用嵌入AI"，对话正在成为工作发生的地方