跳到主要内容

Approval 与 Human Review Workflow

很多 Agent 系统出问题，不在推理阶段，而在动作执行阶段。

系统一旦开始：

  • 发邮件
  • 改数据
  • 执行 SQL
  • 提交工单
  • 调用外部支付或审批接口

很快就会碰到一个问题：

哪些动作可以自动执行，哪些动作必须停下来给人看一眼。

这里讨论的就是这一层。

1. Approval 不是“多加一步确认”​

Approval workflow 的作用，不只是弹一个确认框。

更准确地说，它要解决这些问题：

  • 哪些动作需要人工介入
  • 人工介入发生在动作前还是动作后
  • 审批人看到什么上下文才够判断
  • 审批后的结果怎样重新回到运行链里
  • 被拒绝、修改、超时之后系统怎样继续

如果这些边界不清楚，人审通常只剩一个形式。

2. 哪些动作通常应该进入审批流​

常见的高风险动作包括：

  • 写操作
  • 删除操作
  • 对外发送消息
  • 财务相关操作
  • 法务、合规、权限变更
  • 会影响客户、订单、合同、库存的动作

一个实用原则是：

能造成真实外部后果的动作，默认先考虑审批。

3. 审批流里最核心的三个判断​

3.1 这一步是否可逆​

如果动作不可逆，审批门槛通常会更高。

例如：

  • 发出的外部邮件
  • 已执行的转账
  • 已删除的数据
  • 已提交到第三方系统的结果

3.2 这一步是否超出当前权限边界​

有些动作本身不危险，但一旦跨权限边界，就应该停下来。

例如：

  • 访问敏感客户记录
  • 批量导出数据
  • 代表组织对外发言
  • 触发生产环境变更

3.3 这一步是否需要业务判断​

有些动作不是技术风险，而是业务责任问题。

例如：

  • 是否真的应该给客户退款
  • 是否要升级工单优先级
  • 是否接受某个采购方案

这种情况下，审批不是为了拦模型，而是为了保留业务决策权。

4. 一个最小审批流长什么样​

这条链里最关键的，不是“有没有审批”，而是审批点前后都要有清楚的状态转换。

5. 审批流里，人到底要看什么​

审批人不需要看全部上下文，但至少要看到这些内容：

  • 动作名称
  • 关键参数
  • 目标对象
  • 为什么要做这件事
  • 这一步来自哪段推理或哪条规则
  • 可能的影响范围
  • 是否可回滚

如果审批界面只显示“是否确认执行”，那通常不足以做出可靠判断。

6. 三种常见审批结果​

6.1 approve​

动作按原参数执行。

适合：

  • 低争议动作
  • 参数已经足够清楚
  • 风险主要在权限，而不在业务判断

6.2 edit​

审批人修改参数，再让系统继续。

适合：

  • 目标方向对，但细节需要修正
  • 需要调整金额、收件人、SQL 条件、时间范围等

6.3 reject​

动作不执行，并给出原因。

适合：

  • 当前计划不成立
  • 风险不可接受
  • 条件不足，需要补信息

很多系统最容易漏掉的是 edit。但在真实业务里，这一类情况往往比简单 approve / reject 更常见。

7. 审批流最容易被做坏的地方​

7.1 只给动作名，不给上下文​

审批人不知道系统为什么要这样做，结果只能机械地点通过或拒绝。

7.2 审批点太多​

如果低风险动作也频繁打断，审批流很快会退化成“全部直接点通过”。

7.3 审批点太晚​

如果系统已经执行了一半，审批的价值会明显下降。

7.4 被拒绝后没有清楚分支​

被拒绝之后，系统可能需要：

  • 结束流程
  • 回到上一步重新规划
  • 请求补充信息
  • 转人工接管

没有这些分支，审批流就只是一个死胡同。

8. 哪些系统更适合把审批做成 workflow 节点​

更适合显式 workflow 节点的情况包括：

  • 业务流程天然有审批环节
  • 审批可能跨人、跨角色、跨时间
  • 需要 checkpoint / resume
  • 需要审计与追踪

这类情况下，审批流本身就是系统流程的一部分，不只是某个 guardrail 附件。

9. 哪些系统更适合把审批做成 tool policy​

更适合作为 tool policy 的情况包括：

  • 审批逻辑集中在少数高风险工具上
  • 主流程本身并不复杂
  • 需要根据工具类型决定是否停下

这类模式在 Agent SDK 或 LangGraph 的中断机制里都不少见。

10. 审批流和 Guardrails 的关系​

两者有关，但不是一回事。

  • guardrails 更偏规则边界和运行限制
  • approval workflow 更偏责任转交和人工决策

也可以直接这样看：

  • guardrails 负责先拦
  • approval 负责决定是否继续

11. 审批流和 Human Review 的区别​

很多时候这两个词会一起出现，但关注点不同。

  • approval 更强调是否允许动作继续发生
  • human review 更强调人工检查、修改、补充或接管

因此一个流程可以：

  • 只有 approval
  • 只有 review
  • 或两者同时存在

例如：

  • 发邮件前需要 approval
  • 报告生成后需要 human review
  • 合同草稿需要 review，正式发送前还要 approval

12. 第一版最需要定清楚的 5 件事​

  1. 哪些工具或动作必须审批
  2. 审批人看到哪些上下文
  3. 批准、修改、拒绝分别怎样落回流程
  4. 超时、无人处理时系统怎样降级
  5. 审批记录是否进入 trace、审计和回归样本

这五件事定清楚，第一版审批流通常就能落地。

13. 和哪些文档一起看最顺​

14. 小结​

审批流要解决的，不是“多一次确认”，而是把高风险动作放回责任边界里：

  • 哪一步要停
  • 谁来决定
  • 看什么做决定
  • 决定之后系统怎样继续

这条链路越清楚，Agent 系统越容易稳定上线。