Human-in-the-loop 流程让智能体在明确的决策点暂停，向有权处理的人展示拟执行操作与相关证据，得到授权决定后才继续。对交付物的验收，应与发送、发布、花钱、删除或部署的操作授权分开。
选定真正需要控制的决策点
从具体操作开始，例如发送客户报告。智能体可在权限范围内调研和起草，但外部发送必须等待。明确谁能批准，拒绝或长期未回复时怎样处理。发送后的聊天通知是审计事件，不是事前审批。
审核阶段也可防止任务在交付物未验收前关闭。这很有用，但并不会自动阻止邮件工具提前发送草稿。应在实际需要控制的操作处设置边界。
展示足以让人判断的具体请求
在报告示例中，提供收件人、最终主题与正文、附件版本、客户、来源任务，以及为什么需要发送。链接审核者需要的证据，不要在消息尚未完成时只问“可以给客户发邮件吗”。
| 审批字段 | 请求示例 |
|---|---|
| 操作 | 发送已审核的每周报告 |
| 目标 | 与任务核对后的指定客户联系人 |
| 内容 | 最终消息和关联的报告版本 |
| 范围 | 该客户及报告项目 |
| 决定 | 仅批准本次请求，或拒绝并说明原因 |
收件人、正文或附件发生变化时，应视为新的提案，不要将旧批准悄悄用于另一项操作。
在工具调用之前执行检查
审批流程需要管理层与执行方配合。运行时必须在外部操作前停下，通过审批机制提出请求，并且只执行已批准的操作。如果一边授予无限制凭据，一边只是要求它“小心”，技术边界仍然不同。
EmperorClaw 的操作设置支持关闭、先询问和允许，采用公司默认值并可按智能体覆盖。受管控的 Emperor API 写操作由服务器检查。外部邮件、shell 等运行时工具需要先调用 check_action。Emperor 无法拦截其 API 之外的任意工具调用。
发送邮件、发布内容、花钱、删除和部署默认先询问；浏览网页和 shell 命令默认允许。应结合每个执行智能体实际持有的工具访问权和凭据检查这些默认值。
把拒绝与等待当成正常状态
审核者拒绝报告后，保留请求和原因，将所需修改写入任务，并交回负责人。下次操作提案应反映修订内容。如果仍在等待审批，应明确显示等待状态，而不是持续运行昂贵的循环反复询问同一问题。
明确人员缺席和决策停滞时的处理方式。这不等于让每个智能体都能批准自己的工作。组织架构中的主管也不会自动获得全部客户记录的访问权。
面向客户使用前，先验证审批流程
- 用完整参数提出一项无害的测试操作。
- 确认等待审批期间没有执行。
- 拒绝请求，确认仍未执行。
- 批准一项新请求，确认只执行一次。
- 修改一个参数，确认旧决定未被复用。
- 重启或断开运行时，检查待处理工作的恢复方式。
使用测试目标和尽可能小的权限。发送结果不确定时，先调查外部系统再重试。审批记录正确，并不证明第三方服务已经完成操作。
常见问题
每项操作都应该要求批准吗？
选择需要判断或授权的决策点。对每次低影响读取都要求审核，可能消耗处理关键操作所需的注意力。策略应匹配工作流和运行时权限。
审批能替代沙盒吗？
不能。审批是决策机制；文件系统、网络、凭据和工具限制决定运行时在技术上能接触什么。
关闭审批历史会停止审批吗？
在 EmperorClaw 中，关闭审批历史模块只隐藏该历史页面，操作请求和项目验收仍会进入收件箱。
配置第一个受控交接
选择一个智能体和一项外部操作，检查其范围与操作设置，起草完整请求，并在批准前先测试拒绝路径。交付物本身需要签字验收时，再增加任务完成审核。
配置方法见 EmperorClaw 操作权限与周期自动化中的审批关卡。