证据与可解释

一句话理解：Agent 的结论要像审计底稿一样可追溯：每个关键判断都能点开，看到用了哪条数据、来自哪个系统、什么时候取的，以及数据是怎样推出结论的。

销售分析 Agent 给出结论：“上周华东区销售额下降 18%，主要原因是 A 类 SKU 缺货。”销售总监看到后的第一反应不是“太好了”，而是：“真的吗？哪几个 SKU？缺了几天？会不会是价格调整导致的？”

如果 Agent 答不上来，或者只能再生成一段看起来很有道理的文字，这个结论就无法被采用。总监不可能拿着一句没有依据的话去找供应链负责人问责。没有证据的结论，对决策者来说价值接近于零，更糟的是，如果结论恰好是错的（模型幻觉、取错了时间范围），它会直接导致错误决策。

这一课讲如何在界面上呈现证据，让用户能快速判断结论是否可信，并在不可信时迅速找到问题。

证据的四个层次

一个可追溯的结论，从上到下分为四层，用户可以逐层展开（图 1）：

图 1 · 证据的四个层次：默认展开结论与依据，来源与原始记录折叠在每条依据后面

大多数用户只看第 1、2 层；抱有怀疑时展开第 3 层；分析师或工程师复核时才需要第 4 层。界面默认展示结论和依据，来源与原始记录折叠在每条依据后面。

不同场景的证据形态

证据不只是文字引用，要根据任务类型选择最直观的形态：

场景	证据形态	呈现要点
知识库问答	原文引用	引用片段可点击跳转到文档原位置，详见引用与可追溯
销售分析	数据表快照 + 图表 + 查询语句	标注时间范围、口径、取数时间，查询语句可展开复制
订单售后诊断	订单状态时间线 + 系统记录	在时间线上高亮异常节点，附系统公告或工单原文
SEO 诊断	页面截图、HTML 片段、检测数值	问题所在的代码行高亮，附检测时间与抓取方式
Coding Agent	代码 diff + 测试结果 + 命令输出	修改前后对比，测试通过与失败的明细
浏览器 Agent	操作截图或录屏	关键步骤截图，尤其是提交表单前的页面状态

一个共同原则：证据要锚定在可核对的系统记录上，例如工具调用的返回、数据库查询结果、文件内容，而不是模型对这些记录的复述。复述可能出错，记录不会。

图 2 画出了这条锚定关系：

图 2 · 证据要锚定在可核对的系统记录上，而不是模型的复述

区分事实、推断与假设

Agent 的报告里混杂着三种性质完全不同的内容，界面必须把它们区分开：

类型	定义	标记示例
已验证事实	直接来自系统记录，可以核对	✓ 已核实
推断	基于事实的分析判断，合理但可能有其他解释	◐ 推断
未验证信息	来自用户陈述、外部网页等未经核实的来源，或 Agent 无法获取数据的部分	○ 未核实

订单售后诊断报告的例子：

诊断结论：订单 A1024 迟迟未退款的主要原因是退款审核队列积压

✓ 已核实  订单 3 月 11 日 14:20 进入退款审核队列，此后 41 小时无状态更新     [状态记录]
✓ 已核实  系统 3 月 11 日发布公告：审核规则升级期间暂停处理退款              [公告原文]
◐ 推断    同期进入该队列的其他 23 个订单均出现停滞，延迟应为系统原因而非个案 [23 个订单]
○ 未核实  客户称已多次联系客服但无人回复（客户陈述，无会话记录可查）
○ 无法获取 审核队列实时进度（审核系统接口超时，未能查询）

注意最后两行。坦诚标出“未核实”和“无法获取”，能避免用户把不确定的信息当作事实使用，也为用户指明了需要人工补充核查的地方。

关于置信度，避免给出没有依据的精确百分比。“置信度 87%”看起来很科学，但如果这个数字只是模型自己说的，它并不具备统计意义，反而会误导用户。用“已核实 / 推断 / 未核实”这类可解释的分类，或者展示“有几条独立证据支持”，更加诚实。

可解释不等于展示思考过程

一个常见的做法是把模型的中间推理原文直接展示给用户，当作“可解释性”。这有几个问题：

信息密度低。 大段推理文字需要用户自己提炼，与“5 秒看懂”的目标相反。
不一定反映真实依据。 模型生成的解释性文字，未必就是它得出结论的真实路径。因此可信的解释应该建立在工具调用记录等可核对的事实上，而不是只依赖模型的自我陈述。
可能包含不该展示的内容。 中间过程里可能有其他客户的数据或内部规则。

更好的做法是把“解释”当作一个 专门设计的产物：由结论、依据、来源组成的结构化说明，而完整的运行记录作为第 4 层，按权限提供给需要复核的人，其数据来源就是 Tracing。

微软研究院的人与 AI 交互指南中有一条准则是“说明系统为什么这样做”（Make clear why the system did what it did）。对 Agent 来说，最有说服力的“为什么”就是证据链。

让证据可以被质疑和纠正

证据不只是用来看的，也应该支持用户的纠错动作：

标记某条依据有误。 例如“这个 SKU 其实是停产，不是缺货”，Agent 基于纠正重新分析，并在报告中记录修改。
补充证据。 用户上传一份 Agent 没有访问权限的供应商邮件。
要求补查。 针对“未核实”的条目，一键让 Agent 追加查询，或生成人工核查任务。

这些纠错行为本身也是宝贵的信号，应该进入持续改进闭环。

常见误区

“结论写得够专业，用户自然会信。” 越是专业的用户，越需要证据。没有证据的漂亮结论会迅速消耗信任。
“把引用链接堆在报告末尾就算有证据。” 证据需要和具体结论逐条对应，用户才知道哪条依据支撑哪个判断。
“显示置信度百分比显得更严谨。” 没有校准的百分比是伪精确，会误导用户。
“隐藏未核实的部分，报告看起来更完整。” 隐藏不确定性是最伤信任的做法之一，一旦被用户发现，此前所有结论都会被怀疑。

设计要点

结论、依据、来源、原始记录四层结构，默认展开前两层。
每条依据与具体结论一一对应，标明数据来源与取数时间。
按场景选择证据形态：引用、数据表、时间线、截图、diff、测试结果。
明确区分已核实事实、推断、未核实信息和无法获取的数据。
不使用没有统计依据的置信度百分比。
解释建立在可核对的系统记录上，而不是直接展示模型的中间推理。
支持用户对证据提出质疑、补充和要求补查。

练习

回到本课开头的销售分析场景（30–45 分钟）：

为结论“华东区销售额下降主要由 A 类 SKU 缺货导致”写出完整的四层证据结构。
至少包含 1 条推断和 1 条未核实信息，并用标记区分。
画出报告页面的文字线框：结论卡片、依据列表、点击某条依据后展开的来源面板。
设计一个“标记依据有误”的交互：用户点击后看到什么、Agent 如何响应。

下一步

证据帮助用户判断“结论对不对”。当 Agent 要据此采取行动时，用户需要判断“这件事能不能做”。下一课「审批与接管」讲确认弹窗之外的审批设计。

证据与可解释