Agent UI 产品化设计：不要只做一个聊天框
这篇文章解决什么问题
很多 Agent 产品第一版都是聊天框。但真实业务用户不只需要聊天，他们需要：
- 看任务状态。
- 看证据来源。
- 审批高风险动作。
- 修改结构化结果。
- 查看执行轨迹。
- 反馈答案质量。
- 重新运行失败步骤。
Agent UI 的核心不是“把模型回复展示出来”，而是把 Agent 的执行过程、证据、状态和控制点产品化。
为什么聊天框不够
聊天框适合：
- 开放问答。
- 灵感生成。
- 简单咨询。
不适合：
- 长任务。
- 工单生成。
- 多 Agent 协作。
- 高风险工具调用。
- 需要引用和证据的 RAG。
- 需要人工审批的流程。
生产级 Agent UI 应该让用户看到系统正在做什么，以及用户在哪里可以介入。
核心 UI 模块
1. 任务面板
展示：
- 任务目标。
- 当前状态。
- 已完成步骤。
- 待处理动作。
- 失败原因。
2. 证据面板
展示：
- 引用文档。
- 页码/段落。
- 置信度。
- 原文片段。
- 检索来源。
3. 工具调用面板
展示：
- 工具名称。
- 参数摘要。
- 风险等级。
- 执行结果。
- 是否需要审批。
4. 审批面板
用于：
- 确认创建工单。
- 确认发送消息。
- 确认写入数据库。
- 拒绝危险动作。
- 修改参数后再执行。
5. 反馈面板
收集：
- 有用/无用。
- 引用错误。
- 答案不完整。
- 工具调用错误。
- 人工修正内容。
反馈要进入 Eval Dataset 或失败样本库。
UI 状态设计
Agent UI 至少要支持：
| 状态 | 含义 |
|---|---|
| idle | 等待任务 |
| planning | 任务拆解 |
| retrieving | 检索证据 |
| calling_tool | 调用工具 |
| waiting_approval | 等待人工审批 |
| generating | 生成结果 |
| failed | 执行失败 |
| completed | 完成 |
不要只有 loading。
长任务交互
长任务需要：
- 进度条。
- step timeline。
- 可取消。
- 可暂停。
- 可恢复。
- 失败重试。
- 局部重跑。
用户不应该盯着一个无限转圈的按钮。
RAG UI
RAG UI 重点不是回复，而是证据：
- 答案旁显示引用。
- 引用可点击展开原文。
- 显示没有足够证据时的拒答。
- 支持用户标记引用错误。
- 支持查看召回文档。
这能显著提高用户信任。
多 Agent UI
多 Agent UI 可以展示：
- Planner 计划。
- 各 Agent 当前状态。
- Handoff 内容。
- 结果聚合。
- 冲突意见。
- Critic 审核结果。
但不要为了炫酷展示一堆角色头像。重点是任务推进和可控性。
面试表达
可以这样讲 Agent UI：
我不会把 Agent 产品只做成一个聊天框。生产级 Agent UI 应该展示任务状态、证据来源、工具调用、审批点、执行轨迹和用户反馈。比如 RAG 场景要让用户看到引用文档和原文片段；工具调用场景要展示参数摘要、风险等级和审批按钮；长任务场景要有 step timeline、失败重试和恢复。UI 的目标是让用户理解 Agent 正在做什么，并在关键风险点介入，而不是被动等待模型回复。