12 篇博文 含有标签「human-in-the-loop」

当 AI 系统犯下严重错误时，一种本能的反应似乎很合理：在流程中加入人工环节。如果一名审核员遗漏了某些内容，就增加第二层审核。如果法务部门感到不安，就增加第三层。这种级联反应给人的感觉像是安全性的复利叠加——每一个审批阶段都是另一层保护。

事实并非如此。在大多数高审核量的生产系统中，增加审批层级反而会降低 AI 的准确性，让审核员产生一种毫无实际作用的监管错觉，而且最糟糕的是，它会毒化 AI 训练所依赖的反馈信号。最终，你承担了人工审核的全部运营成本，却几乎没有获得任何安全性收益。

每个智能体产品的安全仪表盘上都应该有一个数字，但几乎没人追踪它：随时间推移的人均批准率。发布一个“我可以发送这封邮件吗”或“我可以针对生产环境运行此查询吗”的权限提示，其曲线每次都如出一辙。第一天，用户会犹豫、阅读，有时会点击“不”。到了第二周，这已经是本小时内的第五次提示，拒绝的代价是必须由你亲自完成工作，于是点击率会收敛到 95% 以上。团队的安全叙事仍然声称用户批准了每一项操作。但在任何实质性的认知层面上，用户并没有。

这不是一个可以通过更好的文案来修复的 UX 问题。这是使 Cookie 横幅、浏览器 SSL 警告和 Windows UAC 对话框失效的同一种习惯化现象，只是应用在了一个运行速度比以往快几个数量级的底座上。许可门槛是一种具有半衰期的安全控制。如果在发布时不衡量它的衰减速度，你发布的只是一个用户到第二周就会习惯性忽略的复选框 —— 以及一个依赖于不再具有任何意义的点击的合规叙事。

发布的 AI 功能带有一个完美的“安全方案”。任何置信度高于阈值的请求都会自动执行。任何低于阈值的请求都会进入人工审核队列。刚发布时，每天下午 5 点队列就会被清空。市场部门在幻灯片上写下“人工参与（human-in-the-loop）”。合规部门签字批准。大家打道回府。

六个月后，该功能的使用量增长了 10 倍，但审核团队并没有。队列里堆积了 72 小时的待办任务。一个需要“人工审核”的项目在未读状态下躺了三天，然后被一名疲惫的审核员批准——他平均处理一个决策只需 11 秒，因为只有这样才能保证队列不会在夜里翻倍。产品依然宣称“每项操作都经过审核”。现实情况是，“人工参与”已经退化成了“人工最终会在队列里看到”——这在功能上其实就是带有文书延迟的自主运行。

安全方案并不是因为 Bug 而失效，而是因为一个没人负责的人力资源计划而崩溃。

大多数AI团队能告诉你他们的遏制率——AI在不转交给人工的情况下处理的交互比例。但很少有团队能告诉你这个数字是否合理。

升级标准是AI增强团队中最重要的设计文档，而大多数团队根本没有这份文档。他们有一个埋藏在YAML文件中的阈值，以及一个隐含的假设：AI知道自己什么时候卡住了。这个假设在两个方向上都是错误的：阈值过高，人工就要花时间返工AI的工作；阈值过低，用户在没有任何补救措施的情况下承受AI的错误。两种失败都是隐性的，直到它们积累成大问题。

大多数团队将人机协作审核作为事后补充：智能体完成其工作链，结果落入审核队列，然后人工点击批准或拒绝。这看起来像是安全保障，但实际上大多只是一种表演。

当一个多步骤智能体到达链尾审核时，它已经发送了 API 请求、修改了数据库行、起草了客户邮件并安排了后续跟进。所谓的"审核"不过是在批准一件已经完成的事。拒绝它意味着向智能体——通常也向用户——解释为什么过去 10 分钟发生的一切都不作数。

错误放置审批关卡造成的危害并不总是戏剧性的。更多时候，危害更加隐蔽：审核者批准一切，因为真正的决策已经做出；工程师在事故发生后增加更多检查点，却眼睁睁看着产品信任度崩溃；组织在"太多摩擦"和"监督不足"之间摇摆，却从未解决根本的放置问题。

大多数智能体升级流程都是披着善意外衣的冷转接。智能体决定无法继续推进，丢下一句"正在为你转接人工客服"，然后将会话路由给一个对此前发生的一切一无所知的坐席——不知道智能体尝试了什么、哪里失败了、用户究竟需要什么。人工客服从零开始，用户不得不重复自己。信任就此侵蚀——不是因为 AI 出了错，而是因为没有人设计好那个边界。

温和交接模式是一套架构规范，专门针对智能体让渡控制权的那个关键时刻。它将这个边界视为系统的一等关注点，而非事后诸葛。做好了，接收方——无论是人类还是另一个智能体——都能进入一个已经被充分告知、结构清晰的场景。做差了，那个边界就是用户信任的坟场。

负责任的 AI 部署核心存在一个悖论：你越努力让人类参与审查 AI 决策，这种审查就越失去意义。

2024 年哈佛商学院的一项研究让 228 名评估者获得了带有 AI 推理说明的 AI 建议。人类审查者与 AI 建议保持一致的可能性比对照组高 19 个百分点。当 AI 还提供叙述性理由——解释为什么做出某个决策——时，顺从度又增加了 5 个百分点。更好的可解释性反而产生了更差的监督效果。回路中的人类已经沦为表格上的橡皮图章。

大多数构建 AI 代理的团队都在为成功而设计。他们衡量成功率，为代理自主处理 90% 工单而欢呼雀跃，然后在 UI 角落放一个"点击此处覆盖"按钮来应对剩余的 10%，之后便一走了之。

这个按钮不是安全网。它是一种包装成功能的责任。

失败模式不是代理崩溃，而是名义上负责的人类在崩溃发生时无法接管。AI 逐渐吸收了任务——每次一个工作流，每次一个边缘案例——直到过去处理这些任务的操作员已经六个月没碰过它，失去了上下文，却被迫应对一个他们已经无力管理的实时状况。这就是温备问题，它会悄无声息地积累，直到某次事故将其暴露出来。

大多数发布 AI 功能的团队都犯同样的错误：他们直接从"让 VP 印象深刻的原型"跳到"生产环境中完全自主"。然后出了问题——一个错误的推荐、一个不正确的自动回复、一笔本不该被批准的金融交易——整个功能被撤掉。不是调低，是撤掉。

问题不在于 AI 自主性是危险的。问题在于大多数团队将自主性视为一个二元开关——关或开——而它应该是一个旋钮，在这两个极端之间有明确的、被监控的位置。

当客服专员收到包含原始聊天记录的 AI 到人工移交时，准备解决问题所需的平均时间为 15 分钟。专员必须在 CRM 中查找客户、查询相关订单、计算购买日期，并重新推导 AI 已经确定的内容。而当同样的移交以结构化负载（Payload）的形式到达时——包含操作历史、检索到的数据以及触发升级的确切歧义点——准备时间会缩短至 30 秒。

这种手动工作量减少 97% 的情况并非极端案例。这正是能够真正支持人工监督的升级协议，与仅仅将上下文抛给恰好在值班人员的协议之间的区别。

大多数代理 (Agent) 故障并非以“爆炸”这种显式方式发生。它们往往是悄无声息的。代理删除了错误的数据记录，给客户发送了过时的信息，或者重复执行了一个已经成功的支付操作 —— 而你直到两天后收到支持工单 (Support Ticket) 时才会察觉。其根本原因几乎如出一辙：代理拥有对生产系统的写入权限，但在“决定行动”与“执行行动”之间缺乏检查点。

审批门禁 (Approval Gates) 是应对这一问题的工程化方案。这里指的不是那种没人看的合规复选框（即弹窗），而是真正的架构中断点 —— 它们能够暂停代理的执行，序列化状态，等待人工决策，然后干净利落地恢复运行。如果设计得当，它们能让你部署具有真实自主权的代理，而无需在每一次推理调用中都拿生产数据去冒险。

大多数构建 AI Agent 的团队花费数周时间进行部署前评估，却几乎不测量 Agent 在生产环境中实际的行为。这正好本末倒置了。真正重要的指标——Agent 无监督运行的时长、寻求帮助的频率、承担的风险程度——只有在运行时，跨越数千个真实会话之后才能浮现。不去衡量这些，等于盲目飞行。

一项针对数千次生产部署和软件工程会话的大规模研究，揭示了一些真正令人意想不到的发现。呈现出来的图景，与大多数构建者的预期大相径庭。