随着智能体工作流从简单的文本交互演进为丰富的用户界面，开发者面临着一个持久的两难选择：深度定制与无缝集成不可兼得。

直到现在，开发者通常不得不在两条截然不同的路径之间做出选择：

• 模型上下文协议（MCP）应用可以在 iframe 内使用标准 Web 技术提供创意自由度。然而，这些应用对 iframe 的依赖会导致碎片化的用户体验，具体表现为设计系统冲突或多余滚动条等美观上的不一致，同时还在计算性能和安全封装方面带来显著障碍。
• 智能体到用户界面（A2UI）采用声明式框架。A2UI 不发送原始 HTML、CSS 和 JavaScript，而是使用 JSON 负载来定义渲染内容，让宿主应用通过其原生组件处理呈现。宿主应用随后安全地将这些数据转换为其自身的原生 UI 元素。虽然这能确保一致的设计和更强的安全性，但开发者被限制在特定的组件库中。这种方法提供了高性能、安全且集成的体验，尤其适用于图表和表单等结构化数据，但在处理复杂客户端逻辑时则力不从心。

为了解决这些权衡问题，我们分享了三种架构模式，并附有实现指南和示例代码，以展示 A2UI 与 MCP 应用的无缝集成。我们正在考虑为 MCP 添加扩展以支持 A2UI，从而使这些模式更易于采用。如果您感兴趣，请告知我们。

将这两种方法整合起来，开发者可以为标准 UI 元素利用原生组件渲染，同时将自定义 iframe 嵌入保留给高度定制、复杂的体验场景。

模式 1：通过 MCP 服务器提供 A2UI

通过 MCP 服务器提供 A2UI，可以让开发者为其工具添加丰富的原生渲染 UI，作为 MCP 应用的替代方案。它将广泛采用的 MCP 工具连接的简洁性与 A2UI 原生渲染能力相结合。

这种方法降低了开发者采用生成式 UI 的门槛。它带来了动态 UI 的优势，却无需承受构建完整智能体间（A2A）架构的开销，也无需处理复杂的发现机制。

架构优势

• 绕过 iframe 限制：在 MCP 服务器中使用 MCP Apps 作为 UI，会导致视觉脱节和延迟。A2UI-over-MCP 绕过了 iframe，让宿主应用能够使用自身设计系统原生渲染智能体的意图。
• 关注点分离：MCP 负责后端工具和数据访问，A2UI 负责前端组件渲染。这样可以使智能体逻辑保持清晰，专注于推理，而不是 UI 实现细节。
• 增强环境可移植性：MCP 服务器可以将数据输入到 A2UI 客户端，该客户端可在 React、Flutter 或 Angular 上渲染，无需自定义适配。它提供了“一次编写，随处原生渲染”的能力，解决了服务器必须为每个不同界面准备独特响应的问题。
• 简化安全性：来自 MCP 工具的数据与 A2UI 的默认安全 JSON 架构集成。与传递原始 HTML 的传统方法不同，A2UI 采用基于能力的安全模型，客户端仅从预定义目录中渲染受信任的组件。
• 加速开发周期：现在，编写 MCP 工具或定义资源的专业能力可以直接转化为生成复杂用户界面的能力。通过使用 A2UI Agent SDK，工程团队可以绕过手动编写 JSON 的复杂性，因为该库原生处理架构强制和验证。

实际演示

下面是一个基于 A2UI-over-MCP 架构的演示应用。该应用由两个面板组成。左侧面板包含一个简单的表单，允许用户选择烹饪风格和蛋白质类型；右侧面板显示一张食谱卡片。用户在左侧面板中选择烹饪风格和蛋白质类型，然后点击“获取食谱”按钮，获取新的食谱卡片并显示在右侧面板上。

此应用中的两个面板均由 A2UI 生成，并且均采用 A2UI-over-MCP 架构，其中 A2UI 负载直接从 MCP 服务器获取，并使用 A2UI 框架直接渲染。通过利用 A2UI 框架来渲染 UI，宿主应用无需维护任何 UI 组件逻辑，只需将自身的主题应用于 A2UI 组件，即可保持设计一致性。

底层原理：它是如何工作的

MCP 服务器不再返回标准文本响应或打包的 HTML/JS 网页应用，而是返回结构化的 JSON 负载，并指定特定的 MIME 类型：`application/a2ui+json`，从而返回 A2UI 负载。

{
  "content": [
    {
      "type": "resource",
      "resource": {
        "uri": "a2ui://dynamic-ui/recipe-card",
        "mimeType": "application/a2ui+json",
        "text": "[
          { "version": "v0.9",
            "createSurface": { ... }
          }
        ]"
      }
    }
  ]
}

开发者可以利用两种不同的交付机制来传输该负载：通过 MCP 资源（`resources/read`）或通过 MCP 工具调用（`tools/call`）。无论采用哪种方法，端点都使用 `a2ui://` URI 方案。接收后，支持 A2UI 的宿主环境会自动将该 JSON 结构路由到其原生渲染引擎执行。

实现策略：静态交付与动态交付

1. 通过 MCP 资源（`resources/read`）进行静态交付

对于需要预设接口且不受对话上下文影响的工作流，开发者可以将 A2UI 负载作为标准 MCP 资源提供。宿主应用只需获取一个专用 URI（例如 `a2ui://config-panel`），服务器便直接交付不可变的 JSON 结构。

• 理想用例：隐私声明、标准化配置表单或持久化偏好设置等基础组件。
• 主要优势：这种方法可确保高可预测性和高效缓存，且零计算开销，因为它无需 LLM 实时合成 UI。

2. 通过 MCP 工具调用（`tools/call`）进行动态交付

为了解锁真正的生成式 UI 和实时数据注入，客户端可以调用 MCP 工具。后端执行逻辑以获取实时上下文，允许智能体动态组装 A2UI 布局。然后，该定制负载作为嵌入资源在 `CallToolResult` 中返回。

• 理想使用场景：响应式数据可视化、具备上下文感知能力的天气模块，或针对特定用户需求定制的个性化内容卡片。
• 关键优势：提供架构灵活性，使智能体能够构建复杂的、具有原生体验的界面，并响应用户目标。

探索代码

要查看此架构的实际运行效果，请查阅 A2UI-over-MCP 快速入门指南，运行上述演示中展示的 A2UIxMCP Recipe Studio 网页应用。该交互式演示包含一个从 MCP Resource 加载的静态 A2UI 界面（食谱选择表单）和一个由 MCP Tool 提供的动态 A2UI 界面（自定义生成的食谱卡片），两者并行运行。

理解差异：基于 MCP 的 A2UI 与基于 A2A 的 A2UI

工程团队经常询问的一个问题是，除了传输协议之外，A2UI-over-MCP 实现与原生 Agent-to-Agent (A2A) 架构有何不同。其区别在于动态性和编排复杂度的层级：

• 基于 MCP 的 A2UI（Resources）：静态且规定性的 UI。这是满足刚性结构需求（如固定数据输入表单）的最佳选择。
• 基于 MCP 的 A2UI（Tools）：基于工具参数的模板化动态 UI。它同样可以服务于静态且规定性的 UI。动态控件局限于工具的输入参数。
• 基于 A2A 的 A2UI：在受支持目录中的组件范围内，完全生成且开放。智能体拥有完整的对话上下文，并可即时驱动 UI 构建。如果需要，该方法也可以服务于模板化 UI 和静态 UI。

尽管工程师通常利用 MCP Tools 来获取确定性结果，但这些端点本质上并非仅限于静态逻辑。虽然在标准 MCP Tool 配置中使用后端大语言模型并不常见，但开发者如果愿意，可以在工具调用背后编排一个 AI 智能体层，通过 A2UI-over-MCP 架构提供更具生成式的 UI 体验。不过，驱动 UI 生成的上下文仍将局限于工具参数和预设的后端智能体提示词。

模式2. 在 A2UI 组件中运行 MCP 应用

虽然基于 MCP 的 A2UI 非常适合原生集成，但有时你需要 MCP 应用所提供的隔离性高度自定义环境。你可以通过将 MCP 应用封装在 A2UI 组件内来实现这一点，同时不影响宿主系统的原生设计系统或安全边界。通过在 A2UI 组件中封装一个 MCP 应用，工程师可以将复杂、状态密集的模块委托给安全的 iframe，以获得高度定制化的体验。

这种混合方法为工程师在处理复杂、状态密集型模块时提供了创作灵活性，同时确保主界面与宿主的原生设计保持一致，并维持稳健的状态同步协议。

架构优势

• 品牌一致性与受控委托：宿主保持对 MCP 应用 iframe 之外的用户体验的设计控制，同时审慎地将 MCP 应用内部的用户体验委托给外部工具开发者。
• 专门化能力：复杂、状态密集的模块——例如具有实时状态转换的交互式游戏，或包含定制化验证逻辑（如音乐会座位选择）的复杂工作流——通常很难用纯声明式组件来构建。嵌入 MCP 应用解决了这一问题，赋予开发者在最需要的地方创作自由。
• 安全状态对齐：宿主机应用通过一个受调控的、基于事件的循环，与 MCP 应用的内部状态保持同步。通过利用 A2UI 渲染引擎作为中介，该架构在保持主环境上下文与第三方代码分离的同时，确保了状态一致性。

实际演示

下面是一个演示应用程序，展示了将 MCP 应用作为 A2UI 组件来使用。服务端智能体返回一个 A2UI 载荷，其中某个组件是 MCP 应用组件，其输入参数包含一个基于网页的乒乓游戏的完整代码。该 A2UI 载荷中还包含 2 个记分牌，它们不属于 MCP 应用。

当用户开始与 CPU 对战乒乓游戏时，球拍控制和球的位置状态由嵌入的 MCP 应用中的代码来控制。然而，每当出现得分，该事件会被中继给智能体，原生 A2UI 组件会使用更新后的得分重新水合，从而实现 A2UI 界面中所有组件（原生 A2UI 和 MCP 应用）之间的状态同步。

底层原理：如何工作

为了实现这种混合方式，开发者定义了一个自定义 A2UI 组件，该组件充当安全的 iframe 包装器（称为 MCP 应用组件）。这个通用包装器可以容纳任何标准的 MCP 应用，并提供一个桥接通道，供应用与外部世界通信。

每当智能体请求时，MCP 服务器将应用的 HTML 和 JavaScript 资源传输给智能体。智能体随后将应用代码嵌入到结构化的 A2UI JSON 中，并与指定的组件参数集成。整合后的 JSON 被发送到宿主，MCP 应用在上述 iframe 包装器内与其他 A2UI 原生组件一起渲染。

A2UI 渲染引擎通过一个安全的、事件驱动的周期来维护原生组件和嵌入的 MCP 应用之间的状态，我们称之为状态同步。这种方式不依赖实时的 DOM 抓取或状态轮询，而是遵循一个显式的拦截循环：

1. 拦截与转换：当 MCP 应用内部发生关键状态转变时（例如乒乓游戏中得分），应用会触发一个标准的 MCP 工具调用。包裹的 A2UI 组件层在本地拦截该请求，将 JSON 参数映射为结构化的 A2UI 动作上下文，并立即返回确认，从而解除应用本地 UI 循环的阻塞。
2. 请求路由：宿主应用将此转换后的上下文封装为 A2UI Action，并将其路由至后端 AI 智能体。该智能体作为总体协调者，仅追踪宏观"关键状态"（如游戏得分或预约确认），而不跟踪微观状态（如球拍/球的坐标或临时表单输入）。
3. 水合：智能体评估完整体表面状态后，返回一个格式化的 DataModel Update JSON。A2UI 引擎直接更新原生组件（如记分牌），并通过 App Bridge 推送此更新后的资源，以重新水合内部 MCP App 的内部状态。

探索代码

要查看此架构的实际运行效果，请查阅我们的 MCP Apps in A2UI 快速入门指南，运行一个实时客户端。该交互式演示展示了一个与 MCP Server 集成的 AI 智能体，该 Server 可服务于计算器 App 和乒乓球游戏，这些应用可在通用 MCP App 封装组件的 Angular 实现中呈现。

模式 3：在 MCP App 内部运行 A2UI

此模式作为强大的现代化桥梁，允许开发者将动态的、由智能体驱动的 UI 注入到遗留应用或非 A2UI 环境中，而无需进行复杂的架构重构。

在此模式中，MCP App 包包含自己的 A2UI 渲染器。为获取动态的 A2UI 界面，MCP App 向服务器桥接一次工具调用以检索 A2UI 载荷，利用了此前讨论的基于 MCP 的 A2UI 机制。一旦接收到 A2UI JSON 载荷，MCP App 在其自身的 iframe 边界内完全解析并渲染它们。通过将生成式 UI 的复杂性吸收到自包含渲染器中，此模式允许开发者在几乎不进行架构重构的情况下，将动态的 AI 驱动交互引入现有系统。

架构优势

• 为非 A2UI 宿主提供生成式 UI：这使得 MCP App 能够提供智能体驱动的 A2UI 能力，即使宿主环境本身不原生支持 A2UI。
• 旧系统的升级：旧版应用只需支持一个基本的 MCP App iframe 容器即可。MCP App 承担了所有生成式 UI 的复杂性，让旧系统以极少的工程工作量就能解锁动态 AI 交互能力。
• 自包含的交互循环：由于 A2UI 渲染器完全位于 iframed MCP App 的边界内，局部状态转换（例如接受/拒绝文档修订）可以在应用内安全且直接地进行处理。只有经过管理的、预定义的上下文会通过 App Bridge 回传给宿主。

实际操作演示

下面是一个演示应用，展示了 A2UI 嵌入的 MCP App。宿主应用加载了一个 MCP App，该 App 从 MCP 服务器获取了一个在线文本编辑器。这个 MCP App 与 A2UI 库打包在一起，该库提供了将 A2UI JSON 负载渲染为 UI 的能力。通过结合模式 1 中讨论的 A2UI-over-MCP 技术，这个 MCP App 可以与 MCP 服务器有效通信，从而通过 A2UI 协议支持生成式 UI 功能。

在这个演示中，用户通过高亮选中一段文本来启动 AI 辅助的文本编辑。当用户高亮文本时，后端服务器将这段文本作为参数，设计出上下文相关的编辑参数。这些控件通过 A2UI 提供，MCP App 在收到负载后将其渲染出来。用户随后可以调整这些参数，指示 AI 希望如何编辑选中的部分。当用户点击“生成修订”时，AI 智能体将考虑这些参数，并为用户提供编辑建议。

原理：它是如何工作的

与其他模式相比，这种架构模式消除了宿主环境对原生 A2UI 支持的需求。通过将 A2UI 渲染引擎直接打包到 MCP App 包中，开发者可以将复杂性转嫁给嵌入的应用本身。

通过利用 App Bridge，嵌入式 MCP App 使用模式 1 中的 A2UI-over-MCP 机制与后端 AI 智能体通信。任何从 MCP Server 收到的响应，若包含 MIME 类型 `application/a2ui+json`，都会被视为 A2UI 负载，并被委托给 A2UI 库进行渲染。

为了实现本质上是生成式的功能，此演示应用在 MCP Server 后端运行了一个 AI 智能体。这使得 MCP Tool Call 能够利用大语言模型根据提供的参数生成与上下文相关的控制参数和文本修订内容。

以下交互生命周期控制着这个自包含循环：

1. 上下文触发：用户与主界面交互，例如在文档编辑器中高亮显示特定段落。
2. 事件转发：App Bridge 通过 postMessage 将此事件传输到宿主端，宿主端随后将上下文路由到后端 AI 智能体。
3. 生成式负载返回：智能体评估需求，并通过 MCP Server 返回定制的 A2UI JSON 负载，其中可能包含动态滑块或专用编辑控件。
4. 内部渲染：在识别出 `application/a2ui+json` MIME 类型后，应用的内部渲染器会在指定面板中动态挂载界面。
5. 受控通信：高级用户操作通过桥接器转发到后端进行处理，而局部状态转换（例如接受或拒绝修订）则直接在应用沙箱内管理，以保持安全隔离。

<html>
<body>

  <div>
    <h3>MCP App (Editor Panel)</h3>
    <p>This text is native to the sandboxed third-party app.</p>
    
    <!-- A2UI Surface custom element provided by the A2UI SDK -->
    <a2ui-surface surfaceId="recipe-card"></a2ui-surface>
  </div>

  <script>
    // Note: The pseudocode below assumes AppBridge from @modelcontextprotocol/ext-apps
    // and a2uiProcessor from the A2UI SDK are preloaded or inlined.
    const bridge = new AppBridge({ name: 'editor-panel', version: '1.0.0' });

    // Helper to extract and process dynamic A2UI responses from tool results
    function processA2UIResponse(result) {
      const a2uiResource = result?.content?.find(
        c => c.type === 'resource' && c.resource?.mimeType === 'application/a2ui+json'
      );
      if (a2uiResource?.resource?.text) {
        const payload = JSON.parse(a2uiResource.resource.text);
        window.a2uiProcessor.processMessages(payload);
      }
    }

    // 1. Initialize AppBridge and fetch initial controls
    async function initApp() {
      await bridge.connect();
      
      // Call server tool to load initial layout controls
      const result = await bridge.callServerTool({ name: 'fetch_controls', arguments: {} });
      processA2UIResponse(result);
    }

    // 2. Handle interactive User Actions routed by the A2UI SDK
    window.a2uiProcessor.events.subscribe(async (event) => {
      if (!event.message.userAction) return;
      const action = event.message.userAction;
      
      // Route the user action directly via the bridge to the MCP Server tool
      const result = await bridge.callServerTool({
        name: action.name,
        arguments: action.context
      });
      
      // Feed any updated server UI states back to the A2UI processor
      processA2UIResponse(result);
    });

    // Initialize the app on startup
    initApp();
  </script>
</body>
</html>

探索代码

要了解这一架构的具体运行情况，请查阅我们的《MCP App 中的 A2UI 快速入门指南》，运行一个客户端实例。该交互式演示包含了自带 A2UI 渲染引擎的 MCP App，以支持用户的生成式文本编辑体验。

结论

将 A2UI 与 MCP Apps 相结合，有助于让你的智能体用户界面在保持安全、强大且原生质感的同时，不失创意表达力。这种统一方法使你可以：在通过工具渲染 UI 时绕过 iframe（基于 MCP 的 A2UI），在声明式视图中展示丰富的自定义画布（A2UI 中的 MCP Apps），以及轻松地将动态 UI 嵌入现有网页应用（MCP Apps 中的 A2UI）。

选择正确的架构

A2UI 是一种灵活的消息格式，可以从任何后端传输到任何前端。这种灵活性意味着你有很多使用它的方式可以选择。

为了帮助你理清这些选项，请使用下面的决策树来找到最适合你项目特定约束和需求的架构：

准备好在你自己的技术栈中接入 A2UI 和 MCP Apps 了吗？

• 查阅 A2UI.org 上的 A2UI GenUI 文档。
• Read the guides
  • 基于 MCP 的 A2UI
  • A2UI 中的 MCP Apps
  • MCP Apps 中的 A2UI
• 探索 Model Context Protocol 文档以设置你的服务器，并阅读 MCP Apps 概述以了解更多关于自定义应用嵌入的信息。
• 访问 A2UI GitHub 仓库，查看上述所有示例集成。

• 网络
• AI
• 教程
• 最佳实践
• 解决方案
• 学习