第 2.10.2 节：把对话、状态和引用来源展示清楚
本节围绕“把对话、状态和引用来源展示清楚”展开，先建立直观判断，再进入工程细节。完成本节后，你应该能够说清对话视图与引用来源的处理顺序、关键检查点和失败处理。
核心概念四层解释法
本节用四层解释法讲前端核心概念：人话解释、项目位置、工程动作、面试说法。
AI（人工智能）应用前端
人话解释：AI（人工智能）应用前端是用户看见和操作 AI 系统的地方。它不只是输入框和输出框，还要把系统的依据、状态、风险和下一步动作展示出来。
项目位置：在客服 Agent（智能体）工作台里，前端连接用户、Agent 后端、知识库、工具系统、审批中心、人工客服和管理后台。
工程动作：设计页面分区、状态流转、字段契约、权限提示、错误提示、日志摘要、反馈入口和人工接管入口。
面试说法：我不会把 AI 前端做成纯聊天框，而会把它设计成可解释的工作台，让用户知道系统依据什么回答、做了哪些工具动作、哪里需要人工确认，以及失败时怎么继续。
对话视图
人话解释：对话视图是用户和 Agent 交流的主界面，但它必须能展示比文字更多的信息。
项目位置：客服工作台的对话视图要同时展示用户消息、Agent 回答、引用来源、状态标识、转人工入口和反馈按钮。
工程动作：为每条消息设计 message_id（消息编号）、role（角色）、content_summary（内容摘要）、citations（引用来源）、state_badge（状态标识）和 feedback_score（反馈评分）。
面试说法：我会把消息当成可追踪业务对象，而不是一段无状态文本。每条消息都要能关联引用、工具、错误、反馈和 trace_id（追踪编号）。
引用来源
人话解释：引用来源告诉用户：这段回答从哪里来。没有引用来源，用户只能相信模型；有引用来源，用户可以检查依据。
项目位置：客服 Agent 回答售后政策、产品说明、订单规则时，前端应该展示资料标题、版本、片段摘要、更新时间和权限范围。
工程动作：设计引用卡片，支持展开查看摘要、跳转资料、标记过期、隐藏无权限资料，并记录引用是否被用户点击。
面试说法：我会用引用来源降低黑箱感。用户看到的不是“模型说可以退”，而是“根据 2026 年 7 月版售后政策第 3 条，可以进入人工审核”。
工具调用卡片
人话解释：工具调用卡片展示 Agent 是否真的调用了业务系统，以及工具执行到了哪一步。
项目位置：查询订单、创建工单、检查售后政策、发起退款审批，都应该在前端呈现为清晰卡片，而不是藏在后端日志里。
工程动作：卡片要展示工具名称、动作摘要、执行状态、输入摘要、输出摘要、错误原因、是否可重试、是否需要确认和 trace_id（追踪编号）。
面试说法：工具调用卡片让用户和客服都能看懂 Agent 做了什么。它不是炫技组件，而是可控性和人工接管的基础。
审批卡片
人话解释：审批卡片是高风险动作的人工确认界面。它告诉审批人：Agent 想做什么、依据是什么、风险在哪里、同意后会发生什么。
项目位置：退款、补偿、发送短信、批量导出、删除资料、发布知识库，都需要审批或确认界面。
工程动作：审批卡片至少包含 proposed_action（拟执行动作）、evidence_refs（证据引用）、risk_reason（风险原因）、approval_status（审批状态）、approver（审批人）和过期时间。
面试说法：我会把高风险动作从“模型自动执行”改成“模型准备材料，人类确认执行”。前端审批卡片就是 Human-in-the-loop（人工参与闭环）的产品形态。
fallback（降级方案）状态
人话解释：fallback（降级方案）状态是系统无法继续时给用户的可理解出口。它不是简单报错，而是解释当前发生了什么、能不能恢复、下一步怎么做。
项目位置：知识库没命中、工具超时、权限不足、引用过期、审批等待、人工队列繁忙，都需要兜底状态。
工程动作：为每类失败设计 error_banner（错误提示条）、handoff_status（转人工状态）、permission_notice（权限提示）和建议动作。不要让模型在失败后编造结果。
面试说法：AI 系统一定会失败。我会把失败设计成可理解的状态流，而不是让用户面对“系统繁忙”或空白页面。
本章在客服工作台中的位置
客服 Agent 工作台可以拆成 7 层。本章关注最上面的工作台交互层，但它必须理解下面每一层的状态。
| 层级 | 作用 | 前端要呈现什么 |
|---|---|---|
| 用户入口层 | 用户提问、上传资料、选择订单、提交反馈 | 输入框、附件、订单选择、反馈按钮。 |
| 对话状态层 | 维护多轮会话、消息、任务进度 | conversation_id（对话编号）、message_id（消息编号）、state_badge（状态标识）。 |
| 知识检索层 | RAG（检索增强生成）查找政策和资料 | citations（引用来源）、资料版本、无命中提示。 |
| 工具调用层 | 查询订单、创建工单、发起审批 | tool_call_card（工具调用卡片）、执行状态、错误原因。 |
| 权限与护栏层 | 判断能不能看、能不能做、能不能返回 | permission_notice（权限提示）、error_banner（错误提示条）、脱敏提示。 |
| 人工协作层 | 转人工、审批、质检、复盘 | approval_card（审批卡片）、handoff_status（转人工状态）、客服备注。 |
| 管理配置层 | 管理知识库、工具、日志和质量策略 | 配置页、日志摘要、质检反馈、异常统计。 |
前端的难点在于：它不能只等后端给一个“最终文本”。它要能展示中间过程，同时又不能把内部提示词、敏感参数、密钥、完整隐私或无权限资料暴露给用户。
系统流程图
这张图有 4 个重点：
读图重点：先读上组的会话、检索和工具判断，再进入下组的确认、审批与执行；成功、失败和转人工最终都回到反馈与 trace_id 复盘。
- 前端要展示 Agent 运行过程，而不只展示最终回答。
- 引用、工具、审批、转人工和错误都要有可见状态。
- 用户看到的是业务化提示，管理员看到的是可复盘日志。
- 失败路径也是产品流程的一部分，不是异常之外的东西。
模块拆分
客服 Agent 工作台前端可以拆成这些模块：
| 模块 | 负责什么 | 主要展示 |
|---|---|---|
| Conversation Panel（对话面板） | 展示多轮对话和输入区 | 用户消息、Agent 回答、追问、反馈。 |
| Citation Drawer（引用抽屉） | 展示回答依据 | 资料标题、片段摘要、版本、更新时间、权限提示。 |
| Tool（工具） Call Timeline（工具调用时间线） | 展示工具执行过程 | 工具名称、状态、输入摘要、输出摘要、错误原因。 |
| Approval Center（审批中心） | 承接高风险动作 | 待审批动作、证据、风险说明、同意、拒绝、修改。 |
| Handoff（任务转交） Panel（转人工面板） | 处理人工接管 | 转人工原因、队列状态、客服接管人、预计等待。 |
| Error and Fallback Layer（错误与兜底层） | 展示失败、降级和恢复动作 | 错误提示条、重试、补充信息、转人工。 |
| Permission Notice（权限提示） | 解释不可见或不可操作原因 | 无权限、需登录、需管理员、资料已隐藏。 |
| Log Summary Panel（日志摘要面板） | 给客服、主管、管理员复盘 | trace_id（追踪编号）、检索、工具、审批、耗时。 |
| QA Feedback（质检反馈） | 收集用户和质检评价 | 反馈评分、错误类型、备注、复盘标签。 |
| Admin Configuration（管理配置） | 管理知识库、工具和工作台策略 | 工具开关、审批规则、资料状态、展示策略。 |
这些模块不一定一开始都做成独立页面。MVP（最小可行产品）可以先做一个工作台页面，用分区、抽屉和卡片承载这些职责。关键是不要把所有信息塞进一段模型回答里。