、场景引入当 AI 遇到复杂业务想象一下这个场景你的公司刚上线了一个 AI 助手骄傲地接入了 ERP 系统。销售小李在企业微信里问帮我查一下华东区上季度的退货明细。AI 爽快地调用了查询工具然后——在聊天窗口里返回了 800 行 JSON。小李懵了。他真正想做的不是看到数据而是选几条走审批流程。更麻烦的是审批环节。他问 AI把退货金额超过 5 万的单子提交给张总审批。AI 回复请从以下 47 个审批模板中选择1. 标准退货审批 2. 大额退款流程 3. 跨区调拨退库……小李翻了两屏还没看完最后默默打开浏览器登录 ERP 网页端手动操作了 15 分钟。这不是 AI 不够聪明而是纯文本对话本身就不适合复杂的任务型交互。选模板、填表单、点确认、传附件、勾选明细行——这些在 Web 页面上点两下就能完成的事在聊天窗口里变成了灾难。每次多轮选择都在消耗 token每次歧义理解都可能触发错误操作。一个原本 30 秒能完成的审批提交在 AI 对话里可能消耗 10 轮交互、烧掉几千个 token最后还因为理解偏差填错了审批人。2025 年MCPModel Context Protocol让 AI Agent 连上了万千工具。但它解决的是能不能连的问题——像 USB 统一了接口形状。当工具需要人机协作、需要复杂输入输出时MCP 的标准工具调用接口就显得力不从心了。MCP Apps 应运而生。它不是在 Agent 层再造一套 UI 框架而是让 SaaS 厂商直接把既有的扩展能力——PaaS、低代码、插件、行业包——暴露为标准化的 UI 资源。想象一下小李在企业微信里说提交退货审批对话窗口直接弹出一个 400x600 的小界面——退货单列表、审批人选择、备注输入框、提交按钮全部内嵌在聊天上下文中。表单用的是客户自己配置的审批模板字段校验和客户在 Web 端用的一模一样。点完提交界面关闭AI 继续对话“已提交 3 条退货申请给张总预计 2 小时内审批完成。”这就是 MCP Apps 要解决的问题。不是让 AI 更聪明而是让 AI 更懂得在什么时候闭嘴把界面交给业务系统。二、MCP Apps 到底是什么MCP Apps 是 MCP 规范 2026 年 1 月版本引入的正式扩展。它的核心机制可以用三个关键词概括ui:// 资源协议、沙箱 iframe 渲染、标准桥接协议。ui:// 资源把 UI 当作一种 MCP 资源在 MCP 中资源Resource通常指文档、数据库记录、日志文件——用 file:// 或 https:// 这样的 URI 标识。MCP Apps 引入了一种新类型ui://。一个 MCP App 在注册时声明自己提供 UI 能力并给出一个类似 ui://grocery/store-dashboard.html 的 URI。当 AI Agent 判断当前任务需要人机协作界面时它会向 MCP App Server 请求这个资源。Server 返回的内容类型mimeType是特殊的text/html;profilemcp-app这个 profilemcp-app 标记告诉 Agent“这不是普通网页这是一个需要在沙箱中渲染的 MCP 应用界面。”这里的巧妙之处在于复用了 MCP 已有的资源抽象。SaaS 厂商不需要学习新的 API 规范只需要按照资源提供的方式返回 HTML——只不过这次的资源是一张可交互的界面。沙箱 iframe 桥接协议Agent 宿主比如一个支持 MCP 的企业微信机器人或 Slack 客户端收到这个 HTML 后会把它放进一个严格隔离的 iframe 沙箱中运行。沙箱限制了脚本访问外部 DOM、Cookie 和本地存储的能力确保第三方 App 不会窃取对话上下文或用户凭证。但沙箱里的界面需要和 Agent 通信——获取上下文、提交结果、触发后续工具调用。这就需要一套标准桥接协议。MCP App 通过 window.parent.postMessage 与宿主 Agent 交换消息协议涵盖了初始化握手与上下文传递App 启动时获取当前会话上下文如用户信息、租户 IDUI 事件上报按钮点击、表单提交、选项切换等事件通知 Agent工具调用请求App 内的操作可以反向触发 MCP 工具调用生命周期状态同步加载中、就绪、错误、关闭等状态通知这套桥接协议是 MCP Apps 的灵魂。它让沙箱里的界面和 Agent 形成了双向通道——不是单向的展示而是真正的协作。四个不是厘清边界MCP Apps 很容易和一些既有概念混淆。明确说它不是以下四种东西不是 A2UI。 A2UI 的思路是在 Agent 层再造一套 UI 描述语言让 AI 动态生成界面。问题是 AI 生成的界面不稳定今天和明天长得不一样而且很难对接复杂的客制化逻辑。MCP Apps 则是 SaaS 厂商自己写 HTML/CSS/JS完全控制呈现逻辑。界面是开发者写的不是 AI 编的。不是网页链接。 ui:// 返回的 HTML 不直接暴露给用户浏览器而是在 Agent 宿主内渲染。它依赖 MCP 桥接协议通信脱离 Agent 环境就无法运行。你不可能把这个链接贴到浏览器地址栏里打开。不是小程序。 不需要微信/钉钉/飞书的审核和宿主支持也不绑定任何特定平台。只要有 MCP 兼容的 Agent 客户端就能运行。这意味着跨平台的真正可能性——同一个 MCP App 可以在企业微信、Slack、自建 Portal 中无缝运行。不是传统 iframe 嵌入。 虽然底层用了 iframe但它遵循 MCP 标准协议具备完整的生命周期管理、工具命名空间隔离和上下文传递机制。不是简单地在页面里嵌一个框而是在 AI 对话流中嵌入一个有身份、有状态、有协议约束的应用单元。一张表说清楚差异维度 MCP Apps A2UI 网页链接 私有小程序 传统 iframeUI 由谁定义 SaaS 开发者 AI 动态生成 任意 Web 开发者 平台审核的开发者 SaaS 开发者运行环境 MCP Agent 宿主 Agent 内部渲染 外部浏览器 企业微信/钉钉等 任意网页与 Agent 交互 标准桥接协议 原生集成 无 平台私有 JS-SDK 自定义 postMessage上下文传递 内置 内置 需手动透传 需平台适配 需自行实现部署成本 低复用现有能力 高需训练/UI 生成 中 高平台绑定 中标准程度 MCP 开放规范 厂商私有 开放 Web 标准 平台私有 无统一标准一句话总结MCP Apps 是 SaaS 厂商把既有业务界面切片成标准化组件嵌入到 AI 对话中的桥梁机制。三、为什么老 SaaS 需要它中大型企业的客制化现实做过中大型 SaaS 交付的人都知道一个事实没有一个客户会原封不动地用你的标准产品。字段要扩展——客户在标准订单上加 20 个自定义字段。表单布局要调整——采购部要求把供应商信息放在第一屏。校验逻辑要自定义——医药行业需要额外的合规性检查。审批节点要按组织架构重新画——集团有 7 级审批子公司只有 3 级。甚至整个行业模块都要替换——制造业客户要替换掉默认的库存计算逻辑。Salesforce 靠 Force.com 成了万亿级公司北森花十年从 HR SaaS 转型 PaaS 平台用友金蝶的技术架构越来越像低代码平台——这背后的逻辑是一样的软件的价值最终由客户业务逻辑定义而不是由软件厂商定义。这些客制化能力——字段扩展、低代码表单、审批流设计器、行业包/插件市场——是 SaaS 厂商花了十几年、投入 billions 积累起来的核心资产。扩展能力是另类护城河为什么 Salesforce 的客户迁移成本那么高因为客户的业务逻辑已经长进了系统里。几百条自定义校验规则、几十个审批模板、几千个扩展字段、几十个工作流——迁移这些客制化配置的成本往往比重新买一套软件还高。但 AI 来了以后这些护城河面临一个尴尬的局面大模型厂商不愿意碰扩展能力。为什么扩展能力是苦力活。它需要理解每个客户的客制化配置、需要对接复杂的表单渲染引擎、需要处理多租户的权限和数据隔离。重交付、低毛利和 AI 厂商追求的一次训练、无限复制商业模式天然冲突。结果就是AI 助手可以帮你查数据——因为查询是标准化的但很难帮你走流程——因为流程已经被客户改得和标准产品完全不同了。AI 面对客制化的 ERP就像一个会讲通用英语的人被扔进了方言区——能听懂大意但搞不定细节。MCP Apps 的桥梁价值MCP Apps 提供了一条优雅的出路SaaS 厂商不需要为 AI 重写一套界面只需要把现有的扩展能力——PaaS 页面、低代码表单、审批设计器——包装成 ui:// 资源。对客户的价值是直观的AI 助手终于能理解他们的客制化流程了。不是在对话里猜来猜去而是直接弹出客户自己配置过的业务界面——那个用了三年的审批表单、那个加了二十个自定义字段的订单页面原封不动地出现在 AI 对话里。对 SaaS 厂商的价值更深层稳定基于既有的、经过生产验证的扩展架构不是 AI 生成的不确定代码。表单校验通过了十年的生产考验不会因为模型版本更新而出错。不消耗 token复杂交互在本地 iframe 里完成不需要多轮 LLM 调用。一个五步审批流程用户点五次鼠标完成而不是和 AI 对话十轮。成本低复用现有 PaaS/低代码能力不需要额外投入 AI 工程团队。懂业务扩展配置的老人就能干好不需要prompt 工程师。老 SaaS 的客制化能力不是负担是待开采的金矿。MCP Apps 给了它一把铲子。四、OpenClaw.NET 是怎么实现的项目背景OpenClaw.NET 是一个 .NET 生态的原生 AI Agent 运行时近期在 mcpapp-ext 分支中完成了对 MCP Apps 的完整支持。选择 .NET 并非偶然——大量企业级 SaaS尤其是 ERP、CRM、HR 系统的后端正是基于 .NET 构建的。原生支持意味着这些系统可以在不引入额外技术栈的情况下直接把业务界面暴露为 MCP Apps。这不是追逐技术潮流而是务实的工程判断企业 SaaS 的扩展能力本来就写在 .NET 里何必为了 AI 再造一个轮子核心组件一条从发现到服务的流水线OpenClaw.NET 的 MCP App 支持由四个核心组件构成形成一条完整的流水线Discovery发现→ Registry注册→ Server服务→ ToolProvider工具提供McpAppDiscovery负责扫描所有 MCP App 的 Manifest 文件openclaw.mcpapp.json。支持文件系统监控和热更新——App 的 Manifest 变更后自动重新发现不需要重启服务。这意味着你可以在不中断运行的情况下新增或更新 MCP Apps。McpAppRegistry维护已发现 App 的注册表管理 App 的元数据、能力和状态。它是整个生命周期的指挥中心协调组件之间的状态同步。McpAppServer作为 MCP 协议的服务端处理 Agent 的工具调用请求和资源请求。当 Agent 请求 ui:// 资源时由 Server 返回对应的 HTML 内容。Server 同时管理着与各个 App 后端stdio 或 HTTP的长连接。McpAppNativeTool把每个 App 的工具集封装为标准的 MCP Tool注入到 Agent 的工具调用体系中。关键特性是工具命名前缀隔离——每个 App 的工具名都带有前缀如 grocery.query-inventory避免不同 App 之间的命名冲突。想象一下 20 个 MCP App 同时注册没有命名空间隔离的话query 工具来自哪个 App 就完全混乱了。Manifest一个 JSON 定义全部每个 MCP App 只需要一个 openclaw.mcpapp.json 文件{“id”: “grocery-inventory”,“name”: “Grocery Inventory Dashboard”,“transport”: “http”,“url”: “https://localhost:5001/mcp”,“hasUi”: true,“uiResourceUri”: “ui://grocery/store-dashboard.html”,“capabilities”: [“tools”, “resources”, “prompts”],“toolNamePrefix”: “grocery.”}字段含义一目了然transport 和 url 定义 MCP 连接方式支持 stdio 和 http 两种hasUi 和 uiResourceUri 声明 UI 能力capabilities 列出该 App 支持的 MCP 特性工具、资源、提示词toolNamePrefix 确保工具命名空间隔离。这个设计的简洁性是有意为之。SaaS 厂商不需要理解 MCP 协议的细节只需要填好这个 JSONOpenClaw.NET 负责处理剩下的一切。七态生命周期每个 MCP App 在 OpenClaw.NET 中经历严格的生命周期管理状态 含义 触发条件Discovered Discovery 扫描到 Manifest 文件 文件系统扫描Validated Manifest 格式和依赖校验通过 JSON Schema 校验Loaded App 的 MCP Server 连接成功 首次连接成功Running 完全可用可被 Agent 调用 工具和资源就绪Stopped 被管理员手动停用 管理操作Failed 连接失败或运行中出错 异常捕获Disabled 配置标记为禁用 配置项设置状态转换由 SemaphoreSlim 并发锁保护确保高并发场景下不会出现竞态条件。一个 App 从 Discovered 到 Running 的完整路径每一步都有日志记录和错误回退机制。UI 代理Host Proxy Browser RoutesMCP App 的 UI 资源如何安全地暴露给 AgentOpenClaw.NET 采用了一套双层代理机制Gateway Host Proxy所有 ui:// 请求先经过网关层的 Host Proxy负责身份验证、权限校验和请求路由。App 的实际服务端地址不直接暴露给 Agent 端。Browser RoutesAgent 端通过标准化的 Browser Routes 请求 UI 资源URL 格式统一为 /mcpapp/{app-id}/ui/{resource-path}。路由层负责把请求转发到对应的 MCP App Server。// Browser Routes 的核心路由配置app.MapGet(“/mcpapp/{appId}/ui/{*resourcePath}”,async (string appId, string resourcePath) {var app registry.GetApp(appId);if (!app.HasUi) return Results.NotFound();var html await proxy.FetchUiResourceAsync( app.UiResourceUri, resourcePath ); return Results.Content(html, text/html;profilemcp-app);});这套机制的核心目的是隔离与代理App 服务端运行在各自的地址空间Agent 永远不会直接访问它们。所有通信都通过受控的代理层安全性和可观测性都得到保障。关键接口设计OpenClaw.NET 定义了一个简洁的 IMcpAppInfoProvider 接口用于向 Agent 暴露 App 的 UI 信息public interface IMcpAppInfoProvider{bool HasUi { get; } // 是否提供 UI 能力string UiResourceUri { get; } // ui:// 资源地址}Agent 在工具调用前可以通过这个接口判断当前 App 是否支持界面渲染从而决定走纯文本工具调用还是UI 嵌入路径。这个判断是动态的——同一个 App 的同一个工具在某些场景下纯文本返回就够了在另一些场景下则需要弹出 UI。技术选型上回归 .NET 原生不是情怀而是务实的工程判断——企业 SaaS 的扩展能力本来就写在这里何必为了 AI 再造一个轮子五、一个真实的例子GroceryInventory理论说完了看一个从配置到运行的完整实例。假设你经营一个连锁杂货店库存系统想把库存管理面板暴露为 MCP App。第一步写 Manifest在项目的根目录或指定的扫描路径创建 openclaw.mcpapp.json{“id”: “grocery-inventory”,“name”: “Grocery Inventory Dashboard”,“transport”: “http”,“url”: “https://localhost:5001/mcp”,“hasUi”: true,“uiResourceUri”: “ui://grocery/store-dashboard.html”,“capabilities”: [“tools”, “resources”, “prompts”],“toolNamePrefix”: “grocery.”}注意 toolNamePrefix: “grocery.”——这个 App 的所有工具都会以 grocery. 开头比如 grocery.query-inventory、grocery.update-stock、grocery.check-expiry不会和其他 App 的工具冲突。第二步实现 UI 资源在服务端提供 ui://grocery/store-dashboard.html 对应的内容。这是一个标准的 HTML 页面包含库存查询表单、数据表格和操作按钮。它通过 MCP 桥接协议与 Agent 通信——初始化时获取上下文比如当前店铺 ID用户提交时上报事件。这个 HTML 页面可以用任何前端技术栈编写React、Vue、原生 JavaScript甚至是你的 PaaS 低代码平台自动生成的页面。唯一的约束是它需要通过 postMessage 遵循 MCP 桥接协议。第三步OpenClaw.NET 自动完成其余工作OpenClaw.NET 启动时会Discovery 扫描并发现这个 ManifestRegistry 校验格式、注册元数据Server 建立与 https://localhost:5001/mcp 的 HTTP 连接ToolProvider 提取工具列表前缀设为 grocery.状态流转Discovered → Validated → Loaded → Running现在当用户在 Agent 对话中说查看库存Agent 调用 grocery.query-inventory 获取数据同时发现该 App 有 UI 能力。它会请求 ui://grocery/store-dashboard.html用户在聊天窗口中直接看到库存面板——筛选、排序、导出全部在这个嵌入界面中完成。用户选中了几个低库存商品点击生成采购单App 通过桥接协议通知 AgentAgent 再调用 grocery.create-purchase-order 工具。整个过程无缝衔接。三步配置零代码改动现有业务系统。六、展望Agent 的下一步从对话工具到对话应用MCP Apps 代表了一个重要的范式转变。第一代 AI Agent 是对话工具调用——你说一句话Agent 调一个函数返回一段文本。交互是一维的、线性的。适合查天气、算数字、写邮件。第二代 AI Agent 正在变成对话应用嵌入——对话是主航道但复杂的任务可以弹出一个完整的应用界面用户在界面里完成操作后无缝回到对话流。Agent 宿主从单纯的调度器进化成了应用容器。这个转变的意义不亚于从命令行到图形界面的跃迁。它让 AI 助手真正具备了处理复杂业务的能力——不是通过更长的 prompt 或更贵的模型而是通过与既有业务系统的深度整合。当 AI 遇到复杂业务时最好的交互不是让 AI 学会所有业务逻辑而是让 AI 知道什么时候该把界面交给专业的业务系统。SaaS 厂商的三阶段落地路径对于 SaaS 厂商来说拥抱 MCP Apps 不需要一步到位阶段一高频查询场景1-2 个月把最常用的数据查询界面包装成 MCP Apps。让用户在 AI 对话中直接看报表、选数据、点筛选而不是在聊天窗口里翻 JSON。这是投入最小、用户感知最明显的起点。阶段二扩展能力开放3-6 个月把 PaaS 表单设计器、审批流配置界面、低代码仪表盘逐步暴露为 ui:// 资源。AI 助手终于能理解客户的客制化配置了——客户用了三年的自定义表单原封不动地出现在 AI 对话里。阶段三MCP App 生态市场6-12 个月开放第三方开发者基于你的 PaaS 能力构建 MCP Apps。行业伙伴可以开发垂直领域的 MCP AppISV 可以在你的平台上交付定制化解决方案。从 SaaS 厂商变成平台从卖软件变成卖生态位。成熟度模型MCP Apps 的落地可以按四个成熟度来评估协议兼容——能注册、能发现、工具能调用Agent 和 App 说同一种语言视觉兼容——UI 在 Agent 宿主中正确渲染不崩不卡样式不突兀行为兼容——桥接协议通信正常数据能进能出操作有反馈体验兼容——用户感觉这本来就是 AI 的一部分没有割裂感用完还想用