human-in-the-loop

人工参与决策

在能够改变风险的决策节点引入人工判断。仅有确认对话框并不构成监督：应将经授权的决策绑定到易于理解且不可更改的操作，并保留事件证据。

输入

收集或推断以下信息，并标明假设：

• Agent 目标、工作流状态，以及它可以提出或执行的每项操作
• 影响类型、可逆性、价值、受影响人员，以及最严重的可信影响
• 数据敏感性、监管或合同义务，以及组织的风险容忍度
• 请求者和审批者稳定的主体身份、角色分配、策略所有者、职责分离规则，以及值守时段
• 所需响应时间、超时行为、升级联系人，以及可用性目标
• 审批者所需的证据，包括来源、确定性和备选方案
• 现有的身份、策略、审计、工单和通知系统
• 故障、重试、取消、补偿和事件处理路径

不得臆造审批权限或组织策略。如果缺失的信息会影响重要操作，应提出一项策略草案，并标记为待所有者批准。

输出约定

交付以下内容：

1. 操作清单，以及每项操作基于理由确定的风险等级
2. 闸门策略，定义经过验证的谓词、符合条件的审批者角色和不同主体、法定人数、证据、有效期、超时、结构化升级、审计中断时的行为、执行时重新授权、补偿、紧急放行和职责分离
3. 覆盖准备、审核、决策、执行、故障和恢复的状态机
4. 审批体验，展示确切操作、实质影响、不确定性、来源、备选方案，以及安全的拒绝／编辑路径
5. 仅追加的决策记录架构，以及保留／脱敏要求
6. 实现方案或文件级计划，以及策略和并发测试
7. 验证证据、未决策略决策、剩余风险和运营恢复计划

如果机器可读策略有帮助，请从 assets/approval-policy-template.json 开始。使用 scripts/validate_gate_policy.py 对其进行验证。风险等级和状态机的设计指南请参阅 references/gate-design-guide.md。

工作流

1. 列出决策和影响

列出每项 Agent 操作及其影响对象。将起草、预览、建议和读取，与提交、发送、发布、购买、删除、授予访问权限、执行代码或作出高影响决策区分开来。

记录可逆性、规模、敏感性、外部可见性、财务价值、时间压力、受影响的权利，以及错误操作是否可以控制。

2. 选择足以应对风险的最轻监督方式

针对每种风险选择一种控制方式：

• 自主执行并审计： 范围受限、可逆且影响较小的操作
• 操作后通知： 影响较小且及时知情即可的操作
• 操作前审核： 后果重大或对外可见的操作
• 提升审批等级： 价值、敏感性、置信度、异常程度或范围超过阈值时
• 双人控制： 关键、不可逆、权限较高或受监管的操作；默认要求至少两名不同的审批主体
• 禁止： 超出策略范围或无法确保足够安全的操作

不要对每个琐碎步骤都设置闸门；过多的提示会让用户养成不经思考就批准的习惯。绝不要仅为满足延迟目标而移除必要闸门。默认将关键操作仅需单人控制和请求者自我审批视为无效。只有通过有时限的豁免才允许其中任一情况；豁免必须注明闸门和例外类型，包含策略所有者的稳定主体 ID 和审批参考编号，记录理由和补偿性控制措施，并由闸门明确引用。

3. 明确决策内容

向审批人展示：

• 通俗易懂的意图，以及触发审批门槛的原因
• 目标身份和规范化参数
• 变更前后差异，或拟议载荷的准确内容
• 预期影响、受影响方、成本和可逆性
• 证据来源、出处、新鲜度、不确定性和已知缺漏
• 政策依据、替代方案，以及拒绝、编辑或超时将产生的后果

隐藏机密信息，并尽量减少个人数据。确保拒绝／取消路径与批准路径同样易用。

4. 将身份和审批绑定到操作

验证审批人的身份，并独立于模型授权其角色。分别建模角色和稳定的审批人主体，避免双角色要求被悄然判定为同一人。为参与者、租户、操作、目标、重要参数、政策版本、有效期和随机数创建规范表示或摘要。审批仅适用于该不可变提案。

任何重要编辑、过期、政策变更、目标变更或相关状态变更后，都应使审批失效。适用职责分离时，禁止自我审批。不得将沉默、收到消息或先前的一般性同意视为审批。

5. 实现安全状态机

使用明确的状态转换，例如：

prepared -> pending_review -> approved | rejected | expired | cancelled

approved -> executing -> completed | failed | compensation_pending

确保状态转换具备原子性和幂等性。在执行前立即重新检查授权和前置条件。一次性审批仅能使用一次。妥善处理并发审批人、重复回调、过期界面、重试和下游部分故障。

6. 添加升级处理和恢复机制

定义机器可读的提醒、升级对象或角色、最大尝试次数、最长等待时间、达到上限后的行为，以及不在岗时的覆盖安排。默认超时后应拒绝、取消或升级，而非批准。明确审计存储不可用时是默认拒绝，还是使用短时、经签名的缓冲区；关键操作必须默认拒绝。执行前立即重新授权身份、角色、政策、提案摘要、目标状态和有效期。

将补偿定义为自动执行、手动执行、必须执行但无法执行，或不适用，并指定负责人和流程参考。将紧急授权作为独立且经过强身份验证的路径，要求至少两名指定主体、范围严格受限、有效期短、记录理由、立即告警并进行事后审查。

拒绝时，应保留提案和理由，但不得执行。执行失败时，应停止不安全的重试，标记真实状态，存在经过测试的补偿操作时调用该操作，通知负责人，并保留已脱敏的证据。

7. 验证控制措施

测试：

• 每项操作都进入预期的风险级别和审批门槛
• 拒绝未授权、租户不匹配和自我审批的参与者
• 参数、目标、状态、政策或有效期变更后，审批失效
• 重复审批和回调不会导致重复执行
• 拒绝、编辑、取消、超时、升级和审批人不可用等路径
• 并发决策下的法定人数、不同主体、自我审批、负责人豁免和职责分离行为
• 执行时重新授权以及前置条件变更
• 升级次数用尽、审计存储故障、部分故障、补偿、紧急授权和事件通知
• 决策记录包含所需证据，但不包含机密信息
• 代表性审批人的可用性，包括理解程度和错误率

报告命令、模拟过程和观察结果。未实际验证政策逻辑和审批体验时，不得声称人工审查有效。

授权与安全边界

• 设计关卡并不代表已获授权执行相关操作；除非另行获得授权，否则不得执行、发送、发布、部署、购买、删除或授予访问权限。
• 绝不允许模型伪造、冒充或推断人工审批。
• 在模型生成的文本之外强制执行身份验证、授权、法定人数要求和审批绑定。
• 不得向审批者、日志、通知或测试固件暴露机密或不必要的个人数据。
• 对于高风险操作，如果缺少身份信息、条件谓词含糊或格式错误、状态已过期、审批或豁免已失效、租户错误、法定人数无效、不同主体数量不足，或审计存储不可用，则应默认拒绝。
• 避免暗黑模式、预先选中审批、紧迫感操纵，以及掩盖实质不同操作的捆绑。
• 不得利用人工审核为歧视性、违法或其他禁止的决策背书。

真实示例

退款 Agent

仅对已验证的重复扣款，允许自主退款低于 50 美元的款项。超过 50 美元须由支持经理审批；超过 1,000 美元须由财务和支持部门共同审批。展示订单历史、政策依据、金额、收款去向和欺诈信号。将审批绑定到订单、金额、收款去向和政策版本；测试重复扣款、付款去向变更、超时以及处理器部分故障。

通信 Agent

允许 Agent 起草客户更新内容，但须由账户负责人审批确切的收件人、主题、正文摘要、附件和发送时间。任何编辑都会使审批失效。被拒绝的草稿应返回编辑状态；已过期的审批不得发送。记录审批决定，但不要将附件内容存入决定日志。

完成检查

仅当每项会产生重大后果的操作都有成文政策、条件谓词经过结构化验证、审批者角色对应到足够数量的不同主体、除非存在有效且经负责人批准的豁免，否则拒绝由单一关键控制者审批或自我审批、审批无法重放或在不知情的情况下扩大适用范围、升级处理／审计中断／重新授权／补偿／紧急访问路径均有效，并且审计轨迹与剩余风险均有明确说明时，才算完成。