生成一封邮件错了，可以重写；AI 自动把邮件发给客户、删除数据库或提交付款，错误成本完全不同。Agent UX 不能只增加一个“Run”按钮，而要根据后果决定什么时候自动执行、什么时候必须先让人确认。
01 把“建议”和“执行”当成两个不同权限等级
传统 Copilot 主要给建议，用户自己完成动作；Agent 开始代表用户调用工具，产品责任随之变化。
界面应该明确区分“AI 建议你这样做”和“AI 将实际执行”。按钮、状态和语言都不能让用户误以为只是预览。
02 风险分级比“所有动作都确认”更可用
如果 AI 每创建一条内部草稿都弹确认，自动化价值会快速下降；如果转账、群发邮件也完全自动，则风险过高。
可以按可逆性、金额、外部影响、数据敏感度和范围分级。低风险自动执行，中风险批量确认，高风险逐项审批。
03 确认前应该展示结果预览，而不是只问“是否允许”
Microsoft HAX 的 Feedforward 模式强调在高风险或难以撤销的行为前说明后果。Agent 确认页应展示将修改什么、发送给谁、涉及多少对象。
“允许 AI 执行 8 个操作？”远不如列出“向 3 位客户发邮件、更新 4 条 CRM、创建 1 个任务”可判断。
04 允许用户修改计划再执行
Agent 计划 10 步，其中第 7 步不合适，用户不应该只能“全部批准”或“全部取消”。可以允许删除某一步、修改参数、暂停到某一步再确认。
这种可编辑计划比把所有 Agent 行为藏在后台更能建立控制感。
05 批量批准要明确范围和共同规则
如果 100 个动作本质相同，例如“为所有未回复客户创建草稿”，可以允许用户确认规则后批量执行。
但一旦每个对象的数据不同、后果不同，就需要抽样预览、异常提示或逐项审批。效率不能以看不见差异为代价。
06 执行中应支持暂停，执行后尽可能支持撤销
长任务不是点击后等待结束。用户需要看到当前进度、已完成哪些步骤、是否还能停止。
可逆动作尽量记录 Undo 或回滚；不可逆操作则更应该在之前提高确认强度。
07 Agent 必须留下可追溯的行动记录
NIST 的生成式 AI 风险框架强调治理、测量和管理风险。企业 Agent 场景中，谁发起、AI 做了什么、用户批准什么、工具返回什么，都应有审计记录。
这既用于安全和合规，也能在错误发生时快速重建过程。
08 最好的 Agent 自动化不是“完全无人”，而是把人放在最有价值的决策点
Human-in-the-loop 不是失败兜底，而是系统设计。机器擅长重复执行，人擅长处理目标、例外、风险和责任。
当审批点恰好放在高风险和高不确定节点，Agent 才能既提高效率，又不会让用户失去控制。
09 高风险 Agent 可以采用“计划—批准—执行”三段式
用户先看到 AI 拟定的计划，确认目标和工具；再批准关键步骤；执行后查看结果。相比一句指令直接黑盒运行，这种结构让责任和变化更清楚。
并不是每个任务都需要完整三段式，但涉及外部发送、数据修改和付款时非常适合。
10 默认权限应遵循最小必要原则
如果 Agent 只需要读取日历，就不应该默认获得发送邮件、删除事件和访问全部 Drive 的权限。连接器授权范围越大，用户越难判断风险。
产品可以在需要某动作时再请求额外能力，并解释“为什么需要”。这既是安全策略，也是信任体验。
11 Agent 执行结果要区分“成功提交”和“真正完成”
调用外部系统返回 accepted，不代表订单已经处理完。界面应跟踪异步结果，避免 AI 说“已完成”但外部任务仍排队。
对用户来说，状态语义必须与真实世界后果一致。
常见问题
AI Agent 每次执行都要用户确认吗？
不需要。应按风险、可逆性和影响范围分级，低风险动作可以更自动化。
确认页最重要展示什么？
具体动作、对象、范围和不可逆后果，而不是只显示一个“允许/拒绝”。
Agent 能不能先执行再 Undo？
可逆低风险任务可以，高风险不可逆任务应在执行前确认。
批量批准安全吗？
只有当动作逻辑一致、异常可识别且范围清楚时才适合。
为什么需要审计日志？
用于责任追踪、错误恢复、安全治理和理解 Agent 实际做过什么。
相关服务与进一步咨询
链接复制成功
