📰 来源: 博客园
你让 AI 查一下库存数据，它给你吐了三页文字表格。想按品类筛选？重新说一句话。想看个饼图？再描述一遍。如果 AI 能直接给你一个可交互的仪表盘——按钮能点、图表能拖、数据实时刷新——那会怎样？
这不是想象中的未来，而是正在发生的现实。
2026 年 1 月，MCP 协议官方发布了 MCP Apps（扩展标识符 io.modelcontextprotocol/ui），正式将"交互式 UI"纳入 MCP 的能力版图。三个月后，OpenClaw.NET 在 PR #168 中引入了原生的 MCP App 支持，成为 .NET 生态中率先对 MCP Apps 协议提供完整实现的框架。
今天，我们就来聊聊 MCP Apps 究竟是什么，以及 OpenClaw.NET 是如何为 .NET 开发者铺就这条通往"交互式 AI 应用"的道路的。
一、从"对话"到"界面"：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 提供的前端代码。按钮能点、图表能拖、表单能填，数据在前后端之间双向流动。
最关键的是它的渐进增强设计哲学：支持渲染的客户端显示交互界面；不支持的客户端（比如终端工具）照样收到纯文本，不会破坏任何现有功能。
MCP Apps 的架构由三个核心角色组成：
┌─────────────────┐ ┌──────────────────┐ ┌─────────────────┐
│ MCP Server │ │ Host │ │ View │
│ │ │ │ │ │
│ • 注册工具 │◄────┤ • Claude Desktop │◄────┤ • iframe 沙箱 │
│ • 暴露资源 │ │ • ChatGPT │ │ • 前端渲染 │
│ • UI 资源声明 │ │ • VS Code │ │ • 用户交互 │
│ │ │ • 数据中转 │ │ │
└─────────────────┘ └──────────────────┘ └─────────────────┘
▲ │ │
└───────────────────────┴────────────────────────┘
所有通信经 Host 中转
一个关键的架构约束：View 不能直接跟 MCP Server 通信，所有通信必须经过 Host 中转。这确保了安全性和可审计性。
1.4 View 的七种能力
View 并不是简单的静态页面，它拥有一整套与 MCP Server 和 Host 交互的能力：
其中，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,000+ 行新代码，却没有任何破坏性变更。这说明 OpenClaw.NET 的架构设计从一开始就为扩展预留了足够的空间。
2.2 为什么是"第三层"架构
要理解 OpenClaw.NET 的 MCP App 支持，我们需要先看看它已有的 MCP 相关架构。
在 PR #168 之前，OpenClaw.NET 已经在两个维度上支持了 MCP：
前两层解决的是"如何连接"的问题：作为 Server 被连，或作为 Client 去连别人。而新增的第三层 OpenClaw.McpApp 解决的是一个更上层的问题：如何在一个统一的框架内，大规模地管理、运行、协调多个 MCP 应用？
这不是简单的"再加一个客户端"，而是一个完整的应用生命周期管理层。
三、三层架构的完整图景
让我们把三个层级放在一起，看看 OpenClaw.NET 的 MCP 架构全景：
┌─────────────────────────────────────────────────────────────────────┐
│ OpenClaw.NET 生态 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ┌────────────────
🔗 原文链接: 点击阅读原文
文章评论