Google A2UI Team 在 2026 年 6 月 17 日发布 A2UI + MCP Apps 文章，讨论 agentic workflows 如何由文字交流走向更丰富的互动 UI。这是 AI agent 产品化的重要议题，因为很多真实任务不是一句答案就完结，而是需要表单、图表、核准卡、控制项和状态同步。
文章指出，开发者一直面对两难：MCP Apps 可以用 iframe 和标准 web 技术做高度自定义界面，但可能带来设计不一致、性能和安全封装问题；A2UI 则用 declarative JSON 描述 UI，由 host application 用原生 component rendering，安全和一致性较好，但自由度受限于 component catalog。
Google 今次提出的方向，不是二选一，而是三种混合架构。第一种是 A2UI over MCP servers，MCP 负责 tool connectivity 和 data access，A2UI 负责 frontend component rendering。这让 MCP server 不只回文字，也可以回 application/a2ui+json，让 host 用自己的设计系统直接渲染表单、图表或卡片。
第二种是把 MCP Apps 放入 A2UI components。当某些模块需要高度自定义、状态密集或复杂互动，例如游戏、座位选择或特殊工作台，开发者仍可使用 iframe，但由 A2UI component 作为受控 wrapper，并通过事件循环与外层 agent 状态同步。
第三种是把 A2UI 放入 MCP Apps，让旧系统或非 A2UI host 也可以逐步加入 agent-driven UI。这对企业很实际，因为很多内部系统不可能一次重写；如果 MCP App 自带 A2UI renderer，就可以在既有 iframe 容器内加入动态控制项和 agent 操作流程。
这篇文章的价值，在于把 agent UI 问题拆得很清楚。真正可用的 enterprise agent 不应只懂「讲答案」，还要能在合适位置交出可操作界面：让人选项、调整参数、批准动作、查看图表、确认风险。文字是入口，但 UI 才是很多工作流的控制面。
对企业和开发团队来说，A2UI + MCP Apps 的讯号是 agent platform 需要同时处理安全、设计一致性、可移植性和自定义能力。未来 AI workflow 的竞争不只是哪个模型最好，而是谁能把模型、工具、资料和互动界面接成稳定产品体验。
