自动化偏见：人类为何橡皮章AI，如何防护

自动化偏见，是指人们过度信任自动化系统：未经充分审查便接受它的建议（作为错误，errors of commission），甚至彻底停止监控它（不作为错误，errors of omission）。这解释了为什么人面对 AI Agent 的输出时，往往会直接批准，而没有真正检查。对于任何构建 Agent 的人来说，自动化偏见都是“人在回路”（human in the loop）理念面临的最大威胁，因为它会悄无声息地把监督变成走过场。人点击批准，操作随即执行，所有人都以为已经有人审核过，但实际上根本没有发生真正的审核。

本文将解释什么是自动化偏见、它为什么会导致人类对 AI 的监督失效、哪些因素会助长它，以及该如何通过设计加以防范。文章将采用 LoopRails——一个免费、面向实践者的人在回路监督框架——其方法是 Grade · Guard · Show · Prove（参见该框架）。

什么是自动化偏见：作为错误与不作为错误

自动化偏见会以两种截然不同的方式出现，而你的设计必须同时防范这两种情况。

作为错误（Errors of commission）。即使其他信息本应让人停止操作，人仍然按照系统的建议采取了行动。Agent 提出一项变更，人类批准了它，但该提议其实是错误的：审核者明明掌握了发现问题所需的信息，却选择服从机器。比如，Agent 计划删除一张“未使用”的表，而这张表后来被证明是系统正常运行不可或缺的一环；批准这项计划，就是一种作为错误。

不作为错误（Errors of omission）。人停止监控，因而错过了系统没有主动标记的问题。Agent 获得信任并自行运行，人类逐渐退出监督，而它从未暴露出来的故障就这样悄无声息地溜了过去。Agent 过去表现得越可靠，这种倾向就越强：此前每一次正确操作，都在教会人类“下一次应该也没问题”。于是，随着风险不断累积，人的注意力却逐渐转移。

陷阱在于，从当事人的角度看，这两种错误都显得合情合理。一个系统已经连续正确了一百次，继续听从它，看起来是一种合理的经验法则，而不是懒惰。这正是自动化偏见这种 AI 风险如此难以通过培训消除的原因。它不是性格缺陷，而是人们与可靠自动化系统互动时的一种结构性特征。专家同样会受其影响，警告也无法消除它，而且 Agent 越先进，问题反而越严重。

为什么自动化偏见会让“人在回路”失效

有一项研究发现，足以改变你对 Agent 监督的理解。针对 AI 编码 Agent 的研究（参见 LoopRails codex）测试了这样一个问题：要求 Agent 在行动前先提交计划并获得批准，是否能阻止不良行为？从行动层面看，计划审批确实有所帮助：它把成功攻击率从约 90% 降到了 60%～74%。

但对自动化偏见而言，真正关键的是人类进行审核时发生了什么。当问题真的呈现在人面前时，干预成功率——即人类发现并阻止不良操作的比例——在所有被测试的监督策略中都只有 9%～26%。换句话说，大约四次中有三次，人类还是会批准。失败并不是因为没有注意到。人们看到了这项操作，却为它寻找合理解释，并逐渐把 Agent 的叙事框架视为正常。研究人员将其称为识别瓶颈（recognition bottleneck）：瓶颈不在于有没有看到，而在于能否把自己看到的东西识别为问题。

结论非常直接：增加一个审批 prompt，并不会让人类突然变成善于发现 Agent 错误的检测器。这是自动化偏见代价最昂贵的表现。审批关卡确实存在，审计日志中也记录了批准，但不良操作在大多数情况下仍然顺利通过。审批变成了走过场。

因此，“回路中有没有人？”问错了问题。如果一个人面对的是大到无法读完的 diff、要到事后才能显现的后果，或根本来不及反应的情况，那么即使他身处回路之中，也没有真正发挥监督作用。LoopRails 重新构造了这个问题：不再用一个非黑即白的问题判断监督是否存在，而是针对每项操作追问——这个人能否在当前时间窗口内发现这个错误？如果答案是否定的，就应该直接防止不良结果发生，而不是把它放在一次点击之后等待放行。

哪些因素会助长自动化偏见

对 AI 的机械批准并非随机发生。少数几个因素让这种行为变得可以预测，而每个因素都可以修复。

生产力压力。Agent 的存在就是为了提升人的工作速度，因此在团队看来，逐项仔细审查操作的审核者反而会拖慢进度。激励机制会把人推向快速批准，而快速批准也就意味着浅层审核。

用整洁的摘要代替证据。这是最容易修复的因素。当 Agent 告诉你“我更新了认证配置，以提升安全性”时，人类其实无从检查。摘要无法验证，于是唯一可选的反应就是相信它。更糟糕的是，无论底层操作是否正确，只要摘要写得足够自信，就会提高人们的接受率。具有说服力的理由是一套推销话术，而不是证据。

告警疲劳。如果不断要求一个人确认，他最终就不会再阅读这些 prompt。这并不是假设：研究发现，临床医生会忽略 49%～96% 的安全告警。同样的机制也会摧毁 Agent 监督。为每一项琐碎操作都设置关卡，只会训练出下意识忽略提示的反射；于是，真正重要的那次 prompt，也会像前面一百次无关紧要的提示一样，被人自动点击通过。在现实世界中，过度提示是导致监督失效的主要方式之一。

责任归属不清。当责任被分散——Agent 提出操作、平台负责执行、人类只需点击——就没有人真正觉得自己应该为结果负责。切身感受到责任，是少数几种被证明确实能够减少自动化偏见的因素之一。与之相反的情况被称为“道德溃缩区”（moral crumple zone）：一个人被放在某个位置上，负责替自己实际上根本无法控制的系统承担责任，因此他也没有多少动力去认真审查它。

如何通过设计防范自动化偏见

你无法仅靠劝诫让人摆脱自动化偏见。警告和培训都解决不了这个问题。真正需要改变的是设计：要么让人做出真正的决策，要么别再让他们承担自己根本无法胜任的工作。以下措施来自 LoopRails 的 Show 步骤。

强制做出真正的决策。最有效的防御方式是引入一种强制机制：要求人类在看到 Agent 的答案之前，先明确提交自己的判断。审核者如果先说明变更应该是什么样，就有了一个属于自己的比较基准，也就无法简单地听从机器。这种共同执行（co-execution）模式，是应对识别瓶颈最可靠的方法，因为它让盲目服从变得不可能。

展示证据，而不是摘要。不要提供整洁的描述，而要展示真实操作及其后果：实际的 diff、确切的收件人列表、DELETE 将影响的具体数据行、真实的金额和收款人。摘要会隐藏错误，而具体产物会暴露错误：

- ALLOWED_ORIGINS = ["https://app.example.com"]
+ ALLOWED_ORIGINS = ["*"]

任何读到这段 diff 的人都能看出，Agent 刚刚向整个互联网开放了 CORS；而“改进了认证配置”这样的摘要，恰好隐藏了最关键的问题。组织证据时，目标应该是帮助人类发现错误，而不是向人推销这个答案。

谨慎使用审核者的注意力。注意力是一种稀缺且容易流失的资源。每在琐碎事务上消耗一次 prompt，就少了一份可以投入真正重要事务的注意力。不要为 G0 和大多数 G1 操作设置关卡；直接运行并记录，或先执行再通知，同时提供一键撤销。只在真正能够由人类改变结果的操作上打断用户。这样，实际弹出的 prompt 才不会被忽略。（默认映射方式参见 playbook 和单页速查表。）

只把人类审核留给可发现、影响重大的操作；其他情况则应直接预防。根据可逆性、影响范围和风险程度对每项操作进行分级（高风险但仍可发现的层级参见 G2 指南，关键层级参见 G3 指南），然后追问：人类真的能及时发现并纠正这个错误吗？如果答案是肯定的，而且风险确实很高，就使用前述措施，构建一个真正有效的审核时刻。如果答案是否定的——内容太多，根本读不完；没有反应时间；或故障只有落地后才会显现——就不要请求批准，而应直接防止不良结果发生：

缩小后果或放入沙箱。让操作变得可逆（参见 rail-reversible），或限制其影响范围，使其风险等级下降；同时，把安全边界从 prompt 转移到运行环境中：禁止网络访问、限制凭据权限、使用临时机器。

采用 maker-checker，或者拒绝并升级处理。对于不可逆的操作，提议者不能同时担任审批者；审批者还应该是此前没有参与这项任务的人，因为已经与 Agent 协作一个小时的人，往往早已接受了它的叙事框架（参见 maker-checker for AI）。如果连这一点也做不到，就把操作交给拥有决策权的人类负责人，并附上一份上下文充分的摘要。

判断标准始终不变：人类能否及时发现这个问题？如果诚实的答案是否定的，那么审批 prompt 就是错误的工具；依赖它，不过是在等待自动化偏见迟早发生。

自动化偏见就是对自动化系统的过度信任：未经审查就接受建议（作为错误），以及停止监控（不作为错误）。专家同样会受到影响，而且 Agent 越可靠，这种偏见反而越严重。

它会导致“人在回路”失效：针对 AI 编码 Agent 的研究发现，即使问题已经呈现在人类面前，干预成功率仍然只有 9%～26%。这是一种识别瓶颈，而不是注意力不足。审批最终变成了走过场。

助长它的因素包括生产力压力、整洁的摘要、告警疲劳（临床医生会忽略 49%～96% 的安全告警），以及责任归属不清（道德溃缩区）。

应该通过设计来防范它：在人类看到答案前，强制其先做出真正的判断；展示证据而不是摘要；谨慎使用人的注意力；只让人审核那些风险高但仍能及时发现的问题，其他问题则直接预防。

主导一切的判断问题，从来都不是“回路中有没有人？”，而是“这个人能否及时发现这个错误？”如果不能，就应该防止结果发生，而不是在前面设置一道审批关卡。

使用交互式分级器评估 Agent 的操作，再通过 playbook 为每项操作设计相应的监督时刻。如果想了解它如何融入完整的安全论证，可以阅读“人在回路是否能提升 AI 安全性”以及“AI Agent 应该在何时请求批准”。如需了解该方法以及每一项论断背后的证据，请阅读 framework 和 codex。

本文最初发布于 looprails.dev/article-automation-bias.html。LoopRails 是一个免费且有资料依据的框架，用于设计针对 AI Agent 的人在回路监督机制。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。