模式矩阵 /模式白皮书/G1

G1 · Approval Gate · 审批门

它解决什么问题

Agent 进生产之后，最贵的不是它跑得慢，是它独自 commit 了一个不可逆的高风险动作。一笔转账、一次 production 部署、一封对外发布的邮件，错一次的代价远超它跑一万次省下的人力。把所有动作都交给 Agent 自动执行是赌博，把所有动作都拦下来人审又会让效率回到 Agent 之前。

Approval Gate 把这件事路由化：每个动作到达决策点，先按风险分类，再分发到三个目的地之一——低风险自动放行、中风险留痕后执行、高风险强制人审。它不追求拦下每一个动作，只追求让"错的代价不可逆且巨大"的那一小类动作必须有人按过回车。这条边界还顺带回答了企业落地 Agent 最关心的一个问题——出事谁负责：有人审过的责任由审批人承担，自动决定的责任由产品 owner 承担。

为什么坐标是「治理 × 路由」

• 纵轴 · 治理：审批门管的是高 blast radius 动作该不该被执行，是治理的核心控制点。它不改变 Agent 怎么推理，也不优化它的输出质量，只在动作即将落地的那一刻插入一道人类否决权。
• 横轴 · 路由：它的本质是一个 router——把到达的每个 action 按 reversibility × impact 分类，分发到 auto-approve / auto-with-log / human-in-loop 三条路径。这是基于动作特征的一次分流决策，不是链式串联，也不是按层级限权。

核心机制

一次审批评估由风险分级加三阶段路由组成：

风险分级建议走 reversibility × impact 双轴，而不是单纯按金额线性切。可逆且影响小的自动放行，不可逆或影响大的强制人审，超过某个阈值的再加 two-person rule 要求两人独立复核。Claude Code 的 5+1 PermissionMode（default / plan / acceptEdits / bypass / dontAsk / auto）是这套档位设计的工业样本，把"全开/全关"二选一升级成了多档位加动态判定的状态机。

适合的生产场景

• 金融与支付：转账、退款、放款这类不可逆资金动作，超阈值必须人审且高额走双人复核。
• 运维生产环境：部署、数据库 migration、DNS 切换这类影响面大的操作，先看 plan 再执行。
• 对外发布与法律文书：邮件群发、合同生成、监管报告，错一次的声誉与合规代价不可逆。
• regulator-facing 的高风险 AI：部署在 EU 且属于招聘、信贷、关键基础设施等类别的系统，没有 human oversight 的审批路径直接合规失败。

容易出错的地方

• Approval Fatigue（审批疲劳）：allow list 太窄、每个动作都弹窗，审批人开始条件反射点放行。这种橡皮图章比没有审批更危险，因为它制造了"已经有人审过"的虚假安全感。把 demonstrably safe 的动作放宽到自动放行，把人审留给真正高风险的。
• False Safety（虚假安全）：deny 规则只看 tool name 不看参数，一个看似无害的 run_command 调 rm -rf 就绕过了。deny 必须检查 arguments，高风险判定建议用 LLM 评估参数是否 destructive。
• Trust Score Override Drift（信任分数绕过漂移）：为了减少审批人不耐烦，加一条"老 vendor 累计成功 N 次就放宽阈值"。每一次绕过都假设那条被绕过的路径不会出事，直到那笔被绕过的大额付款进了攻击者账户。金额、不可逆性、监管关键性这三类硬触发永远不允许被 trust 优化绕过。
• 审批规则散落在 agent 代码里：每个 Agent 各写一套，跨 Agent 系统找不到统一合规边界。正确方向是把 policy 抽到独立的 centralized layer，用声明式语言让合规团队和工程团队在同一份文件里协作。

关键指标

• approval-to-rejection 比例（健康区低于 95%）：放行与拒绝的比值。超过 95% 说明 gate 加了摩擦却几乎不拦截，多半已经在橡皮图章式放行。
• 审批人平均决策时长（健康区高于 3 秒）：低于 3 秒是明显的 reflex 而非审视，是审批疲劳的直接信号。
• override path 实际触发率（健康区接近 0 且不上升）：trust-based 绕过路径的触发频率。一旦发现异常上升立刻停，这是 200 万事故的早期征兆。
• audit log 完整率（健康区 100%）：高风险动作留痕的覆盖率。低于 100% 意味着出事时查不清谁批的、凭什么批，直接违反 EU AI Act Article 22 留档要求。

最小骨架

对每个 action：
    risk = classify(action)          # reversibility × impact 双轴
    Stage 1 Deny  → 命中黑名单(查 args 不只查 name) → 拒绝
    Stage 2 Allow → 命中白名单 且 risk != CRITICAL → 放行
    Stage 3 Ask:
        risk == LOW            → 自动放行
        risk >= MEDIUM         → 路由到人审(无人可审则默认拒绝)
        risk 超阈值 / 不可逆    → two-person rule 双人独立复核
返回 ApprovalRecord(action / risk / decision / reviewer / rationale)
全程写 WORM audit log（满足监管留档）

工程落地三处必改：risk classifier 换成业务的（金融用 KYC + AML 评分、运维用 blast radius 估算）；人审接口对接真实审批工作流（飞书 / Slack / ServiceNow）而非 console input；双人复核强制 reviewer1 ≠ reviewer2。

企业落地一例

某美国 mid-market 银行的 vendor payment Agent，第一版规则是"1 万美金以下自动付、以上需审批"，前两个月跑得很顺。出事那次，一个老 vendor 通过伪造的 change notice 改了收款账号，Agent 读 notice、走 reconciliation、在季度账到期时自动付了 20 万美金，钱进了攻击者账户。根因不是 Agent 没标风险——它标了 high-amount——而是工程团队为了减少审批人不耐烦，加了一条"累计成功超 50 次的老 vendor 阈值放宽到 5 万美金"的 trust-score override，把这笔本该走审批的大额付款自动放行了。事故后银行加了一条铁律：no trust-score override on amount triggers，再老的 vendor 金额一过门槛审批人必须按回车。这套修正还包括 30 天内改过账号加大额组合强制双人复核、audit log 七年留档备查。问题的根因不是审批门不够用，是有人为了 UX 把审批门绕过了。

在执行型 Agent 的工程实现里，这套门可以做得更轻。当 Agent 有了任务节点和任务状态机之后，敏感任务能在节点处被阻塞、等人工审核通过再继续执行，需要审核的关键操作基于配置声明即可挂上 human-in-the-loop，不必每次都改代码。

与其他模式的关系

• 爆炸半径控制（G2）：治理双柱。审批门是软闸，问"该不该做"；爆炸半径是硬墙，限"做错了能错多大"。审批漏掉的风险，由 G2 的工程边界在事中兜住。
• 渐进承诺（G3）：互补。审批门是一道静态的门，渐进承诺是一条动态的权力进阶路径。同一个动作两个模式一起决定 routing——当前信任档位越高，需要人审的动作越少。
• 可观测性（G5）：依赖。审批门必须留 audit log，G5 让这些 log 可被查询、可被回放、可被监管审计。没有 G5，审批记录就是没人看的死数据。
• 钩子流水线（G4）：审批门是 PreToolUse hook 的一种特殊形态——在动作执行前插入的一道 deterministic 拦截。

一句话记住它

Approval Gate 的本质不是 UX 工作流，而是责任承担工程——它把"Agent 出事谁背锅"这个模糊问题，转化成"有人审过的归审批人、自动决定的归 owner"这条明确的责任划分契约。

本页属于 ADPS 33 模式白皮书。返回 模式矩阵与白皮书目录， 或查看配套 可运行代码目录。