前端转 AI Agent 工程师进阶指南

主题

专题 04 Agent UI / UX 与 Human-in-the-Loop ​

本专题回答一个非常关键的问题：为什么很多 Agent 产品技术上能跑，但用户用起来仍然不放心、不顺手、不愿意长期使用。

原因通常不是模型不够强，而是交互设计仍停留在“聊天框 + 回答文本”的阶段。对前端工程师来说，这正是最应该发挥价值的地方：把 Agent 从一个会说话的接口，做成一个可信、可控、可协作的产品。

1. 为什么 Agent 不能只做成聊天框 ​

聊天框是最容易做的入口，但不是最好的交互范式。 当 Agent 要执行任务、调用工具、访问知识、生成计划、请求确认时，用户真正需要的不是“它能不能说”，而是：

  • 它现在在做什么。
  • 它为什么这么做。
  • 它做到哪一步了。
  • 我能不能打断。
  • 有风险时我能不能接管。

如果这些信息都不可见，用户就会缺乏信任感。

2. 前端工程师在 Agent 产品中的独特价值 ​

很多 AI 项目初期会由模型或后端视角主导，容易把问题理解成“只要输出正确就行”。 但从产品体验看，这远远不够。

前端工程师可以补上的关键价值包括：

  • 让任务过程可见。
  • 让系统状态可解释。
  • 让高风险动作可确认。
  • 让失败场景有清晰兜底。
  • 让人与 Agent 之间形成真正的协作关系。

3. Agent UI 的核心设计目标 ​

3.1 可见性 ​

用户要知道系统正在执行哪一步。 推荐展示：

  • 当前阶段：理解问题、检索资料、调用工具、生成结果。
  • 当前使用的证据或工具。
  • 是否存在等待确认的动作。

3.2 可控性 ​

用户必须拥有基本控制权，例如：

  • 中断当前执行。
  • 修改输入约束。
  • 拒绝某个高风险动作。
  • 重试某一步而不是重跑全部流程。

3.3 可解释性 ​

特别是在企业场景中，用户往往更关心“为什么得到这个结果”。 前端可以展示：

  • 引用来源。
  • 工具执行结果摘要。
  • 关键决策依据。
  • 低置信度提示。

3.4 可恢复性 ​

系统失败是常态，不是异常。 优秀的 Agent UI 不只是展示错误，而是告诉用户下一步怎么做：

  • 补充哪些信息。
  • 是否转人工。
  • 是否保留当前进度。
  • 能否只重试失败步骤。

4. Human-in-the-Loop 为什么重要 ​

Human-in-the-Loop 不是“系统不够智能所以靠人工补”，而是一种产品设计原则： 在关键节点，让人保有最终决策权。

尤其在这些场景里必须优先考虑：

  • 会修改真实业务数据。
  • 会发送消息、邮件、通知。
  • 会触发审批、下单、删除、发布等高风险动作。
  • 输出内容涉及合规、财务、法务、客户承诺。

5. 常见的 HITL 交互模式 ​

5.1 先计划后执行 ​

系统先展示执行计划，再让用户确认。 适合自动化任务、批量操作、跨系统操作。

5.2 关键步骤确认 ​

不要求每一步都确认，而是在高风险节点弹出确认。 适合中等复杂度流程。

5.3 结果审核后发布 ​

系统完成草稿、建议或候选方案，由用户审核后最终提交。 适合内容生成、回复建议、工单结论、周报生成等场景。

5.4 人工接管 ​

当系统置信度低、工具异常或流程阻塞时，把当前状态交给人继续处理。 这要求前端能把“当前进度、已有证据、失败原因”展示清楚。

6. 一套推荐的 Agent 交互结构 ​

可以把界面拆成四个区块：

  • 对话区：用于自然语言交流。
  • 过程区：展示当前步骤、工具调用和状态变化。
  • 证据区：展示引用来源、检索片段、关键输入输出。
  • 控制区：提供暂停、确认、重试、转人工等操作。

对任务型 Agent 来说，这比只有一个聊天区域稳定得多。

7. 前端实现时应该特别设计的状态 ​

建议至少明确以下状态，而不是用一个 loading 一把梭：

  • thinking：模型在推理或等待结果。
  • retrieving：正在检索或读取知识。
  • calling_tool：正在执行外部工具。
  • waiting_user_confirmation：等待用户确认。
  • partial_success：部分步骤已成功，部分失败。
  • needs_human_takeover：系统建议人工接管。
  • completed：流程完成。
  • cancelled：用户主动中断。

状态设计越清晰，后续可观测性和问题排查就越容易。

8. 适合前端补强的 6 个体验点 ​

8.1 流式输出 ​

不要等全部完成再一次性展示。 用户希望尽早获得反馈，哪怕只是“正在检索制度文档”。

8.2 步骤可见 ​

如果 Agent 执行了 3 到 5 个步骤，应该能让用户看见执行轨迹，而不是只看到最终结果。

8.3 可中断 ​

用户应该能取消明显跑偏或耗时过长的流程。

8.4 引用可查看 ​

特别是知识问答类产品，引用不应该埋在一行小字里。 用户应该可以展开查看引用片段和来源文档。

8.5 高风险操作可确认 ​

任何真正有副作用的动作，都不应该“默默执行”。

8.6 失败后有下一步建议 ​

不要只显示“出错了”，而要告诉用户：

  • 是工具问题、权限问题还是信息不足。
  • 建议补什么。
  • 是否转人工。

9. 一个推荐的任务型交互流程 ​

以“帮我整理一份产品评审纪要并生成待办”为例：

  1. 用户输入任务。
  2. Agent 回显理解后的任务计划。
  3. 用户确认计划或修改约束。
  4. Agent 分步骤执行：读取文档、提取结论、生成待办。
  5. 关键步骤展示中间结果。
  6. 最终结果交由用户审核。
  7. 用户确认后再写入系统或导出。

这个流程比“用户发一句话，系统直接返回一大段文本”更符合真实工作场景。

10. 常见失败模式 ​

10.1 过度拟人化，弱化系统边界 ​

现象：文案上很像真人助手，但实际上系统对能力边界、失败原因、高风险操作都不透明。

10.2 所有步骤都隐藏 ​

现象：用户只看到转圈，不知道系统是卡住了还是正在正常执行。

10.3 所有步骤都要求确认 ​

现象：用户被频繁打断，体验过重，反而降低效率。

10.4 失败后上下文丢失 ​

现象：某一步失败后，之前已完成的工作无法复用，用户只能从头再来。

10.5 引用和依据缺失 ​

现象：系统给出结论，但用户无法判断是否可信。

11. 验证方式 ​

你可以通过以下问题检查 Agent UI 是否成型：

  • 用户是否能理解当前系统状态。
  • 用户是否能在关键时刻控制或中断流程。
  • 高风险动作是否都需要合适级别的确认。
  • 失败后是否能保留上下文并继续操作。
  • 用户是否能查看关键证据、引用或执行依据。
  • 系统输出是否能和界面状态严格对应。

12. 可复用模板 ​

12.1 高风险操作确认文案模板 ​

text
即将执行的操作：
影响范围：
预计结果：
是否可回滚：
是否需要审批：
请确认是否继续。

12.2 失败提示模板 ​

text
当前步骤：
失败原因：权限不足 / 工具超时 / 信息不足 / 外部系统异常
建议动作：重试 / 补充信息 / 转人工 / 稍后再试
是否保留当前进度：是 / 否

12.3 任务面板模板 ​

text
任务名称：
当前阶段：
已完成步骤：
待处理步骤：
风险提示：
是否需要用户确认：是 / 否

13. 面试表达 ​

你可以这样讲：

“我在做 Agent 产品时，不把前端理解成聊天窗口外壳，而是把它当成可信执行界面的关键组成部分。我的重点是让任务过程可见、让高风险动作可确认、让失败状态可恢复、让引用和依据可查看。这样用户不会把 Agent 当成一个黑盒，而是把它当成一个能协作、能接管、能追踪的工作伙伴。”