进展、证据与信任

智能体系统可能看起来很忙，却没有真正取得进展。它们可以流式输出 Token、打开工具、修改计划、调用 API，并生成自信满满的摘要，却没有减少用户的不确定性，也没有改变相关状态。

反之亦然。一个系统可能看起来停滞不前，但实际上正在等待审批、核对并纠正一个未知影响，或者正在运行一个缓慢但比所有先前可见活动都更重要的验证步骤。如果产品不能区分这些状态，用户就无法监督工作。他们要么过度信任系统的表现，要么在错误的时间中断系统。

值得信赖的体验并不意味着让系统显得自信、友好或神奇。它意味着帮助人们根据证据、不确定性、后果以及他们在任务中的角色，恰当地信赖系统。

论点

值得信赖的智能体体验应使当前状态、实质性操作、来源、假设、不确定性、限制以及完成证据足够可审查，以支持用户的决策，同时避免超出证据的虚假精确性和说服性解释。

产品应区分三个概念：

• 活动（Activity）： 系统执行了某些操作。
• 进展（Progress）： 一个未满足的成功条件被减少了，或者相关状态发生了变化。
• 完成（Completion）： 已接受的证据支持承诺的结果。

模型可能会叙述活动。产品应基于已接受的状态、工具结果、来源记录、检查、审批和人类决策来体现进展和完成。

诚实地展示运行状态

用户应知道工作是否处于：

• 已创建但未启动；
• 已排队或已准入；
• 运行中；
• 等待用户；
• 等待其他人；
• 等待依赖项、计划、回调或审批；
• 受阻；
• 部分完成；
• 已取消；
• 已失败；
• 已成功；或
• 已升级处理（escalated）。

这些状态应映射到架构中的运行时状态，但产品语言可以更友好。重要规则是诚实。当系统正在等待用户审批时，不要显示“工作中”。当验证未完成时，不要显示“完成”。当存在有用的部分结果时，不要显示“失败”。当正在进行的操作结果未知时，不要显示“取消”仿佛没有产生任何影响。

WCAG 2.2 要求状态消息在程序上可确定，以便辅助技术能够呈现重要变化而不窃取焦点（W3C, 2023）。智能体状态更新不是装饰。它们是用户控制的一部分。

基于成功条件构建进展

一个好的进展展示应回答：

• 正在追求什么目标？
• 什么已完成并已验证？
• 当前正在尝试什么？
• 还有什么未完成？
• 自上次更新以来发生了什么变化？
• 什么证据支持该变化？
• 什么是不确定的、受阻的或正在等待的？
• 用户现在可以做什么？

避免戏剧化的进展表达，例如“努力思考”、虚假的百分比、动画忙碌状态，或者看起来很厉害但无助于用户行动的长篇工具日志。对于不确定的任务，优先使用里程碑和基于证据的进展：

目标：比较三家供应商的 SOC 2 证据和数据保留契合度。

已完成：
- 找到了所有三家供应商自己的安全页面。
- 验证了两家供应商的 SOC 2 可用性。

当前状态：
- 正在检查主要文档中的保留条款。

受阻：
- 供应商 C 需要登录信任门户。

下一步用户操作：
- 批准使用供应商提供的摘要，或将供应商 C 排除。

这比 72% 完成 更有用，除非产品能够解释该百分比背后的分子、分母和不确定性。百分比适用于具有已知单位且工作量可比较的任务。当发现过程改变计划时，百分比会产生误导。

区分证据等级

并非所有证据都应获得相同的视觉或产品权重。来源可以是：

• 用户提供的；
• 从已连接系统检索到的；
• 由模型推断的；
• 作为草稿生成的；
• 通过确定性检查验证的；
• 由人类审查者接受的；
• 从记录系统回读的；
• 过时或超出其新鲜度窗口的；
• 被另一个来源矛盾的；或
• 不可用的。

当这些区别影响决策时，界面应保留它们。基于政策文本、当前订单状态和回读确认的客服智能体建议，和基于旧邮件生成摘要的建议并不相同。编码智能体说“测试通过”时，应指明哪些测试通过、用的是哪个命令、有哪些失败或跳过。研究智能体说“来源一致”时，应显示哪些来源、发布日期和声明范围。

不同的任务需要不同的证据：

任务类型	用户可能需要的证据
研究	来源、发布日期、访问日期、冲突、无支持的声明、相关性限制
编码	更改的文件、差异、运行的命令、通过或失败的测试、lint/构建状态、评审状态
支持	政策规则、客户事实、已暂存或已执行的操作、退款 ID、升级原因
运维	接触的系统、审批、日志、当前状态、回滚或补偿路径
个人生产力	日历、收件人、草稿、已发送消息、自审批以来的更改
采购或风险管理	标准、来源权威性、缺失证据、假设、评审者接受情况

以有助于用户决策的级别展示证据。原始追踪记录可能会让人不知所措；精炼的摘要可能会遗漏决定性的事实。使用渐进式披露：先是简洁的状态，然后是可展开的来源、操作、检查与记录。

解释决策，但不要捏造确定性

微软的人机交互论文建议在适当的时候解释系统能做什么、为什么这样做以及其确定性程度（Amershi et al., 2019）。Google 的 People + AI Guidebook 同样强调心智模型、可解释性和信任校准（Google PAIR）。对于智能体，解释必须包含环境证据，而不仅仅是模型的推理过程。

有用的解释应连接以下内容：

目标 -> 证据 -> 行动或建议 -> 不确定性 -> 下一步选择

弱解释：

我选择这个选项，因为它最适合您的需求。

更强有力的解释：

我将供应商 A 排在第一，因为其当前安全页面列出了 SOC 2 Type II，
数据保留设置可由工作区管理员配置，
并且它支持您设定的欧盟区域要求。
我未验证 DPA，因为它需要账户登录。

不要将隐藏的思维链（chain-of-thought）当作证据来展示。用户需要的是行动的依据：来源、观察信息、检查、假设、替代方案、被拒绝的选项以及限制条件。如果生成的解释不能与这些记录挂钩，就可能变成说服。

以可用的形式保留不确定性

有用的不确定性是具体的：

• 哪个事实未知；
• 为什么它重要；
• 检查了哪些证据；
• 正在做出什么假设；
• 证据有多强或多弱；
• 什么可能改变结论；
• 在不确定的情况下什么行动是安全的；以及
• 用户是否需要做决定。

避免使用诸如“AI 可能会犯错”之类的模糊免责声明作为主要控制手段。它们虽然正确，但很弱。更可取的做法是：

我只找到了此 API 行为的供应商文档；简报中没有独立的实施证据。

或：

支付写入在派出后超时，因此在状态被核对并纠正之前，结果未知。

或：

此答案使用了 2026 年 7 月 18 日上传的文档。它不包含该日期之后的政策变更。

置信度分数只有在经过校准且对用户有意义时才有帮助。一个基于不明确基础的精确数字可能比一句简单的限制说明更糟糕。像“高置信度”这样的标签不应将来源质量、模型自我评估、政策合规性和用户接受度混合成一个未经解释的徽章。

解释也可能增加过度依赖。2024 年的一项研究发现，解释并不能一致地减少对错误 AI 建议的依赖（Cecil et al., 2024）。持久的设计教训是：测试用户是否注意到植入的错误、质疑无支持的声明并做出更好的决策，而不仅仅是他们是否报告界面感觉透明。

展示实质性操作和影响

当系统使用工具或影响外部状态时，用户应能够看到：

• 请求了什么；
• 什么被允许、拒绝或暂存；
• 使用了哪个身份或权限；
• 返回了什么结果；
• 什么状态发生了变化；
• 什么仍然待定、部分或未知；
• 什么证据确认了该影响；
• 下一步操作是什么；以及
• 用户是否可以撤销、补偿或升级处理。

这并不要求暴露每个内部 Token、模型消息或实现追踪记录。它确实要求保留操作的来源（provenance）。用户不应通过最终答案来推断系统是否真的发送了电子邮件、提交了工单、打开了拉取请求、提交了退款，还是仅仅起草了文本。

在权限边界处，操作证据应尤其清晰。如果系统从“准备”进入“发送”，从“暂存”进入“提交”，或从“推荐”进入“决定”，用户应看到该转换及其依据。

为用户决策而设计

适当的证据密度取决于用户能用它做什么：

用户决策	所需证据
让工作继续	当前状态、剩余工作、预算、阻塞项、预期下一步影响。
批准某个操作	目标、数据、权限、策略检查、自上次批准以来的更改、可逆性。
接受最终结果	完成证据、局限、未解决的问题、产物、外部影响。
纠正任务	当前假设、受影响的待定操作、旧范围与新范围。
升级处理或接管	目标、状态、证据、尝试、部分或未知影响、负责人、截止日期。
事后审计	事件追踪记录、来源与流转记录、审批、版本、结果证据。

因此，进展视图应具有角色意识。最终用户可能需要一张简单的“等待您批准”卡片，并带有精确的操作。操作员可能需要队列年龄、依赖状态和未知影响计数。审查者可能需要引用和差异。支持经理可能需要客户影响和政策原因。

不要把同一份原始追踪记录倒给所有人。追踪记录是生产侧记录。证据链路（evidence trail）是面向用户的说明，用来解释实质性来源、操作、检查、假设和未解决的限制。

将完成视为一个证据声明

谨慎使用完成相关的措辞：

标签	含义
已完成	已接受的证据满足产品承诺。
待审查	系统生成了一个候选结果，但必须由人接受。
部分完成	一个子集可用且限制明确。
受阻	一个已命名的缺失输入、权限、依赖项或策略阻止了进展。
失败	系统结束而未满足承诺的结果。
已升级处理	责任已移交给某个人或另一个流程。
已取消	已处理一个授权的停止操作，并报告了影响状态。

不要让模型的声明“我完成了任务”成为产品状态。完成应反映来自控制回路的已接受结果证据。

完成证据应与后果成比例：

• 头脑风暴任务可以以一份草稿和一条说明（未验证任何声明）结束。
• 研究任务可能需要来源、限制条件和无支持的声明。
• 编码任务可能需要更改的文件、测试和剩余的失败。
• 支持任务可能需要策略匹配、已执行的操作 ID 和升级记录。
• 受监管的决策可能需要人类决策负责人、解释、审计追踪和申诉路径。

避免信任表演

信任校准（Trust calibration）不是信任最大化练习。过度信任会导致用户接受错误或未授权的工作。信任不足会导致他们忽略有用的自动化或手动重复工作。产品应帮助用户看到何时依赖是合理的，何时需要审查。

常见的信任表演（trust theatre）手法包括：

• 没有来源或操作证据的精致最终文本；
• 诸如“已验证”之类的徽章而未解释验证者；
• 百分比或置信度分数中的虚假精确性；
• 掩盖等待或失败的动画活动；
• 省略注意事项、失败检查或手动修复的摘要；
• 将隐藏的人工干预呈现为自主成功；
• 听起来像证据的生成理由；
• 始终积极的语言使失败状态显得不诚实。

优先选择证据而非安抚。一句平静的“我无法从主要来源验证此声明”比一个带有通用免责声明的自信答案更值得信赖。

失效模式

忙碌动作信任

界面显示了许多步骤、Token、动画或工具名称，但用户无法判断发生了什么变化，也看不到支持这些变化的证据。

流畅性作为证据（Fluency as evidence）

最终答案很精炼，因此产品将其视为已验证。来源、操作、检查和状态变化缺失。

虚假精确性（False precision）

系统显示了一个未经过校准或对任务无意义的置信度百分比或进度条。

倾倒追踪记录（Trace dumping）

产品暴露原始日志而非决策相关证据。用户无法找到他们需要的少数事实。

隐藏等待（Hidden waiting）

系统看似在运作，但实际在等待审批、依赖项、计时器或人工移交。

过度说服性解释（Overpersuasive explanation）

生成的推理使系统听起来比证据支持的更确定。

摘要作为完成（Summary as completion）

一个生成的总结说工作已完成，即使所需的检查、审批或外部影响尚未解决。

本手册的判断

1. 诚实地表示当前运行状态。
2. 将进展展示为针对成功条件的证据，而非活动量。
3. 使实质性来源、操作、假设、检查和状态变化可审查。
4. 以具体、可操作的语言保留不确定性和限制。
5. 使用与已接受证据匹配的完成标签。
6. 根据用户的决策、角色和后果调整证据密度。
7. 测试用户是否校准信任并捕获错误，而不仅仅是他们是否喜欢界面。

检查清单

• 用户能否判断工作是在运行、等待、受阻、部分完成、失败、升级处理、已取消还是已完成？
• 进展是否显示什么发生了变化、什么仍然存在以及什么证据支持该变化？
• 来源、操作、检查、假设和状态变化是否在适当级别可审查？
• 未知、过时、推断、生成、人工接受和已验证的事实是否被区分？
• 工具操作和外部影响是否足够可见以便用户控制？
• 界面是否避免虚假百分比和无支持的置信度分数？
• 状态变化是否对辅助技术可访问？
• 完成标签是否与证据挂钩，而非生成的声明？
• 产品是否诚实地显示等待、受阻和未知影响状态？
• 团队是否针对过度依赖、遗漏错误和证据理解进行了测试？

参考文献及其用途

• Cecil et al., “The effects of AI explanations on human decision-making” —— 同行评审证据，用于提醒解释并不能自动防止过度依赖。
• Google People + AI Research, People + AI Guidebook —— Google People + AI Research 发布的设计网页资源，用于支持心智模型、可解释性、反馈、控制和平稳降级；它不能证明某个具体解释界面一定会避免过度依赖。
• Microsoft Research, “Guidelines for Human-AI Interaction” —— 经同行评审的人机交互论文，支持期望设定、不确定性、解释、纠正和控制。
• W3C, Web Content Accessibility Guidelines 2.2 —— W3C 推荐标准，用于可访问的状态消息、输入辅助和可操作控件。