在MCP过去的大部分发展时间里它的交互模式都很简单智能体调用一项工具工具完成某个操作服务器返回文本或结构化数据最后再由模型把结果解释给用户。对于很多场景来说这种方式已经足够。如果我问“现在有多少个正在运行的部署”我并不需要为此打开一个完整的前端应用。智能体只要调用get_deployments()得到以下结果{total:12,healthy:10,degraded:2}然后回答一句当前共有12个部署其中10个运行正常2个处于降级状态。任务完成。然而当用户不只是想“阅读结果”而是希望与结果进行交互时事情就变得复杂了。如果我想查看一个仪表盘呢如果我需要批准某项操作呢如果我需要一张能够筛选的表格、一个配置表单、一幅图表、一套部署控制面板、一段多步骤流程或者一个必须由人工确认的审批环节呢长期以来MCP并没有提供一种能够跨宿主应用统一解决这些问题的标准方式。现在它终于有了。这套扩展叫作MCP Apps。一个很香的 AI 平台GPT-5.6 低倍率且不降智 和 Claude Code 4.8 只要 0.25倍率包含 image-2生图。重点是 首字请求都在 5s 内。入口https://ai.aiyuhub.com过去的MCP服务器更像机器接口最初的MCP思维模型是围绕智能体设计的。服务器公开一组工具例如search_projects() create_ticket() restart_service() get_customer()模型发现这些工具选择其中一项并发起调用服务器返回数据最终用户看到的则是模型对这些数据的重新表述。这种架构非常强大。开发者不再需要为每一种智能体单独编写集成而是可以通过统一协议公开业务能力。不过它始终存在一个重要限制这些能力主要是为机器设计的人类用户与真实结果之间仍然隔着一层模型。当任务只需要一句话回答时这种距离并没有问题。可一旦交互本身具有明显的视觉属性差距便会迅速暴露出来。比如用户要求“把所有生产环境服务展示出来。”返回一大块包含状态、CPU和内存数据的JSON在技术上完全正确。然而相比JSON一个带有进度条、状态标记以及“日志”“重启”“扩容”按钮的小型仪表盘显然更有用。更关键的是那些按钮应该真的能够工作。MCP Apps要填补的正是这个缺口。MCP Apps到底是什么MCP Apps是Model Context Protocol的一项扩展允许MCP服务器在公开工具的同时交付与之配套的交互式用户界面。这里所说的界面不是截图也不是用Markdown勉强模拟出来的按钮而是真正运行在MCP宿主中的HTML和JavaScript应用。按照官方文档描述工具可以声明ui://资源宿主在沙箱化的iframe中渲染这些资源宿主把工具数据传入界面界面也能通过宿主反向调用工具。它可以被简化为MCP App MCP Tool UI Resource Host/View协议工具仍然完成原来的工作调用API查询数据库执行业务逻辑返回结构化数据。区别只是工具现在还能额外告诉宿主“我有一个专门用于展示这份结果的界面。”这套UI本身同样以MCP资源的形式提供例如ui://services/dashboard资源中可以包含一套完整的前端应用HTMLCSSJavaScriptReact或Vue图表表单按钮其他所需组件。于是MCP第一次以跨宿主的标准方式把两类能力组合在了一起面向机器的操作接口以及面向人类的交互界面。MCP Apps是从哪里来的MCP Apps非常新这段历史背景很重要。如果你在2025年一直积极开发MCP服务器却从没见过这项功能并不是因为错过了什么隐藏文档。当时它还没有成为正式标准。2025年11月21日MCP维护者提出了SEP-1865也就是MCP Apps扩展提案。该方案由MCP维护者、MCP-UI创建者以及来自OpenAI和Anthropic的维护人员共同推动。它并不是凭空出现的。在此之前MCP-UI与OpenAI Apps SDK已经分别尝试解决相似问题。真正棘手的是互操作性同一个服务器开发者可能需要为某个宿主编写一套UI集成又为另一个宿主重新实现一遍。MCP Apps希望把这件事标准化一个服务器同时公开工具、数据和UI任何兼容宿主都能渲染。2026年1月26日两个多月后MCP维护者正式宣布MCP Apps上线并将其称为第一个官方MCP扩展同时明确表示已经可以用于生产环境。此时最初的提案已经发展为更成熟的规范更完整的SDK已经落地的宿主实现。1月公告中提到ChatGPT、Claude、Goose与Visual Studio Code已经推出支持。2026年7月28日MCP规范候选版本进一步完善了扩展机制。扩展开始拥有独立标识符客户端与服务器能力协商专用代码仓库独立版本控制正式的Extensions Track。MCP Apps也被明确列入官方扩展。这一版本还进一步确认了一项重要安全属性由UI触发的操作仍然必须经过宿主并继续使用相同的JSON-RPC基础设施。无论触发路径是智能体 → 工具还是人类 → 按钮 → 工具最终都沿着同一条控制链路执行UI代码不能绕过MCP宿主直接操作服务器。2026年9月11日AWS公布了一个实际案例展示如何在Amazon Bedrock AgentCore上部署MCP App。需要注意的是这不代表MCP Apps变成了AWS专属功能。它依然是一项与宿主无关的开放标准。AWS展示的只是一种生产部署模式AI宿主 ↓ AgentCore Gateway ↓ AgentCore Runtime ↓ 同时公开工具与UI资源的MCP服务器 ↓ Lambda与DynamoDB中的业务逻辑示例在ChatGPT中演示了完整体验同时指出同一个服务器也能在Claude和其他支持MCP Apps的宿主中运行。详见AWS示例。哪些客户端真正支持MCP Apps这里必须说得准确一点支持MCP不等于支持MCP Apps。一个客户端可以支持普通工具和资源却完全没有实现Apps扩展。2026年1月的公告明确提到ChatGPT、Claude、Goose和VS Code已经提供支持。当前文档也表示App可以内嵌显示在Claude、ChatGPT和其他兼容客户端中同时明确提醒不同宿主的支持情况并不完全一致。因此正确的设计前提应该是服务器支持MCP Apps 宿主支持MCP Apps 交互式UI不应该假设所有MCP客户端都会自动理解Apps。一个设计良好的服务器在宿主无法渲染App时也应该能够优雅降级继续返回普通文本或结构化内容。真正关键的问题只有一个第一次研究这套模式时我最关心的问题并不是iframe也不是SDK。真正重要的是如果UI资源只是一份静态HTML那么不断变化的工具数据究竟怎样进入界面CPU占用现在可能是21%十秒后可能就变成87%。我们显然不能在每次工具执行时都重新生成一整套前端应用。事实上也不需要这样做。秘诀在于UI和数据是相互分离的。可以这样理解工具 数据 资源 展示方式 宿主 连接两者的胶水工具返回动态数据。资源返回一套能够渲染这种数据类型的应用。宿主则在运行时把数据与界面连接起来。MCP Apps实际如何运行假设服务器提供一项工具get_servers()它会返回服务器列表每项记录包含ID名称状态CPU占用内存使用量。同时这项工具在定义中指向一个UI资源ui://servers/dashboard整个生命周期如下。首先模型调用get_servers()。服务器执行必要的业务逻辑可能查询数据库、AWS、Kubernetes或内部服务随后返回结构化数据。宿主读取工具元数据发现它指向ui://servers/dashboard于是知道这份结果可以用交互式界面展示。接着宿主针对该URI发起MCP资源读取请求resources/read服务器返回真正的前端应用。它可能是打包后的React应用Vue应用原生JavaScript页面。一个非常关键的细节是当前服务器数据不会被直接写死在HTML中。UI只需要知道数据契约例如servers[].id servers[].status servers[].cpu servers[].memory随后宿主在沙箱化iframe中渲染这套应用。这道边界非常重要因为宿主正在执行由MCP服务器提供的UI代码绝不能让它无限制访问父页面DOM、用户会话或身份凭据。最后宿主把真实工具结果交给正在运行的视图。按照官方架构宿主和沙箱视图之间通过postMessage以JSON-RPC形式进行通信。前端收到的数据与任何普通Web应用收到的数据没有本质区别。只有一台服务器它就渲染一张卡片有五十台服务器它就渲染五十张卡片。应用本身没有改变变化的只是数据。把它与传统Web架构比较就更容易理解。传统模式React ↓ GET /api/servers ↓ 返回JSON ↓ 渲染界面MCP Apps模式智能体 ↓ tools/call ↓ 工具返回JSON ↓ 宿主把JSON传给iframe中的React应用 ↓ 渲染界面最大的不同是UI未必需要亲自发起第一次请求。操作已经由智能体触发宿主也已经拿到了结果只需要把数据交给应用。MCP Apps不只是更漂亮的工具结果真正有意思的地方从这里才开始。UI不仅能接收数据还可以通过宿主向服务器“说话”也就是直接调用其他MCP工具。还是刚才的服务器仪表盘现在为每台服务器增加三个按钮[日志] [重启] [扩容]用户点击“重启”后应用希望执行restart_server(server_idsrv-1)不过iframe不会直接连接MCP服务器。完整路径是MCP App ↓ 请求调用工具 ↓ 宿主 ↓ tools/call ↓ MCP服务器 ↓ restart_server()按钮背后的JavaScript只需要知道工具名称和输入契约asyncfunctionrestartServer(serverId){returnapp.callServerTool({name:restart_server,arguments:{server_id:serverId}});}现在智能体和面向人类的应用可以共同使用同一层业务能力。这远比“在聊天机器人里嵌入一张图表”更值得关注。一项能力两种接口没有MCP Apps时系统架构很容易把同一项业务能力公开两次。前端使用POST /api/deployments/restart智能体使用restart_deployment()同一项重启操作却拥有两套集成接口。开发者需要分别维护授权、参数验证、监控、错误处理和业务逻辑很容易出现两边行为逐渐不一致的问题。有了MCP Apps之后无论是智能体主动调用还是人类点击按钮都能执行同一个restart_deployment操作。它们共享身份验证权限控制参数验证可观测性业务规则审计记录。所以MCP Apps带来的变化远不只是“MCP现在支持小组件了”。更深层的影响是机器和人类终于可以通过不同界面复用同一套业务能力。生产案例在智能体流程中加入人工审批来看一个更贴近生产环境的例子。用户要求智能体为某项功能创建一条用户故事。智能体先调用get_feature_context()获得背景信息再由LLM生成用户故事和验收标准。在普通对话流程中任务到这里基本就结束了。用户会看到一段文字然后回复“看起来不错。”或者“把第二条验收标准改一下。”后端必须根据自然语言猜测这究竟是在批准、提出修改还是仅仅发表意见。这种流程很脆弱。使用MCP Apps后智能体可以调用present_user_story_for_approval(...)App会把用户故事展示出来并提供两个清晰按钮[拒绝] [批准]点击“批准”时执行approve_user_story( story_idUS-483, version1 )点击“拒绝”时执行reject_user_story( story_idUS-483, version1, reason... )此时整个流程不再依赖模型猜测而是变成了一台明确的状态机。这并不是视觉装饰。界面已经成为智能体工作流中的正式组成部分。而且这种审批能够被完整审计远比让用户输入“YES”更加可靠。这里还有两个值得注意的生产细节。不要让App抓取聊天内容App不应该尝试读取上方聊天消息再从页面中提取用户故事正文。这样会让工作流依赖宿主的具体渲染结构极其脆弱。更干净的做法是把故事作为工具参数明确传入present_user_story_for_approval( story_id, version, story )视图从一开始就拥有所需状态聊天界面的展示逻辑则与真实工作流状态保持分离。提交ID和版本不要提交整个对象假设用户故事已经更新为版本2而对话中仍然保留着版本1的旧审批卡片。如果按钮重新提交整段旧文本系统可能错误批准一个已经过期的状态。更可靠的方式是只提交story_id version后端发现版本落后后可以拒绝审批并要求用户检查最新草稿。需要始终记住对话只是UI后端才是事实来源。不是每个按钮都要变成模型工具MCP Apps还有一个很实用的设计工具可见性。仪表盘可能需要许多只与UI有关的细小操作例如翻页刷新表格修改排序调整图表时间范围保存筛选条件。这些操作没有必要全部进入LLM的工具上下文。App可以拥有自己专用的UI操作而模型继续面对更小、更清晰的能力集合。随着MCP服务器不断扩大工具上下文体积和工具选择准确率都会成为真实问题。将UI微操作从模型工具中分离可以避免模型被迫理解那些原本就不该由它处理的行为。而且这并不只是一项设计惯例。规范提供了明确机制。工具的_meta.ui.visibility字段可以设置为[model,app]这是默认值代表模型与App都能看到。也可以缩小为[app]当工具被标记为仅App可见时宿主不能把它放进提供给模型的工具列表。从智能体角度来看这项工具根本不存在只能由正在运行的App视图调用。于是同一个MCP服务器可以把工具真正拆分成不同访问层级只允许智能体调用只允许App调用智能体与App都能调用。这不仅让工具列表更整洁也构成了一道真实的访问边界。通信还可以反向流动。在前面的拒绝案例中当用户点击“拒绝”并填写原因后这段理由不必被锁在App内部。根据宿主能力和权限MCP Apps可以更新模型上下文。下一轮模型会直接理解用户为什么拒绝当前故事并自动生成更合理的版本2无须用户在聊天框中重新解释一遍。MCP Apps不是第四种核心原语这个概念需要澄清因为“MCP Apps”这个名字很容易让人形成错误理解。它并没有把原来的Tools / Resources / Prompts变成Tools / Resources / Prompts / AppsApps不是第四种核心原语。它是一项扩展。它继续建立在现有MCP概念之上只是增加了两层标准化关系工具与UI资源之间的关联服务器、宿主与视图之间的通信协议。如果你已经理解MCP工具和资源MCP Apps并不是另一套突然拼接上来的协议。它只是围绕原有能力增加了一层交互界面。如果聊天应用是你自己开发的如果你不是把服务器接入现有MCP Apps宿主而是在构建自己的智能体平台这一点尤其重要。你的聊天应用本身就是MCP宿主。因此它也必须理解MCP Apps包括检测工具中的UI元数据读取关联资源在沙箱中渲染应用把工具输入和输出交给视图把视图允许发起的工具调用代理回服务器协商客户端与服务器能力执行权限限制。这是一块真实的系统架构不是勾选一下配置就会自动拥有的功能。按回车键或点击查看完整尺寸图片image整个体系中确实存在三个参与者MCP服务器MCP宿主MCP App视图。当前官方SDK甚至明确区分了三类开发角色视图开发者宿主开发者服务器作者。官方SDK目前主要围绕modelcontextprotocol/ext-appsTypeScript包构建。不过这并不意味着所有业务逻辑都必须迁移到Node.js。传输层仍然围绕普通MCP能力展开工具元数据资源结构化内容MCP请求。因此只要Python或FastMCP服务器能够公开兼容宿主所需的元数据、资源和结构化输出就完全可以继续使用。不要把下面两句话混为一谈“官方辅助SDK使用TypeScript。”和“整个MCP Apps后端必须使用TypeScript。”前端视图自然会使用Web技术但业务层与现有服务完全可以留在原来的技术栈中。安全绝不能最后才考虑当MCP服务器能够交付可执行UI时安全模型就变得至关重要。现有架构已经提供了基础保护视图运行在沙箱化iframe中UI通过宿主通信App不能无限制访问父应用。然而从企业架构角度看仍然应该把每个App都视为不可信UI。尤其当它能够触发以下操作时restart_service() delete_resource() approve_payment() deploy_to_production()对于破坏性操作当然应该添加明确的确认对话框。但确认框绝不是唯一防线。后端仍然必须实施身份验证授权控制输入验证策略执行审计日志幂等处理版本检查速率限制。UI不是信任边界。后端才是。按钮显示为红色、对话框要求用户再次确认都只能改善体验不能替代服务器端的安全控制。哪些场景真正适合MCP Apps不应该为每项工具都开发一个MCP App。如果工具结果只是42直接返回42即可。如果用户只想知道生产环境当前运行哪个版本也不需要为了显示版本号加载React。MCP Apps真正值得使用的地方是交互本身具有结构的场景。运维仪表盘服务、部署、基础设施、日志、指标、任务与队列都很适合使用可交互界面。用户通常需要先检查状态再执行操作。审批工作流例如批准或拒绝接受或要求修改部署或取消发布或保留草稿。这可能是MCP Apps最有价值的企业场景。RAG与企业知识搜索相比把20条搜索结果全部转换成普通文字App可以提供筛选器复选框排序“比较已选内容”按钮。智能体则继续负责结果周围的自然语言推理。智能体治理自然语言很适合询问“目前哪些智能体能够访问生产环境中的Salesforce”然而在审核权限和批准变更时结构化注册表往往更加清晰可靠。自然语言和界面并不冲突它们可以互相补充。表单与配置要求用户用自然语言描述“把CPU设为2内存设为4GB区域改成us-east-1副本数量设为3。”显然不如直接提供表单。MCP Apps允许智能体在对话进行到恰当时机时把配置表单直接带进聊天。不要为每项工具单独做一个App另一种应该避免的设计是把工具与App机械地一一对应tool_1 → app_1 tool_2 → app_2 tool_3 → app_3更合理的做法是围绕业务能力或领域设计应用。例如一套“部署管理”App可以同时使用get_deployment get_logs restart_deployment scale_deployment rollback_deployment其中某项工具作为入口负责把App展示出来。App加载完成后则可以调用整个相关工具家族。这样得到的UI更加完整MCP架构也比一堆用途单一的小应用清晰得多。更大的架构变化MCP Apps最让我感兴趣的并不是iframe本身。真正重要的是过去我们花了大量时间为智能体设计操作如今同一批操作终于能够在上层公开一套标准化的人类交互界面。业务操作 ↓ 机器接口MCP Tool 人类接口MCP App如果你已经开始用“智能体插件”而不是“孤立MCP服务器”的方式思考这件事会更加有意思。例如一套Salesforce能力包可以同时提供使用说明MCP工具如search_accounts、create_opportunity和update_lead权限定义评估用例MCP Apps例如账户浏览器、商机表单和销售管道仪表盘。这套能力不再只是一袋工具而是同时面向智能体和人类的完整交互层。值得注意的是智能体甚至不需要知道这些UI存在。它不需要理解React也不用了解iframe更不必知道按钮如何被渲染。智能体只需要调用get_services(...)或者present_user_story_for_approval(...)工具元数据会告诉宿主当前存在可用界面。于是UI问题留在UI层推理问题交给智能体业务逻辑保留在后端。这正是生产级系统希望拥有的职责分离。我会如何把它引入现有系统假设我已经拥有一套生产级智能体平台其中包括自定义聊天界面多个智能体FastMCP服务器。我不会为了采用MCP Apps而重新设计整个系统。我会从一项只读能力开始。例如get_agents()它只返回一份较小的智能体列表。随后为它关联一个尽可能简单的视图ui://agents/list第一版界面只显示智能体名称当前状态工具数量。暂时不添加按钮。第一个目标只是验证完整链路智能体调用工具 ↓ 宿主发现UI元数据 ↓ 读取资源 ↓ 渲染iframe ↓ 工具结果成功进入视图当这条链路稳定运行后再逐步增加能力添加一个“刷新”按钮增加一项真正的操作例如“禁用智能体”加入授权控制完善审计日志最后再开发更复杂的App。这种方式可以渐进采用MCP Apps而且完全不需要改变现有智能体的推理架构。最后的思考长期以来MCP回答的是一个重要问题AI智能体如何通过统一协议与外部系统交互MCP Apps又增加了一个新问题人类如何在不离开对话的情况下与同一批业务能力直接交互这个变化远比第一眼看上去更大。旧模式是智能体 → 工具 → JSON → 文本新模式则是同一项业务能力分出两种接口。┌→ MCP Tool → 智能体 业务能力 ────────┤ └→ MCP App → 人类两条路径最终都进入同一套底层业务逻辑。智能体仍然负责推理工具仍然执行操作。然而当交互本身需要结构时协议现在可以把真正的界面直接带进对话仪表盘表单审批界面数据可视化配置页面人工参与的工作流。而且它们全部建立在智能体已经使用的同一层MCP能力之上。因此我不认为MCP Apps只是“MCP返回了更漂亮的结果”。它代表了一个更大的变化MCP服务器正在从单纯面向机器的集成端点进化为同时服务智能体与人类的可移植交互层。别再只想着返回JSON。当用户需要的不只是答案而是下一步操作时真正应该交付的也许就是UI。