AI agent 人工审批控制台设计：证据、风险、可选动作和恢复入口怎么呈现

很多 AI agent 系统都说支持 Human-in-the-Loop，但实际给人工的只是一个按钮：批准或拒绝。真正到现场用时，这种设计几乎一定会出问题。因为人工接管时最想知道的不是“我要不要点通过”，而是：

• agent 为什么在这里停下
• 它依据了哪些证据
• 当前风险在哪里
• 如果我拒绝或修改，会从哪一步继续

人工审批控制台的作用，不是让人替 agent 背锅，而是让人能在最短时间内做出高质量决策。

建议先配合 Human-in-the-Loop 审批流设计、AI agent Artifact 设计、AI agent Policy Engine 规则分层 和 AI agent Checkpoint 与断点恢复 一起看。

先给结论：控制台至少回答 4 个问题

如果这 4 个问题答不清，审批动作就只能靠经验和运气。

再进一步，控制台不只是一个详情页，它还是一个“把任务分配给合适的人，并在有限时间内完成决策”的操作系统入口。所以除了单页信息结构，还要考虑队列分流、权限和 SLA。

一、顶部先给“当前决策卡片”，不要一开始堆全部细节

人工进入控制台后，第一眼应该先看到一个 summary：

{
  "runId": "run_123",
  "status": "waiting_review",
  "reason": "high risk external send",
  "nextActionIfApproved": "send_message_and_update_status",
  "nextActionIfRejected": "return_to_draft",
  "riskLevel": "high"
}

这张卡片的作用是帮助审核者 5 秒内知道自己正在审什么，而不是立刻掉进日志海里。

一个更完整的决策卡片，最好再补上：

• 业务优先级
• 剩余处理 SLA
• 当前建议动作的风险等级
• 审批后将释放的外部副作用数量

这样审核者不仅知道“在审什么”，还知道“要先审哪个”。

二、证据区要展示“为什么这样建议”，而不是只贴最终结果

证据区建议按层显示：

如果只展示最终建议，人工依然要靠猜测来判断是否靠谱。

如果 evidence 很多，控制台最好默认先展示“证据摘要 + 命中原因”，再允许展开原始片段，而不是一上来堆满全文。人工审批的瓶颈常常不是信息不够，而是信息太多却没有优先级。

三、可选动作不要只有 approve / reject

很多任务最需要的是“有条件批准”或“先改再继续”。一个更实用的动作集合：

审批控制台本质上是恢复入口，不只是同意或否决入口。

同时，动作是否可见也应该受角色和权限控制。例如：

否则控制台看起来功能很全，实际上谁都能做过大的动作。

四、每个动作都要告诉人“系统接下来会怎么跑”

例如 approve 可能意味着：

• 发送外发消息
• 更新任务状态
• 写入审计记录

而 edit_and_resume 可能意味着：

• 生成新 draft version
• 回到 validate 状态
• 重新经过 policy check

如果控制台不展示这些后果，人工是在盲签。

更稳的做法是把每个动作都渲染成“操作表单 + 影响预览”，至少包含：

• 恢复到哪个 checkpoint
• 会生成或替换哪些 artifact
• 会重新跑哪些 policy
• 会触发哪些外部副作用

当动作后果被结构化展示后，审批质量通常会比单靠经验明显稳定。

五、控制台最好支持“基于 artifact 的局部修改”

人工最常见的需求不是重写整份结果，而是：

• 换一条 evidence
• 改一个参数
• 删除一个高风险动作
• 修改外发文案

因此控制台最好围绕 artifact 操作，而不是围绕一个大文本框：

review proposal
  -> inspect evidence
  -> edit draft field
  -> confirm policy impact
  -> resume from checkpoint

这会比“复制全文到输入框里改一遍”稳定得多。

如果 edit_and_resume 会改动结构化字段，最好在提交前先做局部校验和 policy 预演，而不是等恢复后再报错。否则人工刚做完修改，又会被系统弹回，审批体验会非常差。

六、控制台最好先做队列分流，而不是让所有人看同一池任务

真正上线后，review console 的问题往往先出在入口，而不是详情页。建议至少按这些维度分流：

分流做得好，才能让合适的人看到合适的任务，而不是所有待审项都挤在一个列表里。

七、上线后要看审批链路指标

一个成熟的 review console，建议持续观察：

如果审批时长很长，同时 reroute 比例也很高，通常说明控制台不是缺按钮，而是缺上下文和分流。

八、失败案例：审批人只看到“请确认发送”，看不到发送依据

一个通知 Agent 在发消息前会进入人工确认，但控制台只显示一句“是否发送给客户”。审批人看不到来源、看不到当前状态、也看不到外发文案为什么这么写。

后来一次错误发送发生后，团队追查发现：

• evidence 没有展示
• policy 命中原因没展示
• approve 后会触发的副作用没展示

修复后，控制台改为“决策卡片 + evidence + proposal + action impact”四块布局，审批时间反而缩短，因为审核者不再需要反复问系统管理员“这一步到底在干什么”。

九、Review Console Checklist

• 顶部是否有当前决策卡片
• 决策卡片是否包含优先级、SLA 和风险等级
• 是否展示输入摘要、evidence、proposal、policy 命中原因
• evidence 是否支持摘要优先、原文按需展开
• 是否支持 approve / reject 之外的动作
• 动作是否按角色和权限控制可见性
• 每个动作是否展示恢复路径和副作用预览
• edit_and_resume 前是否支持局部校验和 policy 预演
• 是否支持基于 artifact 的局部修改
• 是否按风险、业务域和 SLA 做待审分流
• 审批结果是否进入 run ledger 和 audit log
• 是否监控审批时长、回滚率和 reroute 比例
• 审批后系统是否从明确 checkpoint 继续

结语

AI agent 的人工审批控制台，不是一个“把锅交给人”的页面，而是一个帮助人快速理解上下文、判断风险、做出修改并让系统稳定恢复的入口。设计得好，人工接管会变成系统能力的一部分；设计得差，人工只会成为最后一道混乱的补丁。

延伸阅读：

• Human-in-the-Loop 审批流设计
• AI agent Artifact 设计
• AI agent Policy Engine 规则分层
• AI agent Checkpoint 与断点恢复