工具调用 UX：让 AI 的每次行动都可见、可控、可恢复

“正在调用 search”几乎没有信息量。用户真正关心的是：系统为什么要搜索、会访问什么数据、结果会如何影响下一步。

高风险操作需要把授权设计为明确决策：范围、影响和撤销路径同时出现；低风险读取则不必用弹窗打断任务。

工具调用经常比模型输出慢。将过程拆成准备、执行、校验、汇总几个可观察阶段，能显著降低用户对“卡住了”的判断。

不要用无限 Loading 掩盖不确定性。超过预期时长就给出延迟原因、继续等待和替代动作。

原始 JSON 很少是最终界面。先给用户一条结论，再保留可展开的来源、参数和日志。这样既能快速阅读，也能在需要时审计。

失败不是末路：保留输入、指出失败边界，并提供重试、修改参数或改用人工流程的出口。

工具不应共享同一种确认策略。纯读取、可逆写入、高影响写入和外部副作用是四个不同等级：查询天气可以直接执行，修改草稿可以执行后提供 Undo，删除数据需要执行前确认，付款和对外发布还需要明确身份与二次校验。

风险等级应来自服务端 tool policy，而不是模型自己判断。Policy 至少考虑数据敏感度、影响范围、是否可逆、费用、外部可见性和当前用户权限，再决定 auto-approve、inline approval 或强确认。

界面要解释为什么这次需要确认。如果同一个工具因为参数不同而风险不同，确认卡必须展示产生差异的关键参数，而不是只显示工具名称。

一个 Tool UI 至少处理参数流入、等待批准、执行中、部分结果、完成、错误、取消和结果过期。只实现 loading 与 result，会让审批、重试和流式结果在真实接入时被迫塞进临时判断。

参数仍在流式生成时，组件可以先展示稳定字段，对未完成字段使用 skeleton；但涉及金额、目标账号和删除范围时，必须等关键字段 complete 后才能开放确认。

结果组件要保留 toolCallId、输入摘要、来源与时间。用户看到结论后可以展开证据，失败后可以基于同一输入修改并重试，审计系统也能把界面动作关联到服务端执行记录。

工具失败后直接显示 Retry 看似简单，却可能重复产生副作用。前端必须知道工具是否幂等、服务端是否返回 idempotency key、上一次执行停在提交前还是提交后。

对于不确定是否成功的外部操作，首选查询状态而不是再次执行。对于部分成功的批量任务，要列出成功项、失败项和未执行项，只允许针对安全集合继续。

取消同样需要契约：停止接收流不等于服务端工具已经停止。UI 应区分“已停止显示”“正在请求取消”和“执行已取消”，并在无法撤销时明确说明后台仍可能完成。