4.7 智能体交互体验：人机交互接口

传统对话式界面（Chatbot UI）面向简单任务，随着智能体能力的提升，用户和智能体的交互需求日益复杂。当智能体具备了工具使用、长期记忆和多步规划能力后，需要一种全新的交互范式——智能体交互体验。本节将探讨如何设计适应智能体的人机交互接口，从生成式界面到伴随式交互，重新定义人与 AI 的协作方式。

4.7.1 从 Chatbot 到 Agentic UI

用户界面的演进总是伴随着交互方式的变革。从简单的对话框发展到能够感知状态、支持协作的智能体界面，是 AI 能力提升的必然要求。

"Prompt as UI" 的局限性

在 LLM 早期，所有的交互都压缩在单一的聊天窗口中。这种模式对于简单的问答（QA）是有效的，但对于复杂的智能体任务存在显著缺陷：

1. 信息密度低：纯文本难以展示结构化数据（如数据报表、架构图）。

2. 交互性差：用户无法直接修改智能体的中间产物，只能通过新的提示词（Prompt）进行修正。

3. 状态不可见：用户不知道智能体在规划什么，导致“等待焦虑”。

智能体交互体验的核心特征

智能体交互体验是一种 多模态、动态、状态感知 的界面范式：

• 富交互（Rich Interaction）：不仅是文本，还包括动态生成的 GUI 组件（按钮、表单、图表）。

• 协作式（Collaborative）：用户可以随时介入智能体的工作流，进行修改或确认。

• 透明化（Transparent）：通过 UI 可视化智能体的思维链（Chain of Thought）和工具调用状态。

4.7.2 生成式界面

生成式界面指的是智能体根据当前的意图和数据，动态生成 最适合的 UI 组件呈现给用户。

动态组件生成

智能体不仅生成文本，还能生成 React/Vue 组件。例如：

• 天气查询：智能体不只是说“今天是晴天”，而是渲染一个带有温度曲线和天气图标的卡片。

• 数据分析：当用户问“分析上季度销售额”时，智能体直接渲染一个可交互的 ECharts 柱状图。

实现原理其核心思想是将工具调用与React Server Components (RSC) 结合。

1. 定义工具与 UI：在服务端定义工具（如 showWeather），并在其 generate 方法中直接返回一个 React 组件（如 <WeatherCard />），而不仅是 JSON 数据。

2. 智能路由：streamUI 函数将用户的 Prompt 发送给大模型。

3. 流式渲染：如果模型决定调用 showWeather，SDK 会在服务端执行该工具，获取数据，渲染组件，并将渲染结果流式传输（Stream）给前端。前端就像接收文本流一样接收这个 UI 组件流。

下面是一个例子。

// 智能体决定渲染什么 UI（伪代码示例）
async function renderUI(input: string) {
  const result = await streamUI({
    model: '<MODEL>',
    system: 'You are a helpful assistant.',
    prompt: input,
    tools: {
      showWeather: {
        description: 'Show weather forecast',
        parameters: z.object({ location: z.string() }),
        generate: async ({ location }) => {
          const data = await getWeather(location);
          // 返回一个 React 组件作为结果
          return <WeatherCard data={data} />; 
        },
      },
    },
  });
  return result;
}

上下文自适应渲染

UI 应该根据上下文自动调整形态：

• 移动端：生成简洁的卡片视图。

• 桌面端：生成带有详细数据表格的仪表盘。

• 新手模式：通过 GUI 引导用户操作。

• 专家模式：提供更密集的命令行或代码编辑器界面。

4.7.3 延迟掩盖与流式反馈

智能体的思考和工具调用往往需要较长时间（数秒甚至数分钟）。为了保持良好的用户体验，必须妥善处理延迟。

思考状态可视化

不要让 UI 假死。通过流式输出来展示智能体的“心跳”：

1. 规划阶段：显示 "Planning tasks..."，并列出待办事项清单。

2. 执行阶段：显示 "Searching web for...", "Analyzing data..."。

3. 结果阶段：逐步渲染最终内容。

最佳实践：

• Skeleton Screens (骨架屏)：预测即将生成的内容结构，先展示骨架。

• Optimistic UI (乐观更新)：假设操作成功，立即在 UI 上反映变化，后台异步确认。如果失败则回滚并提示。

流式组件

利用 React Server Components (RSC) 等技术，实现组件级的流式传输。

• 文本内容逐字显示。

• 图表数据点逐个加载。

• 图片先显示模糊占位图，再逐步清晰。

4.7.4 伴随式交互

智能体不应总是占据屏幕中心，更多时候它应该作为一个 助手（Side-kick） 伴随用户工作。

隐式触发

智能体通过观察用户的行为主动提供帮助，而不需要用户显式输入 Prompt。

• 代码补全：当你输入 def calculate_ 时，幽灵文本（Ghost text）自动建议函数体。

• 上下文感知建议：当你在写文档提到“下周会议”时，侧边栏自动浮现日历组件建议安排日程。

画布交互

以“画布 + 对话”的交互模式为代表。

• Content-First：左侧是聊天，右侧是文档/代码编辑器。

• 指向性编辑：用户并在右侧选中一段代码，在左侧说“优化这段逻辑”，智能体直接修改右侧内容。

• Diff视图：清晰展示智能体的修改建议，用户一键 Accept/Reject。

4.7.5 人工干预设计

Human-in-the-Loop (HITL)机制允许人类在关键节点介入智能体的决策流程。关于 HITL 的协作模式与架构将在 5.4 人机协作 详细探讨，本节重点关注其交互界面（UI）的设计。

• 审批卡片：设计清晰的 批准/拒绝按钮，并用颜色编码风险等级（除了红/绿，还可以有黄色警告）。

• 修改建议：允许用户在批准前对参数进行微调（例如：“批准转账，但金额改为 500”）。

• 进度条与撤回：给予用户“后悔药”，在执行初期允许取消（Cancel）。

---

下一节: 本章小结