Google 最近分享了一份关于 A2UI 与 MCP Apps 集成的架构指南，直指 Agent 界面开发中一个真实的工程难题：如何在保证安全与一致性的前提下，给前端足够的定制空间。A2UI 走的是声明式路线，用 JSON payload 描述界面，宿主用原生组件渲染，好处是跨平台一致、攻击面小，代价是组件库被锁死，想做个花哨的交互基本没门。MCP Apps 反过来，直接在 iframe 里跑标准 Web 技术，想怎么画怎么画，但碎片化、性能损耗和安全沙箱全是坑。Google 的解法不是二选一，而是把两者缝起来——通过 MCP 服务器输出 A2UI 的 JSON，由宿主原生渲染，实现"一次编写、多端原生"的效果。
具体到落地，Google 列出了三种模式。第一种是 A2UI 走 MCP Resources 通道，客户端订阅资源变更后拉取 JSON payload 渲染，适合配置面板、表单这类低频更新场景。第二种走 Tool 调用，每次交互触发工具返回 UI 描述，对话流里动态生成卡片或图表天然适配。第三种更激进：静态场景把 A2UI payload 直接塞进 MCP 服务器的初始化响应或 Resources 列表，客户端无需额外请求即可渲染；动态场景则把 payload 缓存在客户端存储里，通过版本号或哈希校验触发增量更新。Google 明确表示正在考虑把 A2UI 原生写进 MCP 协议层，届时 MCP 客户端可以直接声明自己支持 A2UI 渲染能力，服务器按需投递。
对正在做 Agent 前端的团队来说，这套方案的现实意义在于：不用再死磕"全 Web 化"或"全原生化"的单一路线。A2UI 处理标准化、安全敏感的部分，MCP Apps 兜住需要高自由度定制的长尾场景，两者通过统一的 MCP 传输层对话。Google 给出的不是一份理论白皮书，而是带 JSON schema 示例和调用时序的工程蓝图，本质上是在 Agent UI 这片尚未定型的新战场上，抢先划定一套可落地的参考实现。
