一、从对话到界面MCP Apps 的诞生1.1 当前 AI 交互的痛点相信你已经深有体会今天的 AI 助手无论是 Claude、ChatGPT 还是基于大模型的各种 Agent核心交互方式都是文本对话。你问一句AI 答一段。需要数据分析AI 给你生成一段 Markdown 表格。需要可视化它最多画一张静态的 ASCII 图表。这种模式在简单场景下够用但一旦涉及复杂操作——筛选数据、调整参数、实时预览——对话就成了效率的瓶颈。开发者们很早就意识到这个问题。既然 MCP 协议已经让 AI 能够调用外部工具为什么不进一步让工具返回的不仅是文本而是一套完整的交互界面呢1.2 MCP Apps 是什么MCP Apps仓库名ext-apps是 MCP 协议的官方扩展由 Anthropic 于 2026 年 1 月 26 日正式发布。它的核心能力可以用一句话概括MCP 工具可以返回交互式 UI直接嵌在 Claude、ChatGPT 的对话窗口里。具体来说对话窗口中会嵌入一个真实的 iframe里面跑的是由 MCP Server 提供的前端代码。按钮能点、图表能拖、表单能填数据在前后端之间双向流动。最关键的是它的渐进增强设计哲学支持渲染的客户端显示交互界面不支持的客户端比如终端工具照样收到纯文本不会破坏任何现有功能。1.3 三方架构模型MCP Apps 的架构由三个核心角色组成┌─────────────────┐ ┌──────────────────┐ ┌─────────────────┐ │ MCP Server │ │ Host │ │ View │ │ │ │ │ │ │ │ • 注册工具 │◄────┤ • Claude Desktop │◄────┤ • iframe 沙箱 │ │ • 暴露资源 │ │ • ChatGPT │ │ • 前端渲染 │ │ • UI 资源声明 │ │ • VS Code │ │ • 用户交互 │ │ │ │ • 数据中转 │ │ │ └─────────────────┘ └──────────────────┘ └─────────────────┘ ▲ │ │ └───────────────────────┴────────────────────────┘ 所有通信经 Host 中转角色职责实例MCP Server注册工具时在_meta.ui.resourceUri里指向ui://资源Grocery Inventory APIHost创建 iframe、负责数据搬运、通信中转Claude Desktop、ChatGPT、VS Code InsidersView跑在 iframe 沙箱里的前端代码渲染界面反向调用 Server 工具仪表盘、地图、图表组件一个关键的架构约束View 不能直接跟 MCP Server 通信所有通信必须经过 Host 中转。这确保了安全性和可审计性。1.4 View 的七种能力View 并不是简单的静态页面它拥有一整套与 MCP Server 和 Host 交互的能力能力作用tools/call调用 Server 的工具resources/read读取 Server 的资源ui/message往对话里插入消息ui/update-model-context静默更新模型上下文核心能力用户在 UI 上的操作实时反馈给 LLMui/open-link打开外部链接ui/request-display-mode切换显示模式inline/fullscreen/pipvisibility工具可见性控制[app]标记仅 View 可调其中ui/update-model-context是实现Human-in-the-Loop的核心机制。用户在 UI 上的每一次操作——点了哪个按钮、改了哪个筛选条件、选了哪个时间范围——都可以通过这条通道实时反馈给大模型形成一个用户操作 → 更新上下文 → LLM 重新决策 → 刷新界面的完整闭环。1.5 MCP Apps 的价值MCP Apps 的出现本质上是在回答一个 AI 产品设计的核心命题如何让 AI 干活同时在关键节点上让人确认传统的 Agent 模式是AI 决定 → 执行 → 告诉你结果用户全程被动。而 MCP Apps 开启了一种新的范式AI 决定调什么工具 → 给你一个交互界面 → 你在界面上确认/调整 → 结果实时反馈给 AI 继续处理。这不仅仅是更好看的输出而是人机协作范式的升级。二、OpenClaw.NET 率先响应PR #168 的意义2.1 .NET 生态的第一个MCP Apps 协议发布后各路 SDK 和框架开始跟进。但在 .NET 生态中率先给出完整答案的是OpenClaw.NET。PR #168作者geffzhang已合并至 main 分支为 OpenClaw.NET 增加了原生的 MCP App 支持。这个 PR 的规模充分体现了其工程完整度4,012 行代码22 个文件变更43 个全新单元测试2,308 个现有测试全部通过零破坏性变更中英双语文档这个数字很有意思4,000 行新代码却没有任何破坏性变更。这说明 OpenClaw.NET 的架构设计从一开始就为扩展预留了足够的空间。2.2 为什么是第三层架构要理解 OpenClaw.NET 的 MCP App 支持我们需要先看看它已有的 MCP 相关架构。在 PR #168 之前OpenClaw.NET 已经在两个维度上支持了 MCP层级模块方向用途MCP ServerOpenClaw.Gateway/Mcp对外暴露把 OpenClaw 自身作为 MCP Server对外提供工具MCP ClientOpenClaw.Agent/Plugins对内消费连接外部 MCP Server消费第三方工具MCP App (新增)OpenClaw.McpApp托管管理发现、管理、托管第三方 MCP 应用前两层解决的是如何连接的问题作为 Server 被连或作为 Client 去连别人。而新增的第三层OpenClaw.McpApp解决的是一个更上层的问题如何在一个统一的框架内大规模地管理、运行、协调多个 MCP 应用这不是简单的再加一个客户端而是一个完整的应用生命周期管理层。三、三层架构的完整图景让我们把三个层级放在一起看看 OpenClaw.NET 的 MCP 架构全景┌─────────────────────────────────────────────────────────────────────┐ │ OpenClaw.NET 生态 │ ├─────────────────────────────────────────────────────────────────────┤ │ │ │ ┌─────────────────────┐ │ │ │ OpenClaw.Gateway │ ◄── 外部 MCP Client如 Claude Desktop │ │ │ (MCP Server 层) │ 通过 MCP 协议连接 │ │ │ │ │ │ │ 暴露 OpenClaw 工具 │ │ │ │ 作为标准 MCP Server │ │ │ └──────────┬──────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────┐ ┌──────────────────────────────────┐ │ │ │ OpenClaw.McpApp │ │ OpenClaw.Agent/Plugins │ │ │ │ (MCP App 托管层) │ │ (MCP Client 层) │ │ │ │ │ │ │ │ │ │ • 发现 MCP App │ │ • 连接到外部 MCP Server │ │ │ │ • 管理生命周期 │ │ • 消费外部工具 │ │ │ │ • 维护连接状态 │ │ • 集成到 Agent 工作流 │ │ │ │ • 桥接为 ITool │◄────┤ │ │ │ │ │ │ 方向Client → 外部 Server │ │ │ │ 方向Host → 托管 App│ │ │ │ │ └──────────┬──────────┘ └──────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │ 第三方 MCP App 生态 │ │ │ │ │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌────────────┐ │ │ │ │ │库存管理 │ │系统监控 │ │地图服务 │ │PDF 查看器 │ │ │ │ │ │(grocery) │ │(system) │ │(map) │ │(pdf) │ │ │ │ │ └──────────┘ └──────────┘ └──────────┘ └────────────┘ │ │ │ └─────────────────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────────┘这个架构的精妙之处在于方向性的清晰划分MCP Server 层向外OpenClaw 说我的工具在这里谁来连我MCP Client 层向内OpenClaw 说我去看外面有什么工具可以用MCP App 层托管OpenClaw 说我来管理和运行这些完整的 MCP 应用四、核心组件深度解析OpenClaw.McpApp项目包含 7 个核心组件它们共同构成了一个完整的 MCP 应用托管平台。让我们逐一拆解。4.1 McpAppManifest — 应用的身份证每个 MCP App 都需要一个openclaw.mcpapp.json清单文件它定义了应用的基本信息、传输方式和能力声明。{ id: grocery-inventory, name: Grocery Inventory Manager, description: Multi-store inventory management system, version: 1.0.0, transport: http, url: https://localhost:5001/mcp, hasUi: true, uiResourceUri: ui://grocery/store-dashboard.html, toolNamePrefix: grocery., capabilities: [tools, resources, prompts, completions] }这个设计体现了几个关键考量transport支持stdio子进程、http远程端点、inprocess进程内覆盖了从本地工具到远程服务的全部场景toolNamePrefix避免了命名冲突——grocery.inventory.search和sales.inventory.search可以共存hasUiuiResourceUri声明了交互式 UI 的能力和资源地址capabilities显式声明支持的功能便于 Host 做能力协商4.2 McpAppInstallState — 六阶段生命周期每个 MCP App 从被发现到最终运行会经历一个严格定义的状态机┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ Discovered │───►│ Validated │───►│ Loaded │ │ (被发现) │ │ (已验证) │ │ (已加载) │ └─────────────┘ └──────┬──────┘ └──────┬──────┘ │ │ ▼ ▼ ┌─────────────┐ ┌─────────────┐ │ Disabled │ │ Running │ │ (禁用) │ │ (运行中) │ └─────────────┘ └──────┬──────┘ │ ┌────────────────────┘ ▼ ┌─────────────┐ ┌─────────────┐ │ Stopped │◄─────│ Failed │ │ (已停止) │ │ (失败) │ └─────────────┘ └─────────────┘状态含义转换条件Discovered清单文件被扫描发现自动扫描触发Validated清单格式验证通过JSON Schema 校验Disabled被配置显式禁用Enabled: falseLoaded应用配置已加载验证通过后自动进入Running连接已建立工具可用McpAppServer成功连接Stopped已停止运行框架关闭或手动停止Failed连接或运行出错超时、网络错误、协议错误这个状态机的价值在于可观测性和可控性。在生产环境中你可以精确知道每个 MCP App 处于什么状态出了什么问题而不是面对一个连不上的黑盒。4.3 McpAppDiscovery — 智能发现机制McpAppDiscovery是一个递归清单扫描器负责在指定路径下自动发现 MCP App// Discovery 配置示例 { DiscoveryPaths: [./mcpapps], // 扫描哪些目录 Allow: [grocery-*, monitor*], // 白名单支持 glob 模式 Deny: [*-test, deprecated-*] // 黑名单优先于 Allow }扫描器会递归搜索**/openclaw.mcpapp.json文件反序列化后进行验证再通过allow/deny/glob过滤规则筛选。这套机制让 MCP App 的部署变得极其简单——把应用目录扔进去框架自己找到并加载。4.4 McpAppServer — 连接的生命周期管理McpAppServer负责管理单个 MCP App 的连接生命周期。它的核心职责包括根据transport类型选择连接方式stdio 子进程 / HTTP 端点 / 进程内建立 MCP 协议连接枚举可用的tools、resources、prompts生成IMcpAppInfoProvider供上层使用支持幂等重连——连接断开时自动恢复// 伪代码示意 class McpAppServer { // 幂等启动如果已经在运行直接返回 async Task StartAsync() { if (State ConnectionState.Connected) return; // 根据 transport 创建连接 var transport transportType switch { stdio new StdioTransport(executablePath), http new HttpTransport(endpointUrl), inprocess new InProcessTransport(instance), _ throw new NotSupportedException() }; // 连接、握手、枚举能力 await transport.ConnectAsync(); var capabilities await EnumerateCapabilitiesAsync(); State ConnectionState.Connected; } }4.5 McpAppNativeTool — 无缝桥接到 ITool这是整个架构中最关键的胶水层。McpAppNativeTool将远程 MCP App 提供的工具桥接到 OpenClaw 内部的ITool接口┌─────────────────┐ ┌──────────────────┐ ┌─────────────────┐ │ MCP App │ │ McpAppNativeTool │ │ OpenClaw Agent │ │ (远程) │◄───────►│ (桥接层) │◄───────►│ (ITool 接口) │ │ │ MCP │ │ ITool │ │ │ • search │ 协议 │ 封装远程调用 │ 协议 │ Agent 无感调用 │ │ • update │ │ 统一错误处理 │ │ │ │ • delete │ │ 参数/结果映射 │ │ │ └─────────────────┘ └──────────────────┘ └─────────────────┘对于 Agent 来说调用一个 MCP App 的工具和调用一个原生插件的工具没有任何区别。Agent 不需要知道grocery.inventory.search是来自一个本地函数还是一个远程 HTTP 服务——这一切都被桥接层透明地处理了。4.6 McpAppRegistry — 集中注册表McpAppRegistry是整个 MCP App 子系统的指挥中心管理全部 App 的发现、连接和追踪协调McpAppDiscovery和McpAppServer提供查询接口按 ID 查找、按能力过滤、按状态筛选处理启动时的批量连接和关闭时的优雅清理4.7 McpAppServiceExtensions — 极简的 DI 注册最后McpAppServiceExtensions提供了一行代码完成所有注册的体验// Program.cs builder.Services.AddOpenClawMcpApps(builder.Configuration.GetSection(McpApps));框架内部会依次注册 Discovery → Registry → Server Factory → NativeTool Factory完全不需要手动干预。五、实战从配置到运行5.1 Gateway 配置在appsettings.json中新增McpApps配置节{ McpApps: { Enabled: true, DiscoveryPaths: [./mcpapps], Allow: [*], Deny: [], Entries: { grocery-inventory: { Enabled: true, Url: https://localhost:5001/mcp, ToolNamePrefix: grocery., StartupTimeoutSeconds: 15 } } } }配置分为两部分全局配置Enabled总开关、DiscoveryPaths扫描路径、Allow/Deny过滤规则应用配置Entries下每个 MCP App 的具体连接参数零开销设计McpApps.Enabled默认为false。如果你不启用这个功能整个OpenClaw.McpApp模块不会被激活对性能和启动时间没有任何影响。5.2 启动流程OpenClaw Gateway 启动时MCP App 子系统会按以下顺序执行appsettings.json / GatewayConfig.McpApps │ ▼ McpAppDiscovery 扫描 DiscoveryPaths默认 ./mcpapps/ 查找 **/openclaw.mcpapp.json 反序列化 验证 allow/deny 过滤 │ ▼ McpAppInstallState每个 App 一个实例 生命周期: Discovered → Validated → [Disabled|Failed] → Loaded → Running → Stopped │ ▼ McpAppRegistry 管理全部 App 的集中注册表 调用 McpAppServer 建立连接 │ ▼ McpAppServer 通过 stdio 子进程 / HTTP 端点连接 MCP App 枚举 tools、resources、prompts 生成 IMcpAppInfoProvider │ ▼ McpAppNativeTool实现 ITool 注册进 NativePluginRegistry Agent 可像调用内置工具一样调用 MCP App 工具5.3 GroceryInventory.Api 示例PR #168 中包含了一个完整的示例项目GroceryInventory.Api这是一个多店铺库存管理 MCP App12 个工具库存查询、入库、出库、调拨、盘点等3 个资源店铺列表、商品目录、库存报表3 个 prompts库存分析、补货建议、损耗报告交互式 Dashboard基于text/html;profilemcp-app规范的实时库存仪表盘// openclaw.mcpapp.json { id: grocery-inventory, name: Grocery Inventory Manager, description: Multi-store inventory management system, version: 1.0.0, transport: http, url: https://localhost:5001/mcp, hasUi: true, uiResourceUri: ui://grocery/store-dashboard.html, toolNamePrefix: grocery., capabilities: [tools, resources, prompts, completions] }当 Agent 调用grocery.inventory.search时OpenClaw 会自动将请求路由到 GroceryInventory.Api 的 HTTP 端点。如果用户需要交互式操作Agent 会返回 Dashboard 的 UI 资源 URI由客户端渲染为可交互的 iframe 界面。六、技术亮点一个生产级实现该有的样子回顾整个 PR #168有几个值得称道的工程实践6.1 零破坏性变更4,000 行新代码2,308 个现有测试全部通过。这说明新模块完全独立没有侵入现有代码架构的扩展点设计合理测试覆盖率高回归风险可控6.2 默认禁用零开销McpApps.Enabled默认为false模块默认不激活。这是一种成熟框架的设计哲学新功能不应该是用户的负担。6.3 43 个单元测试新模块自带 43 个单元测试覆盖了 Discovery、Lifecycle、Registry、Tool Bridging 等核心流程。这不是为了测试而测试而是确保一个多步骤、异步、有状态的系统在各种边界条件下都能正确工作。6.4 中英双语文档技术文档的完整度直接决定了功能的采纳率。PR #168 包含了中英文双语的技术文档降低了国内外开发者的使用门槛。6.5 兼容最新协议兼容 MCP2025-03-26协议版本兼容text/html;profilemcp-app交互式 UI 规范协议版本匹配严格避免看起来能用实际上不对的兼容性问题七、展望MCP Apps 的未来与 .NET 开发者的机会7.1 MCP Apps 生态的当前状态根据公开数据MCP Apps 的生态正在快速扩张SDK 周下载 160 万次333 个依赖包首批合作方Amplitude、Asana、Canva、Figma 已接入Salesforce 确认跟进客户端支持Claude Web/Desktop、ChatGPT、VS Code Insiders、Cursor v2.6 等已支持但同时也存在挑战碎片化七个客户端的 iframe 实现各不一样跨平台一致性有待提升终端场景缺席大量开发者在终端里干活MCP Apps 等于不存在信任难题第三方 MCP Server 注入 HTML 的安全信任问题仍需完善7.2 对 .NET 开发者意味着什么OpenClaw.NET 的 MCP App 支持为 .NET 开发者打开了一扇新的大门首先你可以用熟悉的技术栈构建 MCP Apps。ASP.NET Core 服务、Blazor 组件、SignalR 实时通信——这些你早已熟练的技术现在可以直接用于构建面向 AI 的交互式应用。你的库存管理系统、监控仪表盘、数据可视化平台稍加改造就能成为 MCP App。其次MCP App 是AI-Native 应用的新形态。传统的 SaaS 是人登录网页 → 操作系统。MCP App 是AI 决定调用什么工具 → 给人一个交互界面 → 人的操作反馈给 AI。这不是简单的交互方式变化而是应用架构的范式转移。最后先发优势。OpenClaw.NET 是 .NET 生态中率先完整支持 MCP Apps 的框架。这意味着你现在就可以开始构建和实验在这个新兴领域积累经验和影响力。7.3 Human-in-the-Loop 的终极形态让我们回到文章开头的问题当 AI 给你一个可交互的仪表盘而不只是文字描述时什么发生了变化答案是决策权的分配发生了变化。在传统 Agent 模式中AI 是黑盒决策 → 执行 → 输出用户只能接受或拒绝最终结果。而在 MCP Apps 模式下用户提出问题 │ ▼ LLM 分析意图决定调用哪个 MCP App 工具 │ ▼ MCP App 返回交互式 UI不是文本是界面 │ ▼ 用户在 UI 上操作筛选、调整、确认 │ ▼ ui/update-model-context 将用户操作实时反馈给 LLM │ ▼ LLM 基于更新后的上下文继续下一步决策 │ ▼ 循环往复直到任务完成