先给结论：企业 Agent 是否必须人工确认，应由动作风险决定，不由模型“有多确定”决定。 凡是涉及资金或库存、对外承诺、权限提升、不可逆变化、大范围对象以及法律或专业裁量，都应在执行前由有权人确认。
这套分级适合已经允许 Agent 调用 CRM、ERP、审批、消息或账号系统的企业；如果 Agent 只做检索、摘要和草稿，重点是数据权限与引用核验，不需要给每一步都加确认按钮。相反，把所有动作都塞进同一个“请确认”弹窗，会让员工形成机械点击，人审很快失去意义。
用 5 个维度判断是否人审
| 维度 | 低风险信号 | 必须人工确认的信号 |
|---|---|---|
| 可逆性 | 可一键撤回，且不会触发下游动作 | 删除、发布、生效后难以恢复 |
| 资金与库存 | 只读或生成核对清单 | 付款、退款、改价、库存释放或占用 |
| 对外承诺 | 内部草稿、内部提醒 | 向客户或供应商发出交期、价格、赔付、责任表述 |
| 权限变化 | 查询本人已有权限 | 提权、授权他人、创建高权账号、导出敏感数据 |
| 影响范围 | 单对象、低影响、可回读 | 批量对象、跨部门、跨组织或影响生产运行 |
只要任一列落入右侧，就不应让 Agent 自行放行。数据冲突、证据缺失或目标对象不唯一时，即使动作看起来可逆，也应升级给人判断。
四级动作分层
| 级别 | 典型动作 | 默认策略 |
|---|---|---|
| L0 只读与草稿 | 查订单、整理差异、拟回复 | 自动执行，保留来源与日志 |
| L1 低影响可逆 | 创建内部待办、补充非关键备注 | 可自动执行，限定对象和字段，写后回读 |
| L2 受控业务写入 | 修改下一步日期、更新项目普通状态 | 按角色和场景配置确认；批量时强制确认 |
| L3 高风险动作 | 付款、改价、库存放行、对外发送、权限提升、删除 | 有权人确认；必要时双人或专业岗位复核 |
分层不是按系统名称。CRM 里追加一条内部备注可能是 L1，修改客户负责人可能是 L2，修改合同金额就是 L3；同一个系统里也有不同风险。
人审卡片要让人真正能判断
一张合格的确认卡片至少要显示：
- 谁发起、Agent 准备执行什么；
- 目标对象的稳定 ID、名称和所属组织；
- 修改前值、拟修改值、证据来源与规则版本；
- 影响范围、可能触发的下游动作、能否回滚；
- 授权有效期，以及拒绝、退回补证、转专业人三种出口。
只展示一句“Agent 建议执行，是否同意”，并不叫人审。审批人无法看到对象和影响，只能盲点。对于批量动作，还要展示总对象数、抽样明细和异常清单，不能把一百个不同风险的动作压成一次确认。
例如销售 Agent 准备给客户发送交期变更。它可以自动整理订单、库存和项目证据，也可以生成话术；但销售负责人要确认新日期和对外表述。确认后，Agent 还要重新校验订单版本是否变化，再发送并检查消息回执与 CRM 记录。人点了同意只是授权终点，不是业务终态。
三种常见错误
第一，把模型置信度当授权。模型可以判断自己是否缺信息，但无论分数多高，都不能因此获得付款或提权资格。
第二，把人审放在动作之后。先发消息再让人“追认”，对外承诺已经发生；先释放库存再审批，也已经影响履约。高风险确认必须位于执行前。
第三，批准后不复核上下文。人审排队期间，对象版本、金额或负责人可能变化。执行前必须检查批准所依据的对象版本仍然有效，变化则让批准失效并重新确认。
权限本身还要经过确定性校验，具体可看企业 Agent 权限三重校验；执行完成后则按写后回读 6 步核对真实终态。准备落地时，可从AI 落地五项工程把角色、风险级别、确认人和回读路径一起设计，避免最后只补一个形式化弹窗。
