用 A2UI 构建智能体用户界面

在 2026 年,AI 智能体已经变得极其聪明,但它们往往被限制在简单的聊天机器人界面中。我们拥有能够推理、规划和编码的引擎,但强迫它们通过文本和基础 markdown 传达结果。

为了释放智能体的全部潜力,我们需要一种更好的语言让它们表达自己。我们需要能够投射丰富、动态和交互式用户界面的智能体,以适应用户的意图。

这就是 A2UI(Agent-to-User Interface) 的承诺:一种允许智能体原生地"说"UI 的协议。

在我上一篇文章中,我探索了 AI UI 解决方案的领域,并解释了为什么 A2UI 脱颖而出。现在,我想把它付诸实践。我构建了 Featest,一个功能请求应用,设计为"AI 优先"。以下是它的构建故事、我使用的协议的优势,以及涌现的架构模式。

1、项目:Featest

这个项目的起源是我产品经理的一个简单请求:"我们需要一种让用户对功能投票的方式。"

我本可以构建一个标准的 CRUD 应用。但我把这视为一个机会。功能请求板是动态的。用户有模糊的意图:"我想要类似暗黑模式但针对音频的东西。" 他们想要合并重复项。他们想要看到趋势,管理员想要自动标记请求。

这是考虑 AI 优先体验的完美场景。我不想要静态表单;我想要一个用户可以与之对话的智能体,增强交互,并在需要时使用正确的 UI 工具。

GitHub 仓库Featest

使用 AI 建议新功能

2、黄金搭档:A2UI 和 A2A

在深入代码之前,理解这个架构的两大支柱至关重要。

2.1 A2UI:Agent-to-User Interface(内容层)

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"
          }
        }
      }
    ]
  }
}

2.2 A2A:Agent-to-Agent 通信(传输层)

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 确保里面的信件包含丰富的交互内容,而不仅仅是文本。

3、架构

我将系统设计为模块化的,有效地使用了 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。

4、AVC 模式:Agent-View-Controller

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

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

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

4.1 控制器智能体(大脑)

这个智能体处理业务逻辑。它不关心像素。它输入用户请求,决定使用哪个工具(例如 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,

    ],
)

4.2 视图智能体(渲染器)

这个智能体是设计师。它从控制器获取数据并将其转换为 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,
)

4.3 顺序管道

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

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

5、协议的优势

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

使用 A2UI 动态渲染的表单留下评论

5.1 UI 语言

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

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

5.2 安全设计

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

5.3 渐进式渲染

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

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

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

5.4 互操作性

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

5.5 客户端样式控制

使用 A2UI,智能体负责结构(意图),但客户端完全控制样式

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

6、局限性

6.1 成熟度和样板代码

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

6.2 延迟与智能性

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

6.3 互补性质

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

7、结束语

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

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

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

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

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


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

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