# 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 可视化计划摘要、当前步骤、证据引用和工具调用状态；是否展示更细粒度推理取决于产品策略，不应把暴露 raw 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 组件流。

下面是一个例子。

```typescript
// 智能体决定渲染什么 UI（伪代码示例）
import { z } from 'zod';

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。

### 人工干预设计

在关键节点允许人类介入是至关重要的。**Human-in-the-Loop (HITL)** 机制让用户对敏感决策进行确认。设计清晰的批准/拒绝按钮，并用颜色编码风险等级；允许用户在批准前对参数进行微调；给予用户“后悔药”，在执行初期允许取消（Cancel）。关于 HITL 的协作模式与架构详见 [5.4 人机协作](/agentic_ai_guide/di-er-bu-fen-qun-ti-zhi-neng-yu-jin-hua/05_collaboration/5.4_hitl.md)。

## 4.7.5 从 UX 到 AX：智能体体验设计（前瞻视角）

前几节聚焦于“人看到的界面”，但从趋势上看，部分软件产品的“第一使用者”正在逐步从人类扩展到其他智能体或自动化流程。这催生了一个更偏前瞻性的设计话题——**智能体体验（Agent Experience, AX）**。

### 角色转变：从操作者到委托者

当智能体承担更多端到端工作流后，人类在部分软件系统中的角色会从直接操作 GUI 的“操作者”（Operator），逐步转向设定高层目标与监督结果的“委托者”（Delegator）。这并不意味着传统 UX 失效，而是意味着很多系统需要同时面向“人类用户 + 外部智能体”双重受众。

### API 是新的“用户界面”

在 AX 视角下，API、结构化数据格式和模型上下文协议会越来越像“机器的界面”。更稳妥的说法不是“API 取代 UI”，而是：未来的软件平台需要同时优化 **人类可用性** 与 **机器可读性**。AX 设计的核心目标，是提升平台的“机器可读性”与“意图可执行性”——将复杂业务能力映射为智能体可稳定调用的工具与协议（参见 [4.3 MCP](/agentic_ai_guide/di-yi-bu-fen-dan-ti-zhi-neng-jia-gou/04_tools/4.3_mcp.md)）。

### 商业指标的迁移：从 DAU 到 DAA

传统互联网企业依赖 DAU 等人类行为指标来评估产品健康度。若智能体代劳的比例持续上升，一些团队可能会引入类似 DAA（Daily Active Agents）这类补充指标，衡量“程序化调用产生的业务价值”。不过这仍属于新兴实践，更适合作为补充指标，而不是已经定型的行业金标准。

***

**下一节**: [本章小结](/agentic_ai_guide/di-yi-bu-fen-dan-ti-zhi-neng-jia-gou/04_tools/summary.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://yeasy.gitbook.io/agentic_ai_guide/di-yi-bu-fen-dan-ti-zhi-neng-jia-gou/04_tools/4.7_agentic_ux.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.