审批与接管

一句话理解：好的审批不是弹一个“确定吗？”，而是用最少的打扰让人看清“要做什么、影响谁、依据是什么、能不能撤回”，并允许批准、修改后执行、拒绝或亲自接手。

Human-in-the-loop 一课从安全角度讲了“哪些操作需要人确认”，操作分级讲了如何划定风险等级。这一课关注另一个同样重要的问题：审批的交互怎么设计，才能真正起到把关作用？

一个设计糟糕的审批流程，会在两个方向上失败。一种是用户根本看不懂要批准什么，弹窗写着“Agent 请求调用 send_email 工具，是否允许？”，用户只能凭感觉点“允许”。另一种是审批太频繁，客服主管一天要点 200 次“批准”，很快就变成不看内容的机械动作。这两种情况下，审批都只剩下形式，风险并没有被人真正审查。

一张好的审批卡片

对比两个审批请求：

差的审批：
  Agent 请求执行 send_email(to="wang***@example.com", template="DELAY_02")
  [允许]  [拒绝]

好的审批：
  ⚠ 需要你批准：向客户发送订单延迟说明邮件

  发送给   王女士 wang***@example.com（订单 A1024 的下单人）
  内容     您好，您的订单 A1024 因审核排队延迟处理，预计 3 月 14 日前完成。
           给您带来不便深表歉意。                                 [编辑内容]
  为什么   订单已在审核队列停留 41 小时；系统已发布延迟公告       [查看依据]
  影响     1 位客户 · 1 封邮件
  可撤回   否，邮件发出后无法撤回
  风险     低（使用已审核的通知模板，内容无承诺赔偿）

  [批准并发送]  [修改后发送]  [拒绝并说明原因]  [我来处理]
  □ 本任务中，同一模板的延迟说明邮件不再逐条确认

把好的审批卡片拆开看（图 1），每一行都对应审批人的一个问题：

图 1 · 审批卡片的解剖：每一行回答审批人的一个问题

好的审批卡片回答了审批人需要的全部问题：

要素	回答的问题	缺失的后果
动作（用业务语言）	要做什么？	用户看不懂工具名和参数
对象与范围	影响谁、影响多少？	批准了一个其实会发给 500 人的操作
预览	具体内容是什么？	发出去才发现措辞有问题
依据	为什么要做？	无法判断是否必要，见证据与可解释
可逆性	做错了能不能撤回？	对不可逆操作的审慎程度不够
风险提示	有什么需要特别注意的？	高风险细节被淹没

四种审批动作

“允许 / 拒绝”二选一太粗糙。实际工作中审批人常常是“大体同意，但要改一点”，或者“这个我自己来”：

动作	适用情况	设计要点
批准	内容和范围都没问题	批准后立即显示执行结果，而不是只关闭弹窗
修改后执行	方向正确，细节需要调整	提供可编辑的字段（金额、收件人、正文），修改后仍要经过程序校验
拒绝并说明原因	不应该执行	原因反馈给 Agent，由它调整方案；也进入改进闭环
我来处理	情况复杂，需要人工判断或操作	把上下文完整交给人，Agent 跳过这一步或暂停等待

“修改后执行”特别容易被忽视，但它往往是使用频率最高的动作。没有这个选项，用户只能拒绝，然后在对话框里费力地描述要改什么，再等 Agent 重新生成一次。

注意：用户修改后的参数同样必须经过程序校验。比如用户把退款金额从 ¥328 改成了 ¥3,280，超出了该用户的审批权限，系统应该拦截并升级，而不是因为“人已经批准了”就直接执行。原则见程序校验优先。

图 2 画出四种动作各自的去向：

图 2 · 四种审批动作：批准与修改后执行都要再过程序校验

超越逐条确认

当同类操作很多时，逐条确认会迅速导致审批疲劳。几种常用的替代设计：

批量审批。 把同类请求聚合在一起，突出例外项：

待审批：12 封延迟说明邮件
  ✓ 10 封  使用标准模板，内容无差异         [全部批准]
  ⚠  2 封  内容包含“赔偿”字样，需逐条查看   [逐条查看]

规则化授权。 允许用户为一类操作授权，而不是逐次确认，例如“本任务中同一模板的通知不再确认”。授权的范围要明确（本次任务、本类操作、有效期），并且随时可以撤销。OpenAI Agents SDK 的人工审批机制就支持在批准时选择在本次运行的剩余部分自动批准同一工具的后续调用。

审批前置到计划阶段。 在计划与进度中一次性确认：“执行过程中将发送约 12 封说明邮件，并发起最多 3 笔 ¥200 以内的补偿退款”。用户批准计划即授权这些操作，执行中只有超出计划范围的操作才需要再次审批。

延迟执行与撤销窗口。 对可以撤销的操作，用“5 分钟后发送，可随时撤回”代替事前确认。这把审批从“阻塞等待”变成了“默认执行、可以反悔”，适合风险较低但量大的操作。删除数据、发起退款这类不可逆操作的处理见不可逆操作。

中途接管

除了在审批点介入，用户还应该能在任何时刻暂停、停止或接管 Agent 的工作。

暂停：Agent 在当前步骤完成后停下，保留全部状态，可以继续。
停止：终止任务，界面清楚显示已经执行了哪些操作、哪些没有执行。
接管：用户亲自操作，Agent 让出控制权。

OpenAI 在介绍 ChatGPT agent 时强调了类似的控制设计：执行有实际后果的操作前请求许可，用户可以随时中断、接管浏览器或停止任务。Coding Agent 中也有对应的恢复机制，例如 Claude Code 的检查点功能可以把 Claude 的文件编辑和对话回退到之前的某个时间点（它不追踪通过 Bash 命令修改的文件，因此不能替代 Git）。

接管设计中最容易被忽略的是 交还控制权 的环节：

你已完成接管操作。
Agent 检测到以下变化：
  · 说明邮件已由你修改并发送（邮件回执：已送达）
  · 补偿退款尚未发起

接下来我将：从第 5 步“发起补偿退款”继续，金额按你在邮件中承诺的 ¥50 填写。
[继续执行]  [修改后继续]  [结束任务]

Agent 必须知道用户在接管期间做了什么，否则很可能重复执行（再发一封邮件）或者基于过时的状态继续。

图 3 画出从接管到交还控制权的完整流程：

图 3 · 接管后交还控制权：先同步变化，再由用户确认如何继续

审批要能等待，也要能被度量

工程上，审批意味着 Agent 要在某个步骤暂停，可能等几分钟，也可能等到第二天。这要求运行状态能够被持久化并在之后恢复。主流框架都提供了相应机制，例如 OpenAI Agents SDK 在需要审批时返回中断项，运行状态可以序列化保存，审批后恢复执行；LangGraph 的 interrupt() 依赖检查点保存图的状态，并通过线程 ID 在之后恢复。产品经理需要确认：审批超时怎么办？审批期间业务数据变了怎么办？

运营上，审批本身也要被度量，放进日志、指标与告警的看板：

指标	反映的问题	调整方向
批准率接近 100% 且平均审批时长只有 1–2 秒	审批流于形式，可能没人在看	降低该类操作的审批要求，或改为抽检、撤销窗口
修改率很高	Agent 生成的内容质量不足	改进指令、模板或数据
拒绝率很高	Agent 在不该发起时发起操作	检查触发条件与计划逻辑
审批等待时间很长	审批人不在线或通知不到位	改进通知渠道，设置超时升级，见异步任务体验

常见误区

“有审批就安全了。” 看不懂、太频繁的审批只会训练用户无脑点击。审批的有效性取决于交互设计。
“用户批准了，就可以直接执行。” 人会看漏，也会改错。批准后的参数仍然要经过程序校验与权限检查。
“审批就是二选一。” 缺少“修改后执行”和“我来处理”，会让大量审批变成低效的来回沟通。
“接管结束，Agent 接着往下跑就行。” 不同步接管期间的变化，就可能重复执行或基于错误状态继续。

设计要点

审批卡片用业务语言说明动作、对象与范围、内容预览、依据、可逆性与风险。
提供批准、修改后执行、拒绝并说明原因、我来处理四种动作。
用户修改后的参数同样经过程序校验与权限检查。
量大的同类操作使用批量审批、规则化授权、计划阶段预授权或撤销窗口。
支持随时暂停、停止与接管，停止时清楚列出已执行与未执行的操作。
接管结束后同步变化，并由用户确认 Agent 如何继续。
度量批准率、修改率、拒绝率和等待时长，持续调整审批策略。

练习

为「可执行的售后处理 Agent」设计审批交互（45–60 分钟）。它有三个写操作：发送客户邮件、发起退款（金额 ¥0–¥500）、删除过期的草稿工单数据。

为每个操作画一张审批卡片的文字线框，包含本课列出的全部要素。
为“发起退款”设计“修改后执行”的可编辑字段，并写出修改后需要经过的校验规则。
假设一次任务涉及 30 封客户邮件，设计批量审批或计划预授权方案。
写出用户接管后交还控制权时，界面上展示的内容。

下一步

审批通过、任务完成，用户最终拿到的是产物。下一课「以产物为中心」讲如何呈现和迭代报告、文档、代码与工单等产物。

审批与接管