Agent UX 设计：进度、控制权与可信交付

Agent 界面不是更长的聊天窗口

聊天适合表达目标和补充信息，但复杂 Agent 还会规划、调用工具、等待审批、生成文件和修改外部状态。如果所有过程都挤在消息流中，用户很难知道任务做到哪里、是否卡住、哪些动作已经不可逆。

Agent UX 的核心是建立正确心理模型：它正在代表用户完成一个有状态的任务，可能需要时间，也可能需要纠正。界面应同时提供进度、证据和控制权。

对于简单低风险任务，可以直接行动；对于复杂或高影响任务，开始前应把目标转成清楚的交付说明：要产出什么、数据范围、关键限制和预计需要的权限。

不要用十几步计划吓用户。展示三到五个有意义的阶段即可，例如“收集数据—分析问题—生成报告—等待发布确认”。具体工具调用属于运行细节，只在需要排错或审计时展开。

若目标存在关键歧义，先问一个能改变执行路径的问题。已经有合理默认且风险低时，可以说明假设后继续，让用户随时修改。

“正在思考……”无法帮助用户判断是否值得等待。更好的状态是：正在读取 12 个文件、已完成 3/5 个数据源、等待系统返回、需要确认发布对象。

但进度也不能伪造精确百分比。开放式研究很难提前知道总步骤，显示 83% 只会制造错误期待。可以使用阶段状态和已完成事实：

已完成  数据范围确认
进行中  聚合错误日志（2/3 个区域）
待开始  形成结论与建议

长时间没有新进展时，界面要解释原因并提供操作：继续等待、缩小范围、稍后通知或取消。后台任务可以关闭页面继续运行，但用户应能在任务中心重新找到它。

模型“准备发送邮件”只是计划；工具返回成功并取得消息 ID 才是动作完成；收件系统接受消息又是进一步业务结果。界面必须使用准确动词，不能把“已生成草稿”写成“已发送”。

对外部影响动作，展示执行前预览和执行后回执。回执包含业务编号、时间和可查看入口。失败时说明哪些部分已经完成，避免用户误以为可以安全重试整个任务。

结果页应把结论与证据连接。研究报告中的关键判断可以展开查看来源；代码修改可以展示 diff 和验证；批量操作可以展示数量、失败项和重试范围。

“停止”不是隐藏在菜单里的高级功能。运行中的任务应支持取消；可调整任务还应允许修改范围或优先级。用户提出新要求时，系统要说明它会更新当前计划、追加任务还是替换目标。

取消是有状态操作。界面可以显示“正在停止当前工具”，随后确认哪些动作已发生。不能在用户点击取消后继续提交外部写入。

修改目标后生成新的计划版本，并保留变更记录。用户应该看得出 Agent 为什么不再执行旧步骤，而不是面对突然变化的结果。

用一个抽象置信度数字通常没有帮助。“置信度 72%”无法告诉用户下一步做什么。更好的表达是区分：已由系统确认的事实、根据证据推断的结论、尚缺的信息和可能影响结果的假设。

例如：“日志确认错误集中在版本 3.8；网络原因仍是推断，因为欧洲节点指标缺失。补充该指标后可以验证。”这让用户可以决定接受当前结果还是继续调查。

遇到多个合理方案时，展示差异、代价和推荐理由，而不是要求用户阅读模型全部思维过程。解释应围绕决策证据和业务影响。

审批弹窗应明确动作对象、关键参数、预计影响和是否可撤销。危险动作不能用默认高亮的“确认”诱导点击。批量操作显示总数并提供样本；金额和收件人等关键字段需要视觉突出。

用户拒绝后，Agent 应停止或提供替代方案，不能换一个名字相似的工具绕过审批。授权过期或参数变化时，界面说明为什么需要重新确认。

权限申请采用渐进方式。只有任务走到确实需要的阶段才请求敏感权限，并解释用途和持续时间；不要在首次进入产品时一次索取所有能力。

错误信息要区分暂时故障、输入问题、权限不足和业务拒绝。可以自动重试的错误展示下一次尝试时间；需要用户操作的错误提供具体入口；不可恢复错误保留已经生成的产物。

任务恢复后显示“已从上次检查点继续”，并列出重新验证的状态。不要悄悄从头执行，让用户困惑为什么收到重复消息或出现两个文件。

观察用户能否准确回答：Agent 现在在做什么、已经改变了什么、还需要多久或什么条件、如何停止、结果依据是什么。任务成功率之外，还要记录取消响应时间、重复提交、审批误操作、追问轮次和用户手动修正比例。

可用性测试要包含慢任务、部分失败、审批拒绝、目标中途变化和跨设备恢复。只测一次顺利演示，看不到 Agent 体验最关键的状态转换。

好的 Agent UX 不是让系统表现得像无所不能的人，而是让用户始终知道目标、进度、证据和控制边界。准确状态、可中断任务、参数化审批和可追溯结果，会比拟人化措辞更快建立信任。