用 A2UI 构建智能体用户界面

大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。

 
  
    
    
      微信 
     ezpoda免费咨询：AI编程 | AI模型微调| AI私有化部署 
     
 AI模型价格对比 | AI工具导航 | ONNX模型库 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo 
 
 
 




    
 在 2026 年，AI 智能体已经变得极其聪明，但它们往往被限制在简单的聊天机器人界面中。我们拥有能够推理、规划和编码的引擎，但强迫它们通过文本和基础 markdown 传达结果。
为了释放智能体的全部潜力，我们需要一种更好的语言让它们表达自己。我们需要能够投射丰富、动态和交互式用户界面的智能体，以适应用户的意图。
这就是 A2UI（Agent-to-User Interface） 的承诺：一种允许智能体原生地"说"UI 的协议。
在我上一篇文章中，我探索了 AI UI 解决方案的领域，并解释了为什么 A2UI 脱颖而出。现在，我想把它付诸实践。我构建了 Featest，一个功能请求应用，设计为"AI 优先"。以下是它的构建故事、我使用的协议的优势，以及涌现的架构模式。
这个项目的起源是我产品经理的一个简单请求："我们需要一种让用户对功能投票的方式。"
我本可以构建一个标准的 CRUD 应用。但我把这视为一个机会。功能请求板是动态的。用户有模糊的意图："我想要类似暗黑模式但针对音频的东西。" 他们想要合并重复项。他们想要看到趋势，管理员想要自动标记请求。
这是考虑 AI 优先体验的完美场景。我不想要静态表单；我想要一个用户可以与之对话的智能体，增强交互，并在需要时使用正确的 UI 工具。
GitHub 仓库：Featest 
  
    
     
      
      
        使用 AI 建议新功能 
       
    
在深入代码之前，理解这个架构的两大支柱至关重要。
A2UI 是一种声明式协议。智能体不是编写代码（这有风险且容易出错），而是流式传输 UI 的结构化 JSON 描述。
以下是在线路上看起来的样子。智能体发送 SurfaceUpdate 事件来渲染组件，比如一个带按钮的卡片：
{ 
 “surfaceUpdate”: {
 "surfaceId": "main-surface", "components": [ { "id": "welcome-card", "component": { "Card": { "child": "welcome-text" } } }, { "id": "welcome-text", "component": { "Text": { "text": { "literalString": "Welcome to Featest" }, "usageHint": "h1" } } } ] 
 } }

A2A 是传输协议。它标准化了智能体之间以及智能体与客户端通过 HTTP 通信的方式。它处理握手、任务生命周期和消息传递。

在 Featest 中，客户端将用户的意图包装在 A2A 消息中：

POST /api/agents/feature_request_agent/tasks Content-Type: application/json { “task_id”: “12345”, “input”: {
 "text": "I want to vote for dark mode" 
 } }

它们一起创造了一种通用语言。A2A 承载信封，A2UI 确保里面的信件包含丰富的交互内容，而不仅仅是文本。

我将系统设计为模块化的，有效地使用了 Google Agent Development Kit (ADK) 和 A2A 协议。

流程是双向的，依赖于强大的开源包：

用户与 Lit 客户端交互，后者使用官方的 @a2ui/lit 渲染器。它充当状态机，处理 SurfaceUpdate 事件以高效地修补 DOM。
客户端通过 A2A 向后端发送意图。A2UIClient 将用户的输入（文本或事件）包装在标准的 JSON-RPC 信封中。
后端智能体处理逻辑并流式回传 A2UI JSON 指令。
客户端动态渲染 UI 组件。

这个系统的强大之处来自组件 Schema。Featest 支持在 schemas.py 中定义的丰富原生组件集，确保智能体拥有高级构建块而不是原始 HTML：

布局：Row、Column、List、Card、Tabs、Divider、Modal。
输入：Button、CheckBox、TextField、DateTimeInput、MultipleChoice、Slider。
媒体：Text、Image、Icon、Video、AudioPlayer。

在构建 Featest 时，我做出的最重要的发现是一个架构层面的发现。

当你开始构建复杂的智能体应用时，你很快就会意识到一个智能体做所有事情（推理、数据库访问、UI 格式化）是一团糟。它难以测试，难以控制。

我采用了我称之为 Agent-View-Controller（AVC）模式的方法——这是智能体时代的 Model-View-Controller（MVC）的演进。

这个智能体处理业务逻辑。它不关心像素。它输入用户请求，决定使用哪个工具（例如 vote_feature、add_comment），并输出结构化数据。

# agent/agent.py controller_agent = agents.Agent( name="controller_agent", model=configs.AGENT_MODEL, description="Executes application logic.", instruction=prompts.CONTROLLER_INSTRUCTION, tools=[ tools.list_features, tools.add_feature, tools.upvote_feature, tools.add_comment, tools.get_feature, tools.update_feature, tools.delete_feature, ], 
 )

这个智能体是设计师。它从控制器获取数据并将其转换为 A2UI JSON。它关心布局、排版和层次结构。

view_agent = agents.Agent( name="view_agent", model=configs.AGENT_MODEL, description="Formats data into A2UI schema.", instruction=prompts.VIEW_INSTRUCTION, output_schema=schemas.A2UI, 
 )

我使用 ADK 的 SequentialAgent 将它们链接在一起。这种简单的组合给了我极大的灵活性。我可以替换视图智能体来改变应用的整个外观和感觉，而无需触碰一行业务逻辑。

root_agent = agents.SequentialAgent( name="feature_request_agent", description="Handles feature requests from users.", sub_agents=[controller_agent, view_agent], 
 )

使用 A2UI 揭示了相比传统聊天机器人方法的几个优势。

我们习惯了智能体说 Markdown。Markdown 在内容方面非常出色：段落、列表和代码块。但当你需要交互时，它就力不从心了。

如果智能体需要询问一组复杂的偏好设置，Markdown 迫使它一次问一个问题或解析一堆混乱的自然语言。A2UI 允许智能体投射一个带验证的表单、精确值的滑块和日期选择器。它将智能体从”写作者”提升为”界面设计师”，将正确的交互模式匹配到用户的意图。

这是企业的杀手级功能。因为 A2UI 是数据，不是代码，客户端不会发生 eval()。智能体从安全预构建组件的目录中选择。你无法通过 A2UI 注入恶意脚本，使其在”生成代码”是安全噩梦的生产环境中是安全的。

A2UI 设计为可流式传输。随着 LLM 生成 JSON token，UI 在屏幕上自行构建。

首先，容器出现。
然后，标题出现。
然后，列表项一个接一个出现。

这使应用感觉极其响应灵敏，通过可见的进度来掩盖一些延迟。

因为 UI 只是 JSON，完全相同的智能体响应可以在 Web 上（通过 Lit）、移动端（通过 Flutter）或 iOS 上（通过 Swift）原生渲染。你构建一次智能体智能，它就能在任何地方原生投射。

使用 A2UI，智能体负责结构（意图），但客户端完全控制样式。

智能体说”我需要一个主要按钮。”它不会说”我需要一个蓝色、4px 圆角的按钮。”这意味着你的应用保持完美的品牌一致性。相同的智能体响应在 Android 上可以看起来像一个时尚的消费应用，在 Web 上可以像密集的仪表盘，只需更改客户端主题。

A2UI 是一个新协议。从零开始构建自定义应用目前需要大量样板代码。目前最好的方法是使用 Flutter 的 GenUI SDK 等包，或等待 ADK 或 Gemini Enterprise 的更高级集成。

另一个主要挑战是延迟。生成 UI token 需要时间和金钱。虽然流式传输和使用”快速规划器”（如我在 Featest 中所做的）可以缓解这个问题，但纯智能体体验在核心、重复性任务上永远不会击败手工优化的原生应用。动态 UI 的”智能性”必须超过延迟成本——如果没有，就用静态按钮。

我还发现并非每个用例都受益于动态 UI。对于 Featest 中的核心投票交互，静态、可预测的 UI 更简单、更快。A2UI 大放异彩的地方是增强体验，帮助用户合理化功能、标记重复项或通过对话探索趋势。在这个项目中，它是基准 UI 的强大补充，而不一定是替代品。

A2UI 是一个出色的协议，但它不是银弹。

在我的案例中，我最初认为纯”AI 优先”应用将是理想的体验。然而，我了解到对于基本的、重复性的任务，与传统界面相比它简直太慢了。即时生成 UI 的延迟并不总是值得的。

这个项目的理想方法是混合模型：将静态、高度优化的 UI 用于核心工作流，与动态、智能体组件用于复杂的、意图驱动的任务混合使用。由程序员为每个特定用例找到**权衡。

然而，对于以聊天机器人为中心的应用，这个解决方案可能非常有价值。它使得能够精确在需要时创建更丰富的 UI，让体验超越简单的文本和适配器。

有一点是确定的：智能体功能会越来越多，A2UI 将成为智能体能力和用户需求之间的绝佳桥梁。

原文链接: Building with A2UI: Extending the Expressiveness of AI Agent Interfaces

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

用 A2UI 构建智能体用户界面

相关推荐