审批不是弹窗：HITL 必须是可恢复的状态机

很多产品把人工审批做成一个确认框：点了同意就继续，关掉页面就丢。这在普通 CRUD 里勉强能用，在 Agent 里会出大事——因为真正危险的不是「人有没有点过」，而是「副作用有没有发生、发生后能不能接上」。

生产级 Harness 里的 HITL，不是 UI 组件，而是可持久化、可恢复的状态机。模型只提出动作；Harness 在副作用前暂停、落盘、等人；进程崩溃后也不能靠运气重放。

一、第一原则：看动作，不看问法

安全判断只看要执行的动作，不看用户怎么问。同一写库、发邮件、删资源动作，客气问与挑衅问必须同一结果。用提示词道德约束替代动作审查，等于把闸门交给概率。

配对评测很有用：同一动作换两种问法，策略结果必须一致。不一致，就说明闸门还在看语气。

二、最小状态机

一套够用的状态可以长这样：

PENDING：已生成规范化请求，等待人决定。

APPROVED：人已批准，尚未认领执行。

EXECUTING：已认领，外部副作用进行中。

EXECUTED：副作用已确认完成。

REJECTED：拒绝，终态。

UNKNOWN：执行中崩溃或结果不明，不能自动当成功或失败。

硬规则很简单：只有 PENDING 能做审批决定；REJECTED 与 EXECUTED 是终态；进入 EXECUTING 前要策略复检且事务先提交；UNKNOWN 不自动重试，必须人工确认已执行或显式允许重试。

三、审批要绑完整请求

人批准的不是一句话，而是一份规范化动作：工具名、参数、作用对象、执行身份、风险等级。批准后若参数被改写，批准作废。

待审批时，敏感中间结果不要回传模型，避免模型在等待期间继续「脑补执行」。落盘要原子写，重启后能从同一游标恢复。

四、什么时候必须 HITL

可以按后果分级：能否撤销、影响范围、是否对外可见、用谁的凭据、成本高低、能否用确定性规则验收。

低风险只读可自动放行；草稿区修改可先执行后审查；发送、发布、删除、采购、生产变更，通常要跨过更强的人工边界。

五、落地检查

1. 关掉页面再打开，待审批任务是否还在
2. 批准后杀进程，会不会重复产生副作用
3. UNKNOWN 会不会被代码自动重试
4. 审计里能否看到谁批准了什么动作

四条里有一条答不上来，你的审批还只是弹窗。

结语

HITL 的价值，不是让人多点一次确认，而是让危险动作在产生副作用前进入可控停机，并在恢复后继续而不重放。状态机做对了，审批才是 Harness 能力；否则它只是界面上的安慰剂。