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 App：

12+ 个工具：库存查询、入库、出库、调拨、盘点等
3 个资源：店铺列表、商品目录、库存报表
3 个 prompts：库存分析、补货建议、损耗报告
交互式 Dashboard：基于 text/html;profile=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”]
}
当 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 兼容最新协议
兼容 MCP 2025-03-26 协议版本
兼容 text/html;profile=mcp-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 基于更新后的上下文，继续下一步决策
│
▼
循环往复，直到任务完成
在这个循环中，AI 负责"理解意图和编排流程"，人类负责"在关键节点做判断和微调"。这正是 Human-in-the-Loop 的理想形态——不是人类被 AI 替代，也不是人类全程手动操作，而是人机协作，各取所长。

7.4 写在最后
MCP Apps 的出现标志着 MCP 协议从"工具调用"向"应用托管"的进化。而 OpenClaw.NET 在 PR #168 中的实现，不仅是一次功能更新，更是 .NET 生态在 AI 应用架构领域的一次重要布局。

对于 .NET 开发者来说，这是一个值得关注的信号：AI 原生应用的时代正在加速到来，而你手中的技术栈，完全有能力参与其中。

正如 MCP Apps 的设计理念——渐进增强，而非颠覆替换。最好的技术演进，永远是在已有基础上开辟新的可能。