Agent 的审批机制：AI 要发邮件、要下单——在哪个节点需要人点头

你让 AI 助手帮你发一封邮件给客户，它把邮件写好了，点击了发送。过了十分钟你发现，邮件里的报价数字写错了。你怪 AI 吗？其实更该怪的是你自己——你给了它发送的权限，却没在发送前设一道关卡。

这就是 Agent 审批机制要解决的问题：AI 能做的事越来越多，但它在哪个环节需要人点头，决定了这件事的风险等级。

我最早接触这个概念时，觉得审批机制不就是加个 if 判断吗？AI 要执行敏感操作前弹个窗，用户点确认就放行，点拒绝就终止。后来真正动手设计 Agent 系统才发现，问题远没有这么简单：什么算敏感操作？谁来定义？审批一次就够了还是每一步都要审？如果人不在电脑前，AI 是不是就卡死了？每个问题背后都是自主性和控制权的博弈。

AI 下单这件小事，为什么难倒了整个行业

先看一个具体的场景。假设你做一个购物 Agent，用户说"帮我买一箱牛奶"，Agent 要完成一系列动作：搜索商品、比对价格、加入购物车、选择地址、提交订单。每个动作都有风险等级，但最敏感的显然是最后一步——花钱。

问题来了：提交订单之前要审批，那加入购物车要不要审？如果你说不用，那 Agent 可以往购物车里塞一百件东西，虽然没下单，但用户的心理预期已经被搅乱了。如果你说每一步都审，那这个 Agent 就不叫 Agent 了，叫遥控机器人，用户点确认的时间比自己下单还长。

我见过一个团队的设计方案：他们把操作分成了三个等级——只读操作自动执行，低风险写操作（如保存草稿）自动执行，高风险操作（如发送、支付、删除）必须审批。听起来合理，但实际跑起来发现一个问题：风险高低不是一成不变的。同样是发邮件，发给同事的内部通知和发给客户的合同，风险完全不一样。规则写死了，要么误伤，要么漏放。

审批的本质：把"信任边界"画出来

后来我想通了一件事：审批机制的核心不是技术，而是信任边界。你在画一条线，线内 AI 自己说了算，线外必须人来拍板。这条线怎么画，取决于你对 Agent 的信任程度，以及它一旦犯错会造成多大损失。

信任边界不是一条直线，而是分层的。我总结了一个三层模型：

无审批区：低风险、可撤销、影响范围小。比如 AI 帮你查天气、整理文档、生成草稿。这些操作即使错了，你发现后改一下就行，损失几乎为零。
单次审批区：不可逆或成本较高，但风险可控。比如发送邮件、发布公告、提交订单。需要人在执行前确认一次。
多级审批区：涉及大额资金、敏感数据、对外承诺。比如采购超过一万元的设备、删除生产数据库、对外签署合同。这时候不仅需要人点头，可能还需要两个不同层级的人点头。

这个模型的依据很简单：风险等级 = 不可逆程度 × 影响范围 × 出错概率。邮件发错了可以撤回（虽然有延迟），订单下错了可以取消，但钱付出去再想要回来，那就是另一套流程了。

审批节点放在哪：执行前、执行后，还是执行中？

确定了什么操作需要审批，接下来要回答：人在哪个节点介入？我把常见的设计梳理了一遍，大致有三条路线：

执行前审批：最传统，也最安全

这是大多数系统默认的选择。Agent 把要执行的操作和理由打包展示给用户，用户点确认后，Agent 才真正动手。好处是风险最低，坏处是打断体验——用户本来想当甩手掌柜，结果被拉回来当监工。

我见过一个聪明的变体：延迟审批。Agent 把操作放在待办队列里，不是马上执行，而是给用户一个宽限期。比如 Agent 早上八点帮你抢了一张限时优惠券，但付款操作会等到九点，如果这期间你取消，就不用付钱了。这相当于把审批变成了"默认放行，但保留叫停权"。

执行后审批：把信任前置

更激进的方案是让 Agent 先干活，事后向用户汇报。这种模式适合低风险、高频率、可撤销的场景。比如 AI 帮你整理收件箱，把垃圾邮件归到垃圾箱，分类错了你随时可以改回来。

但执行后审批有一个致命缺陷：如果 AI 的行为不可逆，事后审批就变成了事后追责。你让 Agent 替你回复了一个重要客户的邮件，事后发现措辞不当，虽然你可以补救，但伤害已经造成了。所以执行后审批只适合那些"错了也能轻易改回来"的操作。

执行中审批：流程关键节点的"卡点"

有些操作是长流程，中间有多个关键步骤。这时候可以设计成在流程的特定节点停下，等人确认后再继续。比如 Agent 帮你写一份招标书，它调研资料、起草框架、填充内容都可以自动完成，但到了"生成最终版本并发送给客户"这个节点，就必须停下来等用户过目。

执行中审批的本质是把一个大任务的信任边界切成了多个小段，每段都让 AI 展示它的阶段性成果，人只负责审核"这一段做得对不对"。这比执行前审批更灵活，比执行后审批更安全。

OpenAI 在 2025 年 3 月发布的 AgentKit 文档里提到：安全是 Agent 开发的核心，建议开发者在 Agent 执行敏感操作前设置权限和审批流，并强调"在关键节点介入是防止 Agent 做出不可逆行为的关键"。OpenAI 官方公告

谁负责审批：人、规则，还是另一个 AI？

审批机制里最容易被忽略的问题是：审批者是谁？大多数人的第一反应是人。但仔细想想，AI 一天可能执行几千个操作，如果每个操作都找人来审，人就成了瓶颈。所以实际系统里，审批者不一定是人，可能是一套规则引擎，甚至是一个更低层级的 AI。

我画过一张决策表，帮自己理清了不同审批者的适用场景：

审批者	适用场景	优点	缺点
规则引擎	操作类型固定、风险判定明确	零延迟、一致性高	死板，无法处理边界情况
人工审批	高价值、不可逆、需要主观判断	灵活、能理解上下文	慢、贵、容易疲劳
AI 审批（次级 Agent）	大批量、低风险、可模式化判断	速度快、可扩展	可能学偏、需要持续监控
混合模式	大多数生产环境	兼顾效率与安全	实现复杂，需要精心编排

我见过最有意思的混合模式是"先 AI 筛、后人工定"：一个初级 Agent 先对操作做一次预审，把明显违规的拦截掉，把可疑的标记出来，把安全的放行。只有标记为可疑的操作才会进入人工审批队列。这样人工需要审核的量可能只剩原来的 10%，而风险覆盖率却几乎没降。

但这里有一个必须警惕的陷阱：AI 审批者可能学会"装死"。如果初级 Agent 发现某些操作经常被人批回来，它可能会调整自己的策略，变得更保守或更激进，而你不会立刻察觉。所以 AI 审批者本身也需要被审计——它的判定记录、通过率、被驳回率，都应该有监控面板。

审批机制的一个反直觉事实：审批越多，错误越少，但用户越不满意

你可能觉得，审批环节越多越安全，用户应该更放心才对。但实际用户体验研究显示了一个反直觉的结果：过度审批会让用户对 Agent 的能力失去信心。如果每次 AI 做点小事都要弹窗确认，用户会想："这 AI 是不是根本没学会，什么都要问我？"

我早期设计一个客服 Agent 时就犯过这个错。为了确保不犯错，我在每个回复前都加了一道人工确认。结果用户反馈说："你们这个 AI 就是个打字员，我提问它还要请示领导。"后来我们把确认机制砍到只剩"发送"这一步，满意度反而上去了。

这说明审批机制的设计必须平衡两个目标：降低风险和维持流畅体验。一个合格的审批设计，应该让用户感觉到"AI 在替我做事，同时把最重要的决定权留给我"，而不是"AI 每走一步都在问我怎么办"。

具体怎么实现？一个最小可用的审批配置示例

// 用 JSON 配置一个 Agent 的审批规则
{
  "agent": "shopping-agent",
  "approval_rules": [
    {
      "action": "search_product",
      "risk": "low",
      "approval": "none"
    },
    {
      "action": "add_to_cart",
      "risk": "low",
      "approval": "none"
    },
    {
      "action": "place_order",
      "risk": "high",
      "approval": "human",
      "timeout": 3600,
      "on_timeout": "cancel"
    },
    {
      "action": "cancel_order",
      "risk": "high",
      "approval": "human",
      "require_second_approval": true
    }
  ]
}