文章给了三种 HITL 模式（同步审批、异步抽查、异常触发），但业界更精细的分类是四层：Human-in-the-loop（人作为同步阻塞节点，必须等审批）、Human-over-the-loop（人作为监督者，只在异常时介入）、Human-in-the-command（人始终掌握最终决策权，Agent 只给建议）、以及 Agent-in-the-loop（Agent 反过来辅助人类工作流）。这四层不是互斥的，一个成熟产品往往同时使用多层——比如高频低风险操作跑 HotL 的异步抽查，高危操作跑 HitL 的强制审批，而超长尾则降级给人做决策。

文章提到客服 Agent 自动退款 1 万元的案例并非孤例。2023 年，某电商 Agent 未经审核直接同意用户 10 倍赔偿，一周内发生 17 起，损失超 30 万；另有 AutoGPT 错将售价 1000 美元的商品设为 1 美元促销，72 分钟内被下单 3217 笔，直接损失 270 万美元。这些案例的共同点不是模型能力差，而是设计时根本没给『人留位置』——没有审批节点、没有金额阈值熔断、没有超时降级，让 Agent 在完全无监督的状态下执行了不可逆操作。

文章讨论的是产品设计层面的人工介入，但法律视角给出更硬的答案：AI 不具备民事主体资格，其承诺不构成法律上的『意思表示』。杭州互联网法院审理的全国首例 AI 幻觉侵权案中，AI 向用户承诺『若出错将赔偿 10 万』，法院最终驳回索赔——责任不在 AI，而在未尽到提示义务和可靠性义务的服务提供者。这意味着 PM 设计 HITL 节点时，不仅是为了产品体验，更是为了在法律上明确『最后拍板的是人』，否则一旦出事，责任链会直接回溯到公司。

文章指出了『审批疲劳』的陷阱：每天 200 条审批请求，人必然进入无脑点同意的状态。但问题不只是数量——当 Agent 把『确认框』当作 HITL，用户连决策内容都没看就点通过，这套机制就形同虚设。真正值得追问的是：如何设计『让审批人不得不思考』的介入节点？一种思路是随机强制执行『反向确认』——要求审批人先解释为什么同意，再点确认按钮。另一种是从 HotL（人在环上监督）而非 HitL（人在环中阻塞）的角度重构流程，让审批人只看异常摘要而非逐条审批。