AI智能体审批门控：该把人工审核放在哪一步

大多数 AI 智能体的演示，都把"人类确认"做成了一个最后弹出的按钮。问题是——等你点下去，邮件已经发出去了，数据库那行也已经写完了。

真正有用的审批门控不在对话的结尾，而在循环内部，卡在改变外部世界的那一个动作之前。

为什么门控要对准"副作用"而非"回答"

智能体做两类事：读和写。

读包括搜索、检索文档、调用只返回数据的 API；写包括发消息、改记录、转账、删东西。读错了代价很低，结果扔掉重来就行；写错了代价往往不可逆。

所以审批门控应该挂在工具层，而不是挂在对话层。让智能体自由地规划、自由地读取；一旦它决定调用某个会写入的工具，就停下来，把它想执行的那次调用原样保存，然后等待。

def call_tool(run, tool, args):
    if tool.writes and needs_approval(tool, args):
        request = save_pending(run.id, tool.name, args)
        run.pause(waiting_on=request.id)
        return  # resumes later from the saved request
    return tool.execute(args)

作者给出的判断不是"一写就审"，而是两个维度的组合：可逆 vs 不可逆，以及内部 vs 对客户可见。不可逆且面向客户的动作永远等待；可逆的内部动作通常不必拦。比如"创建草稿"和"发送草稿"是两件事，前者可以放行，后者必须拦截。

审核者到底需要看到什么

"智能体想更新一条记录，批准？"——这种提示每次都会被秒批，等于没有审核。

关键在于给审核者说不的依据。文章列出了三条最低要求：

• 精确的动作和参数，尽量以 diff 形式对照当前状态展示。"把截止日期从 11 月 12 日改到 11 月 3 日"远比一坨 JSON 好用。
• 动机和来源。用一句话说明智能体为什么这么做，并附上它参考的资料；如果某个检索到的文档驱动了这个决定，把链接放出来。
• 无人应答时会发生什么。一个没有过期时间的审批请求，会变成一个几周后突然触发的陈旧操作。

还有一条常被忽略的设计：允许审核者直接编辑参数，而不是只能在批准/拒绝之间二选一。大多数纠错都很小——一个错的日期、一个错的收件人。为了改一个字段而驳回整个动作、再让智能体重跑一遍，浪费的是所有人的时间。

别单独相信模型自报的置信度

一个很诱人的做法是：模型说自己有把握，就跳过审批。

但作者提醒，让模型评估自己的置信度，它经常会对错误答案给出高分。更可靠的做法是采用模型外部可验证的信号：

• 检索到底有没有找到相关内容，还是答案来自模型的记忆？
• 参数能否通过校验——记录是否存在、金额是否在正常区间？
• 这类动作此前是否已多次被原样批准？
• 重复执行这一步会不会造成伤害？

这些信号可以合成一个分数，重点在于其中每一项都不需要去问模型，都能从外部独立核实。

这里涉及一个常被混淆的概念：校准（Calibration）。一个模型的"置信度"要真正可用，必须满足校准条件——即当它说"我有 90% 把握"时，在大量同类问题里，它确实有约 90% 是对的。研究表明，语言模型在生成式任务上普遍存在过度自信，尤其是对它训练数据中不常见的领域，往往给出高分却答错。

更麻烦的是，模型的自评分数和它的实际正确率之间并没有稳定映射：同一个提示词换个措辞，分数就可能大幅漂移。这也是文章主张用外部信号的原因——检索命中率、参数校验、历史审批记录这些指标不依赖模型的自我报告，而是从可观测的事实中推导出来，天然更接近真实置信度。把这些信号合成一个分数后，阈值可以随业务风险调整，而不是被模型的"自我感觉"绑架。

说"同意"之后如何恢复执行

审批可能在几分钟后到达，也可能拖上好几天。到那时，发起请求的进程可能已经没了，记录可能已经变了，审核者还可能手抖点了两次。

作者的解法偏向工程化：

• 持久化那次待执行的调用，而不是智能体的记忆。 恢复时直接执行保存下来的调用，而不是让模型重新推一遍、指望它给出同样的答案。
• 执行前再看一眼世界。 如果记录在请求生成之后发生了变化，就重新询问。
• 给每个已批准动作一个幂等键，让重复点击或重试只执行一次。
• 写一条审计行，记录谁在何时批准了什么、实际跑了什么。出问题时，这是所有人第一个会去找的东西。

人类在环（Human-in-the-loop，HITL） 与人类在回环之上（Human-on-the-loop） 是两种不同的监督范式，文章隐含地倾向后者。HITL 要求人在每个关键决策点上同步阻塞、逐次确认；HOTL 则让人只在异常或高风险节点介入，平时系统自主运行、人负责事后审计与例外处理。

这两种模式的选择直接影响审批疲劳的程度。HITL 看似更安全，但如果被放到所有写操作上，就会不可避免地退化成"无脑点击"。HOTL 的代价是要求系统具备更强的自动判别能力——这正是前面那些外部信号、幂等键、审计日志存在的原因。它们共同把"人是否要介入"变成一个可配置、可量化、可优化的工程问题，而不是一个非黑即白的开关。

审批疲劳：比没有门控更危险

一个每天弹五十次的门控，会被无脑点穿。这比没有门控更糟，因为它看起来像是有监督。

文章给出的监测指标很具体：统计每一类请求被"原样批准"的比例。当某个低风险动作的通过率长期居高不下，就应该把它自动化掉，把人的注意力转移到那些真正会被编辑或驳回的请求上。

说到底，目标不是让每个循环里都站着一个人，而是让人在那些出错代价高昂的少数步骤上，并且面前摆着足够的信息，能真正接住错误。

幂等键（Idempotency Key） 是这段工程化设计里最容易被低估的一环。它的核心思想是：给每一个"已批准的动作"分配一个全局唯一的标识符，执行端在真正落库或调用外部 API 前，先检查这个键是否已经处理过；如果处理过，就直接返回上次的结果，而不是再次执行。这样即使审批者手抖点了两次、网络重试导致请求重发、或者恢复进程被多次唤醒，副作用也只发生一次。

在没有幂等键的朴素实现里，重复执行往往不会立刻暴露。比如"发送邮件"重复执行只会多收一封，看起来无害；但"转账 100 元"或"删除该行记录"重复执行就是事故。因此幂等键不是可选优化，而是把"审批"和"执行"解耦之后必须配套的基础设施。它通常与审计行一起写入同一张表，键本身也作为审计的一部分，方便事后追溯是哪一次点击触发了这次执行。