MCP Apps 与 AI 原生界面测试:聊天窗口正在变成工作台

AI 的输出不再只是文字

早期 AI 应用最常见的交互方式是聊天。

用户问：

帮我分析这个销售数据。

AI 回答一段文字。

这种方式适合解释、总结、草拟和问答，但不适合所有任务。

当任务变复杂时，纯文字会变得笨拙。

例如用户想：

对比多个报价方案。
筛选一批客户。
确认退款金额。
调整图表指标。
审批一笔高风险操作。
在候选结果里选择一个。
查看 Agent 调用工具后的结构化结果。

这时用户更需要一个可交互界面，而不是一大段文字。

MCP Apps 和类似的 AI 原生 UI 技术，就是在解决这个问题：

让 Agent 不只输出文本，还能在对话中呈现可交互组件，让用户在聊天窗口里完成真实工作。

聊天窗口正在变成工作台。

什么是 MCP Apps

MCP Apps 可以理解为基于 MCP 的可交互应用界面标准。

它让 MCP Server 不只暴露工具，还能把工具结果和交互界面关联起来。

在支持 MCP Apps 的 Host 中，UI 可以嵌入在聊天体验里，并通过标准桥接机制和 Host 通信。

以 OpenAI Apps SDK 的兼容文档为例，ChatGPT 支持 MCP Apps 的嵌入式 UI 标准，UI 运行在 iframe 中，并通过基于 postMessage 的 ui/* JSON-RPC 桥与 Host 通信。

通俗地说：

MCP Tool 负责“做事”。
MCP Resource 或 UI Resource 负责“展示界面”。
Host 负责把界面嵌入聊天环境。
用户可以在界面中查看、选择、确认、提交。
界面和 Agent 之间通过标准事件同步状态。

这和传统网页不同。

传统网页通常是用户主动操作页面。AI 原生界面则是 Agent 根据任务动态唤起合适组件，并把组件状态纳入对话上下文。

为什么 AI 需要界面

纯文本有几个天然限制。

1. 文本不适合展示复杂结构

例如表格、日历、地图、图表、审批单、订单列表，用文字描述都不如界面清楚。

2. 文本不适合高风险确认

AI 说：


我将退款 5000 元给客户 A。

这不够。

审批人应该看到：

客户是谁。
订单号是什么。
金额是多少。
退款原因是什么。
依据是什么。
是否超出规则。
点击后会发生什么。

这些更适合用结构化界面展示。

3. 文本不适合反复调整

用户可能想筛选、排序、改参数、勾选选项、切换图表。

如果每一步都靠自然语言来回说，会很慢。

4. 文本容易造成信息不对称

Agent 的摘要可能漏掉关键字段。

界面可以直接展示工具参数、原始证据、影响范围和审批按钮，降低误导风险。

AI 原生界面和普通前端有什么区别

AI 原生界面不是普通页面搬进聊天框。

它有几个特点：

维度	普通前端	AI 原生界面
启动方式	用户打开页面	Agent 根据任务唤起
数据来源	页面主动请求接口	工具调用、会话上下文、用户输入共同驱动
状态来源	前端状态和后端状态	前端、Host、Agent、工具结果多方同步
风险	用户误操作	用户误操作加 Agent 误引导
测试重点	功能、兼容、性能	UI、工具、对话、权限、状态和审计

AI 原生界面多了一个关键变量：Agent。

Agent 可能会：

选择错误组件。
传错工具结果。
用文字误导用户点击。
忽略用户在 UI 中的修改。
把 UI 状态误读为最终确认。
在组件未完成时继续执行。

所以测试必须覆盖“对话加 UI 加工具”的联动。

MCP Apps 的典型链路

一个简化链路可能是：

用户提出任务。
Agent 决定调用某个 MCP Tool。
Tool 返回结构化结果。
Host 根据工具元数据加载对应 UI Resource。
UI 展示结果或操作表单。
用户在 UI 中选择、修改或确认。
UI 通过桥接机制通知 Host。
Host 将状态反馈给 Agent 或调用后续工具。
Agent 继续推理或完成任务。

这个链路里有很多测试点：

Tool 结果是否正确。
UI 是否加载正确。
UI 是否展示完整字段。
用户操作是否同步。
Agent 是否理解 UI 状态。
高风险动作是否需要确认。
后续工具是否使用最新参数。
最终业务状态是否正确。

UI 组件测试重点

1. 展示准确性

测试 UI 是否准确展示工具结果。

例如退款审批组件要展示：

订单号。
客户名。
退款金额。
支付方式。
退款原因。
规则校验结果。
风险提示。
审批动作。

常见问题：

金额单位错误。
时间时区错误。
字段缺失。
排序错误。
状态标签错误。
空数据展示误导。
敏感字段未脱敏。

2. 交互正确性

测试用户操作是否正确改变状态。

包括：

勾选。
输入。
筛选。
排序。
分页。
上传。
下载。
确认。
撤销。
取消。

AI 原生界面尤其要测：

用户修改参数后，Agent 是否使用修改后的值。
用户取消后，Agent 是否停止执行。
用户只查看未确认时，是否不会执行写入工具。
多轮对话后，UI 状态是否仍然一致。

3. 状态同步

状态可能存在于多个地方：

UI 内部状态。
Host 会话状态。
Agent 上下文。
MCP Tool 返回结果。
后端业务系统。

测试要验证这些状态不会打架。

例如：

用户在 UI 中把退款金额从 500 改成 300。Agent 后续调用工具时必须使用 300，而不是之前的 500。

4. 权限控制

UI 里不能因为按钮可见，就代表用户有权点击。

测试点：

不同角色看到不同操作。
无权限按钮不可见或不可用。
前端禁用不能替代后端校验。
Agent 不能通过工具绕过 UI 权限。
组件不能展示无权限数据。

5. 审批真实性

高风险操作必须让用户看清楚真实影响。

审批组件应展示：

操作对象。
操作类型。
关键参数。
金额或范围。
证据来源。
风险等级。
是否可撤销。
审批后会调用哪个工具。

不能只展示：


是否同意 AI 的建议？

审批要让人看到事实，而不是让人相信 AI 的一句总结。

对话和 UI 联动测试

AI 原生界面最容易出的问题，是对话和 UI 状态不一致。

场景 1：Agent 忽略 UI 修改

用户在界面里修改配送地址。Agent 仍按旧地址下单。

测试方法：

构造用户修改 UI 的样本。
验证后续工具参数。
验证最终订单状态。

场景 2：Agent 提前执行

用户只是打开审批组件查看。Agent 误以为用户已确认，直接提交。

测试方法：

区分 view、edit、confirm、cancel 事件。
验证只有 confirm 才能触发写入工具。

场景 3：UI 显示成功，但后端失败

组件显示“已提交”，但后端工具调用超时。

测试方法：

模拟工具失败。
验证 UI 回滚或展示待确认状态。
验证 Agent 不会宣布完成。

场景 4：多轮对话覆盖状态

用户先在 UI 中选 A，后面在对话中说“还是改成 B”。系统必须明确最终状态。

测试方法：

验证冲突时是否要求确认。
验证 trace 记录最终参数来源。

安全测试重点

1. iframe 和消息桥安全

嵌入式 UI 通常通过 iframe 和 Host 通信。

测试点：

消息来源校验。
目标 origin 限制。
不接收未知消息。
不泄露会话数据。
不允许第三方脚本读取敏感上下文。
UI 不能调用未授权工具。

2. UI 到工具调用安全

如果 UI 可以触发工具调用，就要验证：

工具调用是否仍经过 Host 策略。
参数是否校验。
用户是否有权限。
高风险动作是否需要确认。
重复点击是否幂等。

3. 模型可见上下文安全

UI 可能把状态更新给模型。

测试要验证：

不把敏感字段无必要地放进模型上下文。
不把 Token、密钥、内部 ID 暴露给模型。
不把用户隐私写入长期记忆。
不让恶意 UI 文案诱导模型越权。

4. Clickjacking 和视觉误导

AI 原生界面可能被用来诱导用户点击。

测试点：

按钮文案是否清晰。
高风险按钮是否突出风险。
取消和确认是否容易区分。
金额和对象是否靠近操作按钮。
是否防止透明遮罩或误导层。

一个案例：AI 采购比价组件

任务：


帮我比较这三家供应商报价，并生成采购建议。

Agent 调用工具后，展示一个比价组件。

组件应展示

供应商名称。
报价金额。
交付周期。
付款条件。
历史评分。
合同风险。
推荐理由。
证据来源。

用户可以操作

筛选供应商。
查看风险详情。
修改权重。
选择推荐方案。
生成审批草稿。

测试重点

数据是否来自正确报价单。
金额和币种是否正确。
Agent 推荐是否有证据。
用户修改权重后推荐是否更新。
生成审批草稿前是否二次确认。
未确认前是否不进入采购流程。
审批草稿是否保留用户选择和证据。

这个案例说明，AI 原生界面测试必须同时看产品体验和业务状态。

AI 原生界面评测指标

能力	指标
展示准确性	字段准确率、金额错误率、状态标签错误率
状态同步	UI 与工具参数一致率、最终状态一致率
交互完成	用户任务完成率、取消成功率
高风险操作	未确认执行率、重复提交率
权限	无权限数据展示率、无权限操作成功率
安全	消息来源校验通过率、敏感上下文泄露率
可用性	用户纠错率、误点率、人工接管率
追溯	UI 事件和工具调用 trace 完整率

MCP Apps 上线清单

UI 是否准确绑定对应 MCP Tool？
工具结果是否完整映射到 UI 字段？
UI 修改是否能同步到 Agent 和后续工具调用？
是否区分查看、编辑、确认、取消事件？
高风险操作是否展示真实参数和影响范围？
前端权限和后端权限是否都校验？
iframe 或嵌入组件是否校验消息来源？
UI 是否避免把敏感信息写入模型上下文？
是否测试重复点击、刷新、断连和超时？
是否记录 UI 事件、工具调用和最终业务状态？
是否支持人工接管？
是否有跨 Host 或降级兼容测试？

总结

MCP Apps 和 AI 原生界面让聊天窗口从“问答入口”变成“业务工作台”。这会显著提升用户体验，也会带来新的测试复杂度。

可以用一句话总结：

AI 原生界面测试不能只看组件好不好看，而要验证 Agent、UI、工具、权限、用户确认和业务状态是否真的一致。