12｜人审批后事故反而更大：正确设计 HITL 审批系统

李号双

你好，我是李号双。
前面几节课，我们讲了怎么给 Agent 踩刹车、怎么定通信规矩，还有权限的四道锁。做到这一步，很多团队才敢让 Agent 去碰生产环境。但还是不放心，又加了一道——人工审批。可偏偏就是这道审批，最容易出事。
我们先从一个真实场景开始。某公司生产环境的数据库，在一次自动化任务中被意外删除。事后查日志，发现那条致命的 DROP TABLE 请求，确实通过了“人工审批”环节。审批人在手机上收到了一条 Slack 消息：“Agent 请求执行 SQL，参数：[超长 JSON]”，他可能根本没看清内容，就点了个“通过”。
为什么加了人这道“安全网”，事故反而更大了？
很多团队上线人工审批后，起初还认真看，但节奏很快就被打破了：Agent 发起的审批请求一条接一条，白天在弹、周末也在弹，全压在值班的同几个人身上。一周之后，“看都不看就点通过”成了肌肉记忆。还有更糟的：审批请求被扔进值班群 @ 所有人，谁都以为别人看过了——责任一分散，更没人真的看。本应是安全阀的审批，就这样变成了没用的“摆设”。
根本原因在于，我们延续了传统软件中“人作为兜底者”的思维，简单地把“高风险操作”标记后，就推给人来拍板。但 Agent 系统的特点完全不同：它是高频、自主、概率性执行的实体。人的处理能力是有限、异步、会疲劳的。如果不加筛选地同步阻塞等待人的审批，系统不仅会效率低下，更会因为“审批疲劳”导致人失效。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
法语
德语
日语
韩语
俄语
西班牙语
解释
总结

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《生产级 Agent 排雷实战》，新⼈⾸单¥59

立即购买

登录后留言

精选留言

由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。

收起评论