Wiki Notes

Appearance

审批与人机协同模式专题 ​

版本：v1.1

最后更新：2026-07-07

很多团队做 Agent 的第一阶段，都想追求更高自动化；第二阶段就会开始补审批；第三阶段才真正意识到，审批不是在流程里插一个按钮，而是要把模型建议、工具动作、风险分层、责任归属和恢复路径一起设计清楚。

真正成熟的人机协同系统，目标不是把人塞进每个步骤，而是把人放在最值得判断、最应该担责、最能止损的位置上。

1. 为什么审批不是一个孤立功能 ​

审批真正解决的不是“点一下通过还是拒绝”，而是以下几个问题：

  • 这次动作为什么需要暂停
  • 模型建议是否足够可信
  • 谁应该做最终判断
  • 审批前必须展示哪些证据
  • 审批通过后流程怎么继续
  • 审批拒绝、超时或冲突后如何收束

如果这些问题没有一起设计，审批就会退化成：

  • 一个缺少上下文的确认框
  • 一个所有人都嫌慢、但没人敢删的中间页

2. 为什么 Agent 场景更需要人机协同 ​

传统系统里的审批，大多围绕固定操作和固定字段。Agent 系统则多了三层不确定性：

  • 模型会动态选择动作，而不是固定按钮流
  • 工具调用参数是推理结果的一部分，不一定稳定
  • 多步流程会把一个小判断放大成真实世界后果

因此很多“看起来只是工具调用”的动作，实际风险很高，例如：

  • 给客户发送外部消息
  • 导出高敏感数据
  • 修改价格、额度、退款金额
  • 触发删除、撤销、权限变更
  • 把高风险内容交给外部系统继续执行

这些场景里，审批不是效率损耗，而是系统边界。

3. 人机协同最常见的四种模式 ​

3.1 Draft then approve ​

AI 先起草，人做最终确认。

适合：

  • 邮件草稿
  • 对外公告
  • 合同摘要
  • 风险说明

核心价值：

  • 把 AI 放在生成和整理位置
  • 把人放在最终责任位置

3.2 AI triage, human decide ​

AI 负责分类、优先级判断、线索聚合，人来做最终决策。

适合：

  • 客服升级
  • 法务分诊
  • 退款初审
  • 风险案件路由

核心价值：

  • 缩短人工理解上下文的时间
  • 但不把拍板权交给模型

3.3 Human on exception ​

低风险自动通过，高风险、异常或不确定样本才转人工。

适合：

  • 高流量、规则较稳定的业务
  • 有明确风险阈值和熔断条件的动作

核心价值：

  • 兼顾吞吐和控制
  • 避免把所有请求都拉进审批队列

3.4 Human takeover ​

系统不只是等待批准，而是正式把流程接管给人工。

适合：

  • 自动恢复失败
  • 多次重试无果
  • 外部状态不一致
  • 高风险动作证据不足

核心价值：

  • 从“审批一步”升级为“人工处置一个 case”

4. 哪些动作应该优先纳入审批 ​

建议优先给这些动作设计审批门：

  • 对外发送消息、邮件、通知
  • 导出、分享、下载高敏数据
  • 删除、撤销、注销、冻结
  • 调整价格、额度、退款、合同条款
  • 跨租户或跨系统写操作
  • 调用高风险工具，例如生产变更、权限修改、支付相关动作

判断标准一般不是“这个动作看起来大不大”，而是看：

  • 是否影响真实世界
  • 是否可能越权
  • 是否难以回滚
  • 是否会带来合规、财务或品牌风险

5. 建议把审批触发条件结构化 ​

审批不应该只有一个布尔值。更稳妥的做法是显式维护触发维度：

维度典型字段
动作类型send_email、export_data、refund、grant_permission
风险等级low、medium、high、critical
数据敏感性是否涉及 PII、财务、法务、客户机密
金额或影响范围退款金额、受影响客户数、受影响系统数
模型置信或不确定性低置信、高分歧、证据不足
用户或租户等级VIP、企业客户、受监管行业
当前系统状态灰度中、告警中、值班中、事故期间

这样审批逻辑才不至于变成一堆散落在业务代码里的 if。

6. 一份审批对象至少要长什么样 ​

审批如果想可恢复、可审计、可复盘，就需要把“待审批项”设计成独立对象，而不是临时页面状态。

建议至少包含这些字段：

字段说明
approval_id审批单唯一标识
task_id / run_id关联到哪个 Agent 任务和执行实例
action_type待执行动作类型
risk_level当前风险等级
requested_by哪个 Agent、工具或用户触发
proposed_action模型建议执行的动作摘要
arguments结构化参数，避免只看自然语言
evidence_refs证据引用，如 trace、上下文、样例、知识来源
deadline_at审批超时点
decisionapproved、rejected、expired、cancelled
decision_by审批人
decision_reason通过或拒绝理由
resume_policy通过后如何恢复执行

有了这个对象，系统才有可能把审批从一次性 UI 交互变成可治理资产。

7. 审批一定要和状态机绑定 ​

审批本质上会把工作流切成多个明确状态。一个最小状态流通常包括：

text
running
 -> approval_requested
 -> awaiting_approval
 -> approved / rejected / expired / cancelled
 -> resume_execution / terminate / escalate

更复杂的系统还会增加：

  • awaiting_second_approval
  • awaiting_business_review
  • manual_takeover
  • compensating

如果没有明确状态，最常见的问题就是：

  • 审批通过了，但流程没恢复
  • 流程恢复了，但找不到审批记录
  • 审批超时了，却没有默认处理路径

8. 审批界面真正需要展示什么 ​

审批体验不是“把 JSON 打印给审批人看”。审批人需要的是最短时间内完成可靠判断。

建议至少展示这些信息：

  • 当前待执行动作是什么
  • 为什么会触发审批
  • 风险标签命中了哪些规则
  • 相关用户、租户、金额、数据范围
  • 模型建议与置信说明
  • 关键证据，如引用内容、历史案例、trace 片段
  • 通过后的效果和拒绝后的效果
  • 是否存在更保守的替代动作

好的审批页应该让审批人能回答一句话：

  • 我现在到底在批准什么，放行之后会发生什么

9. 超时、升级和轮值不能缺 ​

很多团队只设计“通过”和“拒绝”，但真实世界里更常见的是：

  • 审批人没看到
  • 审批人不在线
  • 审批人不确定该不该过
  • 多个审批人互相等待

因此建议提前定义：

  • 审批 SLA，例如 5 分钟、30 分钟、4 小时
  • 超时后是自动拒绝、自动降级还是升级到下一层角色
  • 夜间、节假日和值班场景的替代审批人
  • 同一类动作是否允许双人审批

尤其在高风险场景里，不要让“没人处理”变成隐形默认通过。

10. 审批通过后如何恢复执行 ​

审批只是暂停点，不是终点。通过后建议明确以下恢复契约：

  • 恢复到哪个 step_id
  • 原始参数是否允许被审批人修改
  • 审批结果是否需要重新校验
  • 恢复后是否需要重新获取最新上下文
  • 如果恢复失败，是否直接转人工接管

更稳妥的方式通常是：

  • 保留审批前快照
  • 记录审批后实际执行参数
  • 记录恢复开始、恢复成功和恢复失败事件

这样后面才能对账和复盘。

11. 审批拒绝后不能只写“结束” ​

拒绝以后通常至少有三条后继路径：

11.1 终止 ​

适合动作本身不应继续，例如高风险导出被拒绝。

11.2 降级重试 ​

适合把外部发送改成草稿，把自动写操作改成人工工单。

11.3 转人工处理 ​

适合模型方案不可靠，但业务仍需要继续完成。

如果系统不区分这三类，就容易把所有拒绝都处理成“流程失败”，既影响体验，也损失业务连续性。

12. Agent 最适合承担哪些审批前工作 ​

AI 在审批链路里最有价值的通常不是替人拍板，而是替人降理解成本。常见价值点包括：

  • 提炼上下文
  • 对历史对话做摘要
  • 把证据整理成结构化卡片
  • 标注风险规则命中点
  • 生成可选处理方案
  • 说明通过、拒绝、降级三种后果

这类协同模式的收益很高，因为它把人类注意力从“搜集材料”转向“做判断”。

13. 把审批策略做成可配置资产，而不是散落 if ​

很多团队的审批规则最开始都是这样长出来的：

  • 某个接口里加一个金额阈值
  • 某个工具前再补一个敏感词判断
  • 某个租户单独写一条例外逻辑

短期能跑，长期一定会越来越难解释、难排查、难回滚。

更稳妥的方式，是把审批策略单独建模成可配置对象，例如：

字段作用
policy_id策略唯一标识
policy_version当前生效版本
action_scope约束到哪些动作
risk_conditions风险命中条件
approval_level单人审批、双人审批、业务复核
fallback_on_timeout超时后的默认动作
override_roles允许越级处理的角色
effective_window生效时间窗

这样做的价值有三点：

  1. 审批规则能单独评测和灰度。
  2. 审批事故发生后可以直接定位是哪一版策略在起作用。
  3. 审批策略可以和 Prompt、模型、工具 schema 一起组成发布单元。

根据 OpenAI Guardrails and human review 文档在 2026-07-07 可访问的说明，guardrails 负责自动校验，human review 负责批准或拒绝敏感动作。放到工程实现里，最稳的边界就是把“自动校验”和“人工决策”分别建模，而不是混成一个黑盒判断。

14. 审批前要给人的是证据包，不是模型结论 ​

审批页里最危险的设计，是只展示一句：

  • 建议通过，风险较低

这不是证据，只是另一个待审批对象。

更适合交给审批人的应该是一份 evidence package，至少包含：

  • 原始用户请求或原始事件
  • 模型建议动作
  • 结构化参数
  • 风险命中规则
  • 相关外部对象，如订单、工单、客户、金额
  • 关键证据片段和来源
  • 通过、拒绝、降级三种后果

如果是写操作，最好额外给出：

  • 执行前对象状态
  • 执行后预期变化
  • 审批人实际改过哪些参数

也就是把审批做成接近 pre-execution diff 的体验。

根据 OpenAI Guardrails and human review 文档在 2026-07-07 可访问的说明，human review 适合放在 cancellation、edits、shell commands 和敏感 MCP actions 这类副作用动作之前。对这类动作来说，审批人真正要判断的是“这次改动会对外部世界造成什么变化”，而不是“模型话术听起来像不像有道理”。

15. 审批动作最好不止“通过/拒绝”两种 ​

真实业务里的审批，很多时候不是简单二选一。

更实用的审批动作通常至少包括：

  • approve：按原方案执行
  • approve_with_edits：允许审批人修改参数后执行
  • reject：拒绝当前方案
  • reroute：改派给另一角色或另一队列
  • escalate：升级到更高权限审批人
  • takeover：直接转人工接管后续流程

如果系统只支持“通过/拒绝”，最常见的问题就是：

  • 审批人其实只想改一个字段，却被迫整体拒绝
  • 审批人判断当前自己不该拍板，却没有升级路径
  • 审批人知道要继续做，但系统只能终止

更稳的做法是把审批动作本身也做成结构化契约，例如：

json
{
  "decision": "approve_with_edits",
  "edited_arguments": {
    "refund_amount": 188.00
  },
  "reason": "超过默认建议金额，按订单证据调整",
  "next_owner": "refund-ops-l2"
}

这会直接影响恢复路径、审计记录和后续工具执行参数，所以审批动作本身不能只存在于一段说明文字里。

16. 多个待审批动作要支持分组、去重和拆分处理 ​

生产系统里经常不是“一个任务只触发一个审批”，而是：

  • 一个 case 里连续触发多个高风险动作
  • 多个相同动作由不同子任务重复提出
  • 一个大任务分片后，每个分片都想创建一张审批单

如果不控制审批粒度，系统很快会出现：

  • 审批单泛滥
  • 审批人疲劳
  • 重复放行同类动作
  • 队列中挤满低价值重复项

因此建议从一开始就定义：

  • 哪些动作可以合并成一组审批
  • 哪些动作必须拆开逐项审批
  • 相同动作的去重 key 是什么
  • 同一 case 内是否允许批量放行

常见分组维度包括：

  • 同一 task_id
  • 同一租户、客户或订单
  • 同一种工具动作
  • 同一风险等级
  • 同一审批窗口期

Temporal Human-in-the-Loop 相关资料在 2026-07-07 可访问的说明里强调，人工节点本质上是 workflow 里的显式等待点。放到审批实现里，这意味着等待点越多、越碎，整体吞吐和恢复成本就越高，所以审批粒度必须主动治理。

17. 审批结果和证据要保留到足够支持复盘 ​

很多系统会保留“谁点了通过”，但不会保留“为什么当时能通过”。

这会导致后续几个关键问题全答不上来：

  • 当时审批人到底看到了哪些证据
  • 审批前模型建议和审批后实际执行参数差了多少
  • 审批时是否已经命中了已知风险规则
  • 事故发生后能不能还原那次决策现场

建议至少保留这些审计对象：

  • 原始 proposed action
  • 审批时展示的 evidence package 快照
  • 审批人修改过的字段
  • 最终实际执行参数
  • 审批结果与理由
  • 审批后的恢复和执行事件

更严格的场景里，还可以补：

  • 审批 UI 版本
  • 生效中的审批策略版本
  • 关联 trace、run_id、external_id
  • 双人审批中的一审/二审决策链

也就是把审批从“一个瞬时点击行为”提升为“一个可回放决策记录”。

18. 审批链路怎么评测 ​

审批系统不能只看通过率。建议至少从五个面向评估：

18.1 风险覆盖 ​

  • 高风险动作命中率是否足够
  • 是否存在明显漏拦截

18.2 效率 ​

  • 平均审批耗时
  • 超时比例
  • 队列堆积深度

18.3 质量 ​

  • 人工介入后是否显著降低误操作
  • 审批拒绝是否真的对应高风险样本

18.4 体验 ​

  • 审批人是否经常反馈证据不够
  • 是否经常需要跳出系统查别处信息

18.5 治理 ​

  • 审批记录是否进入审计链
  • 是否能关联到 trace、case、事故和复盘

19. 建议单独监控这些指标 ​

  • approval_trigger_rate
  • high_risk_miss_rate
  • approval_timeout_rate
  • approval_queue_depth
  • median_approval_latency
  • rejection_to_manual_rate
  • approval_after_override_rate
  • approval_evidence_missing_rate

这些指标能帮助团队判断，到底是审批规则太松、太紧，还是审批体验太差。

20. 一个企业客服 Agent 的落地例子 ​

以“客户申请退款 + 外部通知 + CRM 写回”为例，可以设计成：

  1. Agent 先判断退款类型、金额、历史异常记录。
  2. 小额低风险请求自动给出建议，但不直接外发。
  3. 超过金额阈值、命中欺诈标签或涉及高价值客户时，创建审批单。
  4. 审批页展示：
    • 原始诉求
    • 历史订单与退款记录
    • Agent 推荐动作和理由
    • 风险命中标签
    • 预计影响
  5. 通过后再执行：
    • CRM 写回
    • 退款申请提交
    • 客户通知发送
  6. 任一步失败都保留 trace、审批记录和外部对象 ID，便于恢复与对账。

这个例子里，审批不是一个按钮，而是一整段可恢复、可追责、可审计的状态链。

21. 常见反模式 ​

21.1 所有动作都审批 ​

会把系统直接拖死，审批人也会疲劳，最后高风险和低风险都被快速点过。

21.2 高风险动作不审批 ​

短期看起来效率高，长期一定会以事故形式补课。

21.3 审批页没有证据链 ​

审批人只能凭感觉放行，系统等于把风险换了个地方继续存在。

21.4 审批结果不进审计链 ​

事后既无法追责，也无法优化规则。

21.5 审批和权限模型脱节 ​

系统允许“任何能看到审批单的人都能批准”，这会直接打穿治理边界。

22. 推荐搭配阅读 ​

23. 重点官方资源 ​

以下资源是本次补写时重点参考的官方资料，适合继续补强审批门、人工复核、工作流恢复和治理边界设计：

24. 落地检查清单 ​

  • 是否明确定义了哪些动作必须审批、哪些动作允许自动通过
  • 是否将审批单设计为独立对象，而不是临时页面状态
  • 是否为审批定义了 approval_requested、awaiting_approval、approved、rejected、expired 等状态
  • 是否为审批超时、夜间值班、升级和替代审批人定义了规则
  • 是否在审批页展示了足够证据，而不只是一句模型建议
  • 是否支持 approve_with_edits、escalate、takeover 这类中间决策，而不只有通过/拒绝
  • 是否为重复动作定义了审批分组和去重规则，避免审批单泛滥
  • 是否把审批规则做成可版本化、可灰度、可回滚的策略资产
  • 是否记录了审批后的恢复动作、最终执行参数和审计事件
  • 是否能通过指标看见审批规则过松、过紧还是体验过差