审批不变量批准必须绑定一个可识别动作、最终参数、资源版本、策略版本、批准者与有效期。任何变化都需要重新校验;审批界面从不替代服务端授权。

一个行动视图必须回答六件事

行动卡先用业务语言说清“做什么、作用于谁、为什么现在做”,再说明副作用、费用、可逆性、验证方式、批准者和到期时间。Tool 名称和原始 JSON 可以折叠保留用于诊断,但不能成为高风险审核的主要界面。

“发送邮件”不足以审核,至少需要收件人、主题、正文摘要、附件和身份;“执行 SQL”需要目标环境、读写类别、影响行估计与回滚。理由来自当前计划与证据,不能只显示模型自由文本。若系统无法计算影响或撤销路径,应明确标为未知并提高摩擦或拒绝执行。

Tool 状态不能压缩成 Loading/Done

proposed、validating、needs-approval、queued、running对应不同责任主体;succeeded、failed、unknown、cancelled、compensated也不是同一种结束。按钮由状态与权限派生:待审批可修改或拒绝,运行中可能只能请求取消,未知结果只能先查询或对账。

OpenAI Agents SDK 的当前 HITL 文档说明需要审批时 Run 会暂停并返回 interruption,用户决定后用同一 RunState 恢复。这是运行时事实示例,不代表 UI 可以把 interruption 直接展示为一个无上下文按钮。序列化状态也包含应用 Context,持久化前要排除秘密。

行动从提议到可验证终态
提议与校验Schema、权限、策略、对象版本。
审批绑定参数摘要、批准者、期限与哈希。
执行或补偿幂等键、回执和未知终态处理。
业务验证后置条件、审计与可恢复入口。

风险决定信息密度和确认摩擦

风险来自可逆性、影响范围、敏感数据、费用、外部可见性与权限提升,而不是 Tool 名字。MCP 官方对 Tool Annotations 的说明强调 readOnlyHint、destructiveHint等只是服务端提示;不可信 Server 上不能把它们当授权事实,产品要结合身份、参数与业务策略重新分类。

低风险只读

允许内联执行或以轻量状态展示,参数可折叠,但要保留数据来源和越权失败。读取也可能泄露敏感信息或产生费用,所以“只读”不等于“无风险”。

可逆写入

展示变更前后 Diff、影响对象、单次确认与明确撤销时限。撤销只是另一项业务动作,若存在并发修改或外部通知,不能承诺完整回滚。

不可逆/敏感

把关键参数从摘要中突出,展示总影响、受益人与责任主体,采用强确认、Step-up Authentication 或职责分离。高风险批量动作默认拆开审批;无法可靠预估影响时暂停并升级人工。

允许修改,但修改会产生新意图

按 Tool Schema 渲染字段、类型、单位、枚举和业务校验。用户改收件人、金额或目标环境后,旧策略决定和审批全部失效;系统生成规范化参数、重新校验权限与风险,并将批准绑定最终参数哈希和对象版本。

不要让用户在无说明 JSON 中审核高风险动作,也不要把可编辑表单直接等同于 Tool 请求。字段显示值可能经过格式化,提交前要回显规范值;对敏感字段做最小展示,并在审计中存摘要或安全引用,而非复制秘密。

批量审批要防止审批疲劳

只有同风险、同策略、同可逆性且用户能理解共同影响的动作才可合并。批量卡展示总数量、总费用/影响、分组规则和异常项,允许逐项展开、排除、修改。默认选择不能诱导“全部同意”,高风险差异不能藏在折叠区。

审批疲劳的信号包括极短阅读时间、连续全批通过、事后频繁撤销和异常项漏检。治理措施是减少不必要审批、提高预览质量、用规则自动批准已证明的低风险动作,而不是让高风险确认更快。规则化批准仍需范围、期限和撤销。

等待期间现实会变化

审批请求携带资源版本、策略版本和 expiresAt。提交时服务端再次检查身份、权限、对象版本与参数哈希;对象被他人修改、权限撤销、Run 取消或策略升级时,旧审批失效并重新生成预览。

并发批准使用一次性 decision token 或 Compare-and-Set,保证只有一个合法决定。客户端收到“已由他人处理”后刷新事实,不能本地覆盖。长时间暂停应持久化 RunState,但恢复的是候选行动,不是绕过重新授权的通行证。

结果视图连接意图、执行与证据

结果卡把最初意图、最终参数、批准者与时间、策略版本、幂等键、Tool 回执、业务后置条件和补偿记录关联起来。succeeded表示 Tool 协议成功仍不够,例如“API 返回 200”不证明邮件被目标系统接受或付款已对账。

审批故障与验证证据
故障安全行为证据
审批后对象版本变化拒绝执行并重建 Diff版本冲突测试
执行超时但外部可能成功进入 unknown,先对账回执查询与幂等记录
两个审批者同时提交仅一个 decision token 生效并发提交测试
补偿失败保留原效果并升级人工补偿 Runbook 与审计

可用性测试不仅问“信息清楚吗”,还注入错误收件人、相近对象、过期价格和不可逆批量操作,统计误批、正确拒绝、修改成功、发现异常所需时间。最终审计必须能从业务结果回到批准上下文。

主动提取:用户只改了一个参数,为什么必须重新审批?
批准绑定的是具体行动意图。参数决定资源、影响与风险;修改后旧策略判断和参数哈希不再对应将执行的动作。
故障判断:Tool 超时后应该显示“失败”并允许重试吗?
不应直接这样做。超时可能是结果未知,外部副作用可能已发生;先用幂等键或业务回执对账,再决定继续、补偿或重试。

资料与事实边界

以下以官方文档、标准、论文和原始工程资料为主。厂商 API、价格、限额与模型能力会变化,落地时仍需按目标版本做能力探测和回归。

  1. OpenAI Agents SDK:Human-in-the-loop — interruption、审批、拒绝、序列化与恢复的当前官方语义
  2. OpenAI Agents SDK:Tool guardrails — Tool 输入/输出 Guardrail 与审批先后边界
  3. MCP:Tool Annotations as Risk Vocabulary — readOnly、destructive、idempotent 与 open-world 提示的非权威边界
  4. NIST SP 800-63B — 高风险动作的认证与会话保证参考