📌 本文是「AI Agent 的人类控制权」系列的第 5/5 篇。第一篇建立问题意识，第二篇给出三层分析框架，第三篇用框架做六大框架体检，第四篇深入工程实现，本篇讨论前端设计与 Automation Bias。另有番外篇讲微软 Agent 框架的分裂与统一。

——Agent HITL 的前端设计与 Automation Bias 陷阱

前四篇我们讨论了 HITL 的理论框架、工程机制和基础设施。现在假设你全都做对了——框架侧硬控制到位，Checkpoint 正常运行，异步审批流程畅通。Agent 要发一封邮件，框架拦住了，审批请求到了人类面前。

然后人类看都没看就点了"批准"。

这不是假设。这是 HITL 系统在实际运行中最常见的失效模式——不是技术失效，而是人类失效。学术界有一个精确的术语来描述这个现象：Automation Bias（自动化偏见），即人类过度依赖自动化系统的输出，放弃了自己的独立判断。

前面所有篇章解决的是"能不能让人类介入"。这篇要解决的是"人类介入了，但介入得有没有意义"。

Automation Bias：HITL 的隐形杀手

Automation bias 不是新概念。在航空领域，飞行员过度信赖自动驾驶系统、忽视仪表异常数据的案例研究已经积累了几十年。在医疗领域，研究发现医生在有 AI 辅助诊断时，对 AI 错误判断的检出率显著下降。

但在 Agent 系统中，automation bias 的风险被进一步放大。原因有三个：

第一，Agent 的输出看起来"太合理了"。 LLM 生成的内容语言流畅、逻辑连贯、格式专业。一封 Agent 起草的邮件读起来完全像是一个能干的同事写的。人类要发现其中的问题——比如收件人不对、数据引用有误、语气不适合这个场景——需要主动克服"这看起来很好"的第一印象，进行逐项审查。这比发现一个明显的拼写错误难得多。

第二，审批频率和认知负担的恶性循环。 如果 Agent 一天触发 50 个审批请求，而其中 48 个都是正确的、不需要修改的，人类很快就会学到一个"经验"：Agent 大概率是对的，我快速批准就好。到第 49 个真正需要拦截的请求出现时，人类已经进入了"自动批准"模式。这就是审批疲劳——HITL 的形式存在，但实质已经消失。

第三，信息不对称。 Agent"知道"它为什么做这个决策——它的推理链、它参考的数据、它考虑过的替代方案。但审批界面通常只展示最终动作：“要发送邮件给 [email protected]，主题是会议纪要。批准？“人类面对的是一个缺乏上下文的决策——这本质上就是"盲审”。

审批界面的五个设计原则

基于 automation bias 的研究和 Agent HITL 的特殊需求，我总结了五个设计原则。它们不是 UI 规范（颜色、字号那些），而是信息设计原则——审批界面上应该展示什么、怎么展示、什么时候展示。

原则一：展示"为什么”，而不只是"做什么"

反模式： “Agent 想调用 execute_sql。参数：DELETE FROM users WHERE last_login < ‘2024-01-01’。批准？”

正确做法： “Agent 想清理不活跃用户。它计划执行一条 SQL 删除语句，会影响约 3,200 条记录。这是因为你在任务描述中要求’清理超过一年未登录的账户’。具体 SQL 如下：…。批准？”

区别在于：反模式只给了动作本身，人类需要自己推断这个 SQL 意味着什么。正确做法把 Agent 的意图（清理不活跃用户）、影响范围（3200 条记录）、决策依据（用户的原始指令）和具体操作（SQL 语句）都展示出来了。人类有足够的信息来判断"这是不是我想要的"。

这对应了 Amershi 等人（2019）在人机交互设计准则中提出的 G11：“Make clear why the system did what it did”——让用户理解系统行为的原因。

原则二：主动暴露风险信号

不要等人类自己发现问题。如果 Agent 或框架检测到了任何异常，应该主动高亮提示。

几种应该主动标注的风险信号：

  • 影响范围异常：“这个操作会影响 3,200 条记录（过去一个月的平均操作是 50 条）”
  • 参数异常：“收件人是 all-company@，这个地址包含 2,000 人”
  • 与历史行为偏离：“Agent 之前从未调用过 delete_table 工具”
  • 不可逆操作标记：“此操作不可撤销”
  • 成本信号：“预估 API 调用费用：$12.50”

这不要求 Agent 自己能发现所有问题。框架可以基于简单的规则（参数值超出历史均值 N 倍、涉及特定关键词、影响行数超过阈值）自动生成风险标签，嵌入审批界面。

原则三：增加"认知摩擦"，但只在关键时刻

Automation bias 的研究（Buçinca et al., 2021）表明，认知强制函数（Cognitive Forcing Functions）——迫使人类在做决策前经历一个额外的认知步骤——能有效降低盲目批准率。

在 Agent 审批中，这意味着：

  • 低风险操作： 一键批准，不增加摩擦。读文件、搜索、计算——这些让用户快速通过。
  • 中风险操作： 要求人类做出明确选择，而不是只有一个"批准"按钮。比如展示两个选项：“批准发送"和"先看邮件全文再决定”。
  • 高风险操作： 增加结构化摩擦。比如要求人类在文本框中输入批准理由（哪怕只是"确认过收件人列表"），或者要求二次确认（“你确定要删除 3,200 条用户记录吗？请输入数字 3200 来确认”）。

关键是只在高风险操作上增加摩擦。如果所有操作都有二次确认，摩擦就退化成另一种形式的审批疲劳。

原则四：提供对比基线

人类很难从绝对值判断"这个参数正不正常"，但很擅长从比较中发现差异。

利用这一点： 在审批界面中展示"通常情况"作为对比基线。

  • “收件人：[email protected]（你上次发给了 3 个人，这次发给 15 个人）”
  • “SQL 影响行数：3,200（同类操作的历史中位数：45）”
  • “API 调用预估费用：$12.50（你设置的单次预算上限：$5.00）”

有了基线，异常值一眼就能看出来。没有基线，3200 是多是少，人类根本无从判断。

原则五：为"纠正者"模式提供编辑能力

第二篇讲过，把关人的审批不是简单的 Yes/No——人类可以修改参数后再放行。审批界面需要支持这个操作。

最小可用的编辑能力：

  • 修改工具调用的参数（改收件人、改 SQL 的 WHERE 条件、改金额）
  • 修改后实时预览影响（改了 WHERE 条件后显示新的影响行数）
  • 给 Agent 附加指令（“批准，但发送后把结果也抄送给我”）

进阶能力：

  • 直接编辑 Agent 的状态（State Surgery），不仅改这一步的参数，还能改 Agent 记忆中的信息
  • 修改后续计划（“这步批准，但下一步不要自动发送，先给我看草稿”）

LangGraph 的 update_state 和 Command(resume=modified_value) 在后端支持了这些操作。前端的挑战是把这些能力以非技术用户也能操作的方式暴露出来。

审批队列的设计

单个审批界面之外，还有一个经常被忽略的问题：审批队列。当多个 Agent 实例同时运行、多个审批请求同时积压时，人类需要一个"收件箱"来管理这些待办。

审批队列的关键设计要素：

优先级排序。 不是所有审批都同等紧急。涉及金钱的操作、不可逆的操作、即将超时的操作应该排在前面。可以用风险等级（L0-L4）和等待时长来计算优先级。

批量操作。 如果 Agent 生成了 10 封邮件需要逐一审批，应该支持"全部预览→全选批准"，而不是点 10 次。但批量批准前需要确认人类确实看过了每一封（比如要求逐条展开过才能全选）。

超时策略。 审批等了 24 小时没人处理怎么办？选项包括：自动拒绝（安全优先）、自动升级到其他审批人（可用性优先）、自动降低 Agent 自主性级别然后重试（渐进式处理）。没有万能答案，取决于业务场景。

审计日志。 每一次审批（批准、拒绝、修改）都应该记录：谁审批的、什么时候、原始请求是什么、修改了什么、审批理由（如果有）。这不仅是合规需求（EU AI Act Article 14 要求的"可追溯性"），也是系统改进的数据源。

一个容易忽略的视角：Mobile

你的审批请求不总是在人类坐在电脑前时到达。高优先级的审批可能需要在手机上处理——Agent 要给客户发一封紧急邮件，而你在午饭路上。

移动端审批的设计约束更严格：屏幕小（信息密度受限）、交互成本高（打字不方便）、注意力分散（环境干扰）。

移动端的最小可用设计：

  • 推送通知包含足够的摘要信息（“Agent 要发邮件给 3 个客户，主题：合同变更”）
  • 一键批准/拒绝，不需要打开 App
  • 如果需要修改，跳转到详情页

这意味着审批信息的摘要质量极其重要。一条推送通知里，你需要在 100 个字符内传达：谁要做什么、影响是什么、紧急程度如何。这本身就是一个信息设计挑战。

小结：HITL 是 UX 问题

这篇的核心论点只有一个：HITL 的有效性最终取决于人类能否做出有质量的判断，而判断质量取决于信息设计。

后端再完美——Checkpoint 再可靠、框架再灵活——如果人类在审批时看不到关键信息、感受不到风险信号、被审批疲劳磨平了警觉性，HITL 就退化成了一个合规表演：形式上有人类在循环中，实质上人类只是一个自动点击"批准"的橡皮图章。

EU AI Act Article 14 对此有明确的警告：部署者需要让负责监督的人员"保持对自动依赖 AI 输出可能性的警觉"——这说的就是 automation bias。法规要求你不只是"有"人类监督，而是有有效的人类监督。审批界面的设计质量，直接决定了你的 HITL 是否满足这个标准。

五个设计原则再回顾一遍：展示"为什么"而非只展示"做什么"；主动暴露风险信号；在关键时刻增加认知摩擦；提供对比基线帮助判断；为人类提供编辑能力。

这些原则不需要等到框架支持了才能做。即使你用的是最简单的 HITL 实现，只要你把审批界面从"approve/reject"的二元按钮升级为一个展示上下文、标注风险、支持修改的交互面板，HITL 的实际效用就会有质的提升。

最后一个展望。HITL 产生的每一次审批行为——人类批准了什么、拒绝了什么、修改了什么参数、在什么情况下选择了介入——都是极高质量的人类偏好数据。这些数据记录了"在这个具体场景下，人类认为 Agent 应该怎么做"。未来，这些数据可以回流到模型微调中，让 Agent 逐步学会"什么时候该自己做、什么时候该问人"——形成一个"用得越多、越懂你"的飞轮效应。HITL 不只是安全机制，它是 Agent 进化的燃料。但这是另一个话题了。

这是「AI Agent 的人类控制权」系列的第五篇。 完整系列：