在生产级的 Agent 系统中，完成任务的那套引擎和 Harness 固然重要，但大部分系统中，设计良好的前端 UI 应用仍然是不可或缺的重要一环 — 特别是对很多直接面向用户的 AI Native 应用，它关系到最直接的用户体验。
围绕 Agent UI 的构建，之前我们曾经有过一些零散的介绍。
本文将聚焦到 AG-UI、A2UI、MCP Apps 这三种常见标准及其开发，彻底带你看懂各自的定位、能力与区别（上），并探讨它们之间的协同使用（下）。
01 Agent 时代的 UI 有什么不一样
首先我们来思考下，Agent 系统的 UI 到底有什么不一样？
【自然语言不能取代传统 UI】
在早期 Agent 出现时，很多人认为自然语言就是 Agent 的 UI。
但很可惜，自然语言并不能解决所有的交互问题 — 最简单不代表效率最高。
自然语言很适合表达需求和任务：“把我昨天的订单做退款处理”，这比在菜单与按钮之间反复跳转简单省事。
但如果要看十几个订单，列表显然更清晰；要调整订购数量，用输入框或者滑块也会更方便；而如果需要做二次确认，点个按钮要比输入“我确定”更快捷。
所以 Agent UI 往往是自然语言与传统图形化界面（如 Web UI）的“结合体”。
当 Agent 与人类需要多次做复杂信息的交互时，HTML 的视觉表达与交互效率要强于干巴巴的文字和 Markdown。
【Agent 需要更加动态的 UI】
传统应用的 UI 大多提前设计，用户按导航与路由逐步推进（比如，搜索页面->订单列表->订单详情->二次确认->操作成功）。
而 Agent 接收任务后，它的任务步骤和路径并不固定 — 先用哪个工具、缺什么信息、什么时候需要人类介入，未必能在开始前确定。
所以，Agent 系统的 UI 很多时候要随着任务更新而呈现（比如，缺少地址，就出现地址选择；涉及付款，就出现金额核对），既要跟上 Agent 的执行，又要给人留出查看、修改和决策的交互入口。
【更多的复杂性】
除了上面的问题，Agent 的交互由于其任务特征还有更多的复杂性。
Agent 的任务可能持续几分钟，甚至更久。所以，Agent 的前端 UI 很多时候除了逐步显示回复，还需要同步当前状态与进度信息：正在调用某个工具、已经处理的任务进度、生成某个产物等等。
而当 Agent 通过 MCP 接入外部系统时，一个问题是：如果这个接口需要持续交互而非简单的一次数据获取（比如查询附近餐厅并订购），那么操作的 UI 从哪里来？如果完全在客户端定制，很显然又会产生极大的耦合性。
而 AG-UI、A2UI、MCP Apps 正是为了解决这些实际的 UI 挑战而诞生。
02 AG-UI：给交互定义一套共同的表达
AG-UI 全称 Agent-User Interaction Protocol，最早由 CopilotKit（一个 Agent UI开发框架）团队发起，2025 年 5 月公开发布，2026 年 9 月发布的 1.0 已有稳定规范。
【解决什么问题】
如果用一句话介绍 AG-UI 协议：
为 AI 智能体（Agent）与用户界面（UI）之间的实时、双向、结构化通信制定的一个开放事件标准 。
想象一下，前端的 UI 应用需要和后端 Agent 持续通信和交互 — 发送请求、获得回复、了解进度等等，这其中存在大量的交互事件，AG-UI 就是用来统一这些交互的约定：协议、事件、格式等。
需要注意的是：
AG-UI 并不定义 UI 本身 — Agent 事件返回给 UI 后，怎么呈现、卡片长啥样，仍然由前端应用自行决定。
【运作原理】
前端应用提交任务请求后（通常是 HTTP Post），交给 Agent 接收；
由 AG-UI 协议适配层把 Agent 输出转为标准事件持续推送到前端（通常是 HTTP SSE）；常见的事件类型比如：任务开始、任务结束、步骤开始、步骤结束、文本回复、文本增量、状态快找、工具调用开始等等；
同样，前端的用户确认事件，也会反馈到 Agent。
【实战开发】
官方 1.0 SDK 支持 TypeScript、Python、.NET。针对不同的 Agent 框架（比如 LangChain），使用对应的适配器即可快速实现 AG-UI 标准的事件输出。
前端可以选 CopilotKit，也可以直接用 @ag-ui/client，无须更换整套 UI 框架，因为 AG-UI 并不定义 UI 组件及渲染机制。
我们用一个小案例来演示 AG-UI 的应用（后面将一直沿用这个例子）：一个客户服务 Agent，假设在处理一笔订单退款的任务，在二次确认这个环节中，希望用一个更直观的图形 UI 来展示确认信息，并获得反馈。
在这里的例子中，模拟 Agent 调用后，会出现这样的退款确认界面：
注意这里的 UI 仍然是客户端自行实现，但 UI 与后端 Agent 之间的通信则是基于 AG-UI 标准进行。
我们把 Agent 返回前端的 AG-UI 事件打印出来，就可以理解这一点：
可以看到，这里的事件中并没有 UI 元素的信息 — 它们仍然由你自己定义；
它只告诉你 Agent 当前发生了哪些事件，及其携带的必要数据。
03 A2UI：Agent 描述 UI，前端再渲染
A2UI 全称 Agent-to-User Interface，是 Google 发起、2025 年 12 月公开的声明式 UI 协议；AG-UI 的提出者 CopilotKit 与社区参与贡献。
【解决什么问题】
如果用一句话来介绍 A2UI 诞生的动机：
让后端 AI 以安全、可控、跨平台的方式，动态驱动前端交互 UI 的生成与更新。
所以，A2UI 解决的就是我们第一节所说的动态 UI 的问题。当 Agent 任务需要的 UI 并不遵循固定的交互过程与界面，A2UI 可以传递“前端需要哪些控件、怎样组织、绑定什么数据”，然后由前端用自己认可的组件绘制 UI。
Agent 决定 UI 如何显示；前端应用保留对渲染、样式和可用能力的控制。
【运作原理】
A2UI 的基本运作过程是：
后端发送 JSON 消息给前端“描述” UI — 界面区域（Surface）、组件和数据；
前端的渲染器按组件目录（Catalog）校验、映射到本地控件，并完成渲染；
用户点击产生 Action，经前端应用传回后端，再接收 UI 的更新消息；
-
为什么有组件目录（Catalog）？
这是一种安全机制：所有可渲染的 UI 组件（如 Button、Card、Text 等），都需要事先在目录中注册。Agent 只能“请求使用”这些白名单组件，而无法注入任意脚本或超出范围的元素。
-
同一份描述可以跨端复用。
前提是双方支持相同的组件版本与 Catalog，但不保证像素级的一致。
-
A2UI 是一种动态 UI 描述协议，所以其传输可以基于简单的 HTTP ；也可以基于前面的 AG-UI 或 A2A 协议来承载。
【实战开发】
继续上面的例子。我们可以用 A2UI 的方法来实现与前面 AG-UI 方法相同的效果。区别在于：
-
AG-UI 是后端只发送任务过程中的事件和数据；UI 如何展现完全由前端负责
-
A2UI 则是由前后端选定支持的组件目录，然后 Agent 直接返回 UI 描述消息
在这个例子中，我们使用了 Column、Text、Image、Button 等几个主要组件。跟踪 Agent 返回的消息可以看到结构如下（部分）：
{
"version": "v0.9",
"createSurface": {
"surfaceId": "refund",
"catalogId": "https://refund-demo.local/catalog/v1"
}
} {
"version": "v0.9",
"updateComponents": {
"surfaceId": "refund",
"components": [{
"id": "root",
"component": "Column",
"appearance": "refund-card",
"children": ["eyebrow", "heading", "status-badge", "product", "details", "amount", "labelhint", "actions", "footer"]
}, {
"id": "eyebrow",
"component": "Text",
"appearance": "eyebrow",
"text": "REFUND REVIEW / 退款确认"
}, {
"id": "heading",
"component": "Column",
"appearance": "card-heading",
"children": ["title", "subtitle"]
}, {
"id": "confirm",
"component": "Button",
"variant": "primary",
"child": "confirm-label",
"action": {
"event": {
"name": "confirm_refund",
"context": {
"taskId": "0eebb393-201d-4e59-9dde-b739341e996d"
}
}
}
}, {
"id": "cancel",
"component": "Button",
"variant": "secondary",
"child": "cancel-label",
"action": {
"event": {
"name": "cancel_refund",
"context": {
"taskId": "0eebb393-201d-4e59-9dde-b739341e996d"
}
}
}
}]
}
}
很显然，与 AG-UI 相比，大家都传递了消息，但一个是用来给前端更新 UI 的事件；一个则是直接的 UI 描述。两者区别很明显。
04 MCP Apps：让工具带着交互 UI
MCP Apps 是 MCP 的官方 UI 扩展，由 Anthropic、OpenAI 等团队共同推动，吸收了 MCP-UI 和 OpenAI Apps SDK 的实践。2025 年 11 月公布提案，2026 年 1 月正式发布。
【解决什么问题】
想象一下，基于 MCP 来连接到企业的 CRM 系统。传统的方法是构建查询数据的 Tool，前端 Agent 将工具返回的数据自定义呈现并实现交互。但问题是：
简单的 Markdown 文本与表格表现力有限，且交互能力薄弱，如数据过滤、下钻、动态面板、非文本数据等，只能通过多轮来回对话实现。
而这就是 MCP Apps 试图解决的问题：
允许 MCP Server 不仅能返回普通文本、代码、JSON等；更能同时返回一个已经设计好的 HTML 前端 UI。
【运作原理】
相比普通的 MCP Tool，MCP Apps 需要的工具会多出一个 ui:// 的资源地址标签（在工具元数据中关联）。
当前端宿主应用发现工具带有 UI 关联后，就会读取对应的 UI 资源（HTML）；然后在前端隔离加载到一个 “App” 视图中（运行在 iframe 内）；再把工具结果交给 App 进行呈现。
在需要后端 MCP Server 进行交互时，iframe 内的 App 首先通过 AppBridge 与 MCP Client 进行消息通讯（通过浏览器原生 API - postMessage）；MCP Client 再调用 MCP Server 中的工具（通过 MCP 标准协议）。
基于安全原因，iframe 内的“App”不能直接与MCP Server通信，必须通过 AppBridge 代理与“中转。
【实战开发】
MCP Apps 可以借助官方的@modelcontextprotocol/ext-apps一系列的开发 SDK 进行 MCP Server 与客户端的开发。
在服务端通过 registerAppTool，registerAppResource 注册工具与UI资源，声明“这是一个带 UI 的工具”，并实现这个工具和页面。
这里的页面最终是运行在前端的 iframe “沙盒”内，除了视觉组件与数据的渲染呈现外，最主要是的是实现动态交互能力。
比如在点击这个 MCP App 的“确认退款”按钮，此时需要调用 Server 端的工具：
...
const result = await app.callServerTool({
name: "decide_refund",
arguments: { taskId, decision: "confirm" }
});
render(result);
...
并在完成调用后，根据返回结果更新前端 UI 即可：
当然，开发 MCP Apps 更简单的方法是让 AI 编程工具代你完成。
借助 MCP 官方的几个 Skill ，可以让 AI 快速获得架构指导与最佳实践：
-
create-mcp-app：从零到一个 MCP App项目的脚手架
-
add-app-to-server：给已有的 MCP Server 增加交互式 UI
-
convert-web-app：普通 Web App 转化成 MCP App，快速与 Agent 集成
05 总结：区别与选择
尽管这三种面向 Agent UI 的标准都与 UI 相关，但各自的定位完全不同：
三种标准解决的是不同环节的问题，我们在选型时可以先看项目缺失了哪部分：
-
已有前端 UI 页面，需要接入 Agent 的回复、进度和状态，优先考虑 AG-UI，界面仍由前端设计。
-
需要按任务动态组合表单、卡片，考虑 A2UI；但前提是客户端具备匹配的组件目录与渲染器。
-
外部工具需要配套地图、编辑器等交互界面，希望随工具一起复用，考虑 MCP Apps，但宿主必须支持该扩展。
需要注意的是，三者可以独立采用，但也可以组合使用。
305
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
