AI智能体UI的圣杯

在我之前的文章中，我认为 AI 智能体的真正瓶颈是用户界面（UI）。我们等于是在把火箭发动机钉在自行车上——强迫先进的智能体通过基础的 markdown 聊天机器人进行交流。

从那以后，我一直在寻找解决方案。我不只想要理论上的答案；我想亲手构建它。我探索了从"AI 编排开发"到 Python 封装库，再到新的 AI 协议的一切，寻找一种可扩展的方式来为智能体提供原生、丰富和动态的界面。

我投入时间构建了具体的实现来验证我的假设。以下是我的发现、失败的经历，以及为什么我相信 A2UI 就是我们一直在等待的解决方案。

1、探索之旅："差一点"方案的墓地

我的目标很简单：在不花数周时间写样板代码的情况下，为智能体应用构建自定义前端。 我尝试了多种方法，大多数都碰了壁。

1.1 "重型"方案：Angular 和 Flutter

我的第一直觉是构建一个真正的应用。我尝试了 Angular 和 Flutter。这些是企业应用开发的标准，提供强大的生态系统和像素级精确控制。

结果： 能用，但代价是什么？在 2026 年，搭建一个完整的前端项目仍然很痛苦。你需要配置构建工具、设置代码检查工具、管理复杂的状态存储（Redux、Bloc），并与后端同步数据模型。这种开销对于像银行仪表盘这样静态的、长期的产品是可以接受的，但对于一个动态的智能体？太过了。

智能体需要能够传输它们的 UI 并即时适应。硬编码一个重型客户端违背了自主智能体的初衷。如果每个新的智能体能力都需要一个前端开发的冲刺周期，那这个智能体就不是真正自主的。它只是一个带有非常昂贵聊天界面的后端 API。

1.2 "AI 编排开发"（AI 生成 UI）

我尝试了我称之为"AI 编排开发"的方法：一种更有条理的方式，AI 在生成应用代码中居于核心地位，在 2026 年初由 GitHub Spec Kit、Gemini Conductor 或 Antigravity 等工具推广。这与"氛围编码"（在不理解输出的情况下直觉性地使用 AI）不同。AI 编排开发旨在建立一个系统化的流程，在开发者的指导下由 AI 负责实现。

结论： 虽然长期来看有前景，但它仍然会生成大量代码。这些代码需要维护、测试和调试。我对维护 AI 生成的代码库或让 AI 成为生产系统的唯一责任方都没有信心。

我们已经在应用维护上花费的时间比构建更多。AI 编排开发有加速这种积累的风险。我们需要减少生成的特定代码量，而不是增加它。

1.3 HTMX：后端驱动的 UI

我回到了我的老本行（PHP/AJAX），尝试了 HTMX。这是一种高效的方法，通过从服务器流式传输 HTML 片段，将逻辑集中在一个地方。

问题： HTMX 将智能体与特定的视觉实现耦合得太紧。如果你想在移动应用、Web 仪表盘和桌面客户端上渲染相同的智能体响应，你无法复用 HTML 流——你被锁定在一个表现层中。

更根本的是，HTML 对于智能体推理来说太底层了。智能体不应该操心 CSS 类、DOM 嵌套或无障碍属性。它应该专注于意图和逻辑，而不是像素。发送声明式数据更高效、更通用，可以被不同类型的客户端消费。

1.4 Python 封装库（Streamlit、Gradio、Chainlit）

这些用于原型设计很好。Streamlit、Gradio 和 Chainlit 等工具提供少量的代码表面积和即时部署。

缺陷： "胶水代码"地狱。你不可避免地会碰到库不支持你需要的特定交互或组件的墙。也许你需要自定义拖放界面或特定的数据可视化。你失去了对样式的控制，最终写出 hack 式的变通方案（自定义 HTML 注入、iframe 桥接）来连接智能体状态和 UI 组件。

它们也不是真正动态的——它们是填充了数据的僵硬模板，而不是根据智能体需求生成的流畅界面。你仍然在构建表单；只是用 Python 而不是 React 来做。

1.5 聊天扩展（Slack/Teams/Workspace）

构建到现有工作流中看起来很聪明。既然可以部署一个机器人到 Slack 或 Google Chat，为什么要构建新的 UI？

限制： 无法扩展。你最终要为 Slack 构建一个适配器，为 Teams 构建另一个，为 Google Chat 又构建一个。每个平台都有自己的专有 UI 套件（Block Kit、Adaptive Cards），限制各不相同。

你希望一次构建智能体并让它将 UI 投射到任何地方，而不是为每个宿主应用重写表现层。这种碎片化增加了维护负担，并阻止你跨平台创建一致的用户体验。

2、顿悟：关注点分离

在这个过程中我意识到了一个基本道理：一切都是一次性的。

我们不应该对 UI 代码过于珍惜。我们应该专注于声明式的一面。就像人类使用 HTML 不是因为我们喜欢画像素，而是因为我们想说"这是一个链接"或"这是一张图片"，智能体需要一种高级语言来描述需要展示什么，而不是如何绘制它。

智能体应该负责数据和逻辑。客户端应该负责样式和渲染。

这种分离使智能体可以"大脑发达"而"UI 轻量"，将复杂的渲染逻辑推迟给客户端，而这正是客户端最擅长的。

3、解决方案：A2UI（Agent-to-User Interface）

A2UI 登场了。

我使用这个协议构建了一个演示应用，对其优雅程度真心感到印象深刻。A2UI 是一种基于 JSONL 的声明式协议，在 AI 和用户界面之间创建标准契约。

3.1 工作原理

与像传统 LLM 那样流式传输 markdown token 不同，智能体流式传输代表 UI 组件的结构化 JSON 对象。

客户端可以使用 Lit 渲染器、Angular 渲染器或 Flutter 渲染器来渐进式渲染原生组件。

3.2 为什么它胜出

• Google 内的生产就绪： A2UI 不是空中楼阁——它已经集成到 Google 产品中，如 Opal、Gemini Enterprise 和 Flutter GenUI SDK。
• 传输无关： 它可以通过 HTTP（通过 A2A 协议）、WebSocket 或信鸽工作。协议不在乎 JSON 如何到达。
• 渐进式渲染： UI 随着智能体"思考"而出现。组件逐一流入，使界面感觉活跃和响应灵敏，就像文本流式传输一样，只是变成了丰富的 UI 元素。
• 框架无关： 客户端实现（React、Angular、Lit）决定"Card"长什么样。智能体只说"我需要一个 Card"。这意味着你可以有一个"Material Design"客户端和一个"iOS Cupertino"客户端，原生渲染完全相同的智能体响应。
• 安全： 没有任意 JavaScript 执行。只是声明式数据，降低注入风险。这对于安全审查会阻止"动态代码生成"的企业采用至关重要。
• LLM 友好： 扁平的、流式 JSON 结构，专为轻松生成而设计。LLM 可以增量构建 UI，而不需要一次生成完美的 JSON。

注意： A2UI 目前处于 v0.8，仍在积极开发中。协议有一些粗糙的边缘，对于生产使用，最好的方法是等待在 Gemini Enterprise 或 Agent Development Kit (ADK) 等工具中的原生集成。

4、A2UI vs AG-UI：两种哲学

我也研究了 AG-UI，这个领域中另一个新兴的标准。

• AG-UI 旨在深度融合前端和后端，从头开始创建"AI 优先"的应用，重点关注实时事件循环。它很强大，但需要你重新思考整个应用架构中关于状态同步和事件处理的部分。
• A2UI 专注于扩展基于聊天的交互能力使其更丰富。它是一座桥梁，让智能体使用标准组件"说 UI"。它感觉更像是聊天界面向指挥中心的进化，而不是应用栈的完全替代。

我相信 A2UI 是大多数智能体实现的可扩展路径。它尊重关注点分离，并通过 A2A（Agent-to-Agent）等协议与现有系统无缝集成。

5、结束语

我们正在走向前端技术的分裂，而且速度比我们想象的要快：

• 静态应用（存量）： 仪表盘、零售网站和专业工具。这些仍将使用高效框架构建，以实现速度、精确控制和已知路径的特定用户旅程。它们代表了现有应用的大多数。
• 动态智能体界面（增量）： 由 A2UI 等新协议驱动。这些将用更强大的东西取代"聊天机器人"——交互式的、基于组件的、即时生成的。这是新增长发生的地方。这些界面将在用户意图模糊或高度多变时出现，比如在智能体商务中。

我确信 2026 年是我们停止为智能体构建 UI，开始让智能体向我们投射 UI 的一年。我们不应该在 UI 上花太多时间。让它由智能体个性化，这样我们就可以专注于真正重要的事情：集成和指令。

原文链接: Finding the Holy Grail of AI Agent UIs: From AI-Orchestrated Development to A2UI

汇智网翻译整理，转载请标明出处