有人工监督的AI智能体：何时构建审批门控（何时不该构建）

目录

发布于2026年7月。

摘要： 当错误代价高昂、不可逆或面向客户，且人工能够及时发现时，审批门控才有意义。当量太大无法审查、错误修复成本低，或人们不读就批准时，门控毫无意义。我用四个问题来决策，我的30多个生产智能体大多完全自动化运行。

运营者笔记： 我在两家企业运营智能体——一家咨询品牌和位于得克萨斯州普夫拉格维尔的匹克球馆Pickleland。最初我到处设置审批门控，因为感觉”安全”。几周内，我的Slack频道里塞满了没人读的通知，智能体在技术上受到监督但实际上无人看管。这比没有门控更糟：监督的幻觉而无监督的实质。本文解释我现在如何思考这个决策。

人工监督门控到底是什么

最简单来说，审批门控是智能体工作流中的一个暂停点，人工必须在智能体继续之前进行确认。智能体起草一封邮件——人工在发送前审批。智能体标记一笔交易——人工在处理退款前审核。

门控可以是同步的（智能体阻塞直到有人批准）或异步的（智能体将操作加入队列，发送通知，人工按自己的节奏从仪表板或Slack消息中批准）。对于非时间敏感的事项，异步几乎总是更好的选择，因为同步门控会在队列中产生背压并破坏智能体的可靠性保证。

门控不是什么：重试循环、置信度阈值或回退到更简单的模型。这些是智能体内部的错误处理机制。审批门控是关于人类判断进入循环——有意为之，在特定点，有其原因。

我提问的四个问题

在添加门控之前，我会过一遍四个问题。其中任何一个”是”都是考虑添加门控的信号。全部四个”是”意味着门控在结构上是必要的。

1. 操作是否不可逆（或撤销成本高昂）？

向10,000人发送邮件无法撤回。提交付款无法轻易召回。没有备份地删除数据库记录是永久的。不可逆性是支持门控的最强论据，因为智能体无法撤销其所做的事。

将其与以下情况对比：用一个类别标记一个入站查询。如果标签错了，你两次点击就能纠正。无需门控。

2. 如果智能体出错，谁来买单？

一个内部标签错误——我花几秒钟纠正。一封面向客户的邮件错误——客户为糟糕的体验付代价，我为信任损失付代价。一笔财务交易错误——我用真实的钱和可能的合规风险付代价。

只影响内部系统的智能体可以在没有门控的情况下容忍更多错误。接触客户或金钱的智能体需要赢得无人看管运行的权利。

3. 人工真的能在问题变得重要之前发现错误吗？

这是大多数人跳过的问题，也是消灭门控最多的问题。如果一个智能体每小时处理500个项目，你每个项目收到一条Slack通知，没有人会读完所有500条。你在制造警报疲劳，而非监督。

计算很简单：只有当人工能在可用时间窗口内切实审查被标记的项目时，门控才有价值。如果智能体量大且速度快，门控要么需要高度选择性（只标记边缘案例），要么应该被移除。

4. 人工是否可靠地阅读智能体呈现的内容？

如果你的审批队列满了而人们不读就批准，门控比没有门控更糟——它制造了有人工检查过工作的虚假信任。

门控明显有意义的时候

以下是我总是添加门控的模式，无一例外：

• 不可逆的外部通信 — 发给真实人的邮件、短信、社交媒体帖子。智能体起草；人工发送。根据量而定。
• 超过阈值的财务操作 — 任何移动资金的事情，如果超过我按上下文设置的最低金额，就设置门控。
• 智能体未曾见过的新模式 — 如果智能体的分类器将某事标记为”未知”或超出其训练分布，那就是强制升级。
• 合规敏感输出 — 任何涉及HIPAA、PCI、法律通知或受监管金融内容的事项都由人工审查。

门控悄然扼杀产品的时候

以下是门控看似安全但悄然破坏采用的模式：

• 大量且可逆的操作 — 如果能两次点击撤销，且每天发生200次，审查疲劳会占上风。
• 时间敏感的工作流 — 在30秒内响应客户询问的智能体不应有同步门控。
• 人工拥有的上下文少于智能体的任务 — 如果智能体读了50页上下文来做分类，而审阅者只得到一行摘要，审查就是走过场。
• 内部丰富化和标记 — 标记CRM记录、对费用分类、总结会议记录。风险不值得中断。

我实际部署的三种门控模式

当门控有必要时，我从三种实现中选择：

1. 通过Slack/邮件的异步审批

智能体完成草稿，在指定Slack频道发布带有提议操作和批准/拒绝按钮的消息，然后暂停。我使用Cloudflare Queues保存待处理的操作，以及一个单独的Worker在恢复前监听审批webhook。

适用于：邮件草稿、社交内容、重要CRM更新。

2. 基于置信度的升级

智能体对高置信度输出（比如，在结构化模式上≥0.85置信度）完全自动化运行，并将低置信度项目路由到人工队列。人工只看到模糊的边缘案例。

适用于：分类、路由、分类处理。

3. 仪表板审查与批量批准

智能体的所有输出都进入审查仪表板，而非每个项目设门控。人工批量审查——比如每天早上——并集体批准或纠正。

适用于：内容生成、报告起草、计划摘要。

警报疲劳陷阱

你添加的每个门控都是对某人注意力的永久税收。风险不仅仅是一个门控被忽视——而是三个门控创造了一个嘈杂的Slack频道，让人们习惯性地忽略所有通知。

我建立的纪律：每个门控都有明确的负责人和明确的SLA。如果没有人在SLA内持续审查，门控就被移除并替换为审计追踪。我每月审计所有审批队列。

与智能体可靠性的连接

门控是可靠性堆栈中的一层，而非整个堆栈。我的生产智能体完整可靠性堆栈：

1. 评估框架 — 在部署前确认正确输出。
2. 带模式验证的结构化输出 — 智能体输出被限制在类型化模式中。
3. 置信度阈值 — 低置信度输出进入人工审查。
4. 审计日志 — 智能体的每个操作都记录了输入、输出和模型调用元数据。
5. 人工审批门控 — 仅用于上述不够的操作。

门控是最后防线，而非第一道。如果你的智能体不可靠到需要在每个操作上设门控，根本问题是评估覆盖和提示设计，而非监督流程。

我的经验法则

如果我不希望初级员工在没有先征询我意见的情况下这样做，智能体就需要一个门控。如果我会让初级员工毫不犹豫地去做，智能体应该无人看管地运行。

常见问题

如何处理需要审批但运行量大的智能体？

改变架构：不要求每个项目批准——要求每个模式批准。让智能体运行，但让它呈现统计异常供人工审查。

如果错误可能造成严重损害，但我无法承担完整的人工审查怎么办？

这通常是还不该为那个操作部署智能体的信号。或者，使用置信度阈值让智能体只在高度确信时才行动，其他所有情况升级。如果你使用Claude作为模型层，Anthropic SDK的工具使用模式使得定义一个智能体在缺乏置信度时可以调用的”升级”工具变得简单。