MCP Apps 会取代 A2UI 吗？

不会。MCP 提供工具与资源，MCP Apps 提供沙箱化 Web UI，A2UI 提供声明式原生 UI 意图，系统可以组合使用。

哪种模式最能保持宿主设计系统？

A2UI over MCP，因为宿主渲染器会把校验后的意图映射到自己的受控原生组件。

有效的问题不是“A2UI 还是 MCP Apps”，因为二者控制不同边界。MCP 连接模型、工具与资源；MCP Apps 在隔离运行时中承载定制 Web 体验；A2UI 把声明式 UI 意图交给宿主渲染器。官方现已给出三种组合方式。

MCP Server 以 application/a2ui+json 媒体类型和 a2ui:// URI 暴露 A2UI 资源。静态 UI 可通过资源读取；参数化 UI 可由工具调用返回。

表单、审批卡片、表格、图表和状态页适合此模式。渲染保持原生，宿主继续控制设计令牌、无障碍、导航、遥测与 Action 策略。服务端必须校验输入，客户端也必须校验返回的 A2UI Schema。

经过审核的 A2UI Catalog 组件可以包装 MCP App。原生组件围绕专用编辑器、画布、游戏或旧 Web 模块布局，这些模块若用 Catalog 原语重建，成本可能过高。

包装器属于高权限能力。应限制来源与沙箱权限，保持消息桥窄且有类型，向用户展示远程来源，并阻止嵌入应用冒充宿主可信控件。不得通过宽泛组件属性传递认证令牌或私有模型上下文。

当宿主支持 MCP Apps 但没有原生 A2UI Runtime 时，MCP App 可以打包 A2UI 渲染器。这是一条兼容路径，也允许沙箱创建生成式子 Surface。

代价是最终 UI 仍在 iframe 中。宿主原生焦点管理、无障碍语义、样式与导航不会自动继承。必须测试完整辅助技术路径，不能只假设内部渲染器会继承外部宿主行为。

应优先用 A2UI over MCP 表达需要遵循宿主外观和行为的常规产品流程；只有确实需要开放客户端运行时的独立模块才引入 MCP App；只有现有宿主缺少原生 A2UI 能力时，才把 A2UI 放入 MCP App。

三种模式都需要威胁建模。声明式 JSON 降低任意代码传输风险，但 URL、Action、文本与数据仍不可信；iframe 隔离限制影响范围，却无法阻止误导内容或不安全桥接调用。部署前执行集成指南与生产安全清单。