什么是 审批门禁（Approval Gate）？
审批门禁（Approval Gate）是确定性执行检查点，在 AI 动作产生外部副作用前，阻断执行并由可信代码验证适用的策略决定或审批记录。
快速了解
| 规范文档 | 官方规范 |
|---|
工作原理
Approval Gate 位于受保护操作的唯一执行路径上。它接收具体 Action Proposal 与可信 Execution Context，输出 allow、deny、require review、escalate 或 expire 等明确结果。它不会询问模型动作是否安全，Tool Description 或 Prompt 也不能绕过它。门禁应尽可能靠近 Side-effecting Adapter，或直接放在下游服务内部。
Gate 是更广泛 Human-in-the-Loop 设计中的一种机制。人工 Reviewer 可以签发 Approval，确定性 Rule 或可信 Policy Service 也可以批准低风险案例。相反，Interrupt 只负责暂停 Run；如果到受保护操作还存在不校验有效决定的路径，它就不是门禁。Guardrails 覆盖更广的 Input、Output、Tool 或 Policy 控制，Approval Gate 则专门强制执行流程推进或 Effect。
输入应包含可信 Actor / Tenant Identity、Resource 与 Current State、准确 Operation / Tool Schema Version、规范化 Argument Digest、Policy Version、Risk Class、Requested Scope、Run / Call ID 和 Approval Evidence。模型提供 Identity、Ownership、Price、Risk 或历史 Approval 字段，不代表这些字段可信。通过 Gate 后仍必须执行 Downstream Authorization。
Approval Record 应 Immutable、Short-lived、绑定准确 Proposal，并且 Single-use。校验 Approver 当前权限、Separation-of-duties Rule、Decision、Expiry、Revocation、Policy / Schema Version、Resource State、Argument Digest 与 Consumed Status。编辑参数会产生新 Proposal。针对整个 Agent、Conversation、Tool Family 或未来动作的宽泛批准，不等于批准一次具体 Effect。
必须防止 Time-of-check / Time-of-use 缝隙。Dispatch 前立即重新校验，并把 Decision 消费与 Operation / Outbox Record 创建原子化，禁止两个并发 Worker 同时消费一个 Approval。Decision 消费后若 Dispatch Timeout，应记录 outcome_unknown 并向目标系统对账；不能重置 Gate 后再次执行。仍需 Stable Operation Key 与下游 Idempotency。
Gate State 可包括 pending、approved、rejected、expired、revoked、cancelled、escalated 与 consumed。受保护 Effect 在 Timeout 或 Review Service 不可用时应 Fail Closed。Denial 应终止或进入有界替代路径，不能让模型无限改写。高风险操作可使用 Multi-party Approval，但 Quorum、Order、Independence、Delegation 与 Revocation 必须明确。
测试 Direct Adapter Bypass、Forged Reviewer Identity、Cross-tenant Approval、Changed Argument、Stale Policy / Schema、Expired / Revoked Decision、Duplicate Consumption、Concurrent Approval / Cancellation、Dispatch 前后 Crash 与 Reviewer Outage。度量 Protected-path Coverage、Bypass Attempt、False Allow / False Block、Queue Age、P50 / P95 Latency、Abandonment、Escalation、Override Outcome、Duplicate Effect 与 Incident。高 Approval Rate 可能说明低风险案例应该自动化，也可能说明 Reviewer 在机械盖章，不能证明安全。
主要特点
- 受保护外部副作用每条路径上的确定性检查点
- 明确 allow、deny、review、escalate、expire、revoke、cancel 与 consume 状态
- Decision 绑定 Actor、Tenant、Resource、Operation、Argument、Schema、Policy 与 Expiry
- 把单次消费与 Operation 或 Outbox 创建原子化
- 保留独立下游授权、最小权限、幂等和副作用对账
- 度量覆盖、绕过、决策质量、队列延迟、重复副作用与事故
常见用途
- 阻断退款、转账、采购、账户变更或权限授予
- 邮件、工单、发布、部署、合并或删除前要求绑定决定
- 对高权限基础设施与安全操作强制职责分离
- 自动放行低风险动作，把异常案例路由到人工复核
- 对受监管或高爆炸半径操作执行多方审批
- 防止过期或重放 Approval 授权已变化的 Tool Argument
示例
Loading code...常见问题
Approval Gate 与 Human-in-the-Loop 有什么区别？
Human-in-the-Loop 是更广的人工控制流程；Approval Gate 是执行前验证 Decision 的确定性强制点。低风险案例的 Gate 也可接受可信 Policy Service 决定。
通过 Approval Gate 就代表动作已获授权吗？
不代表。Gate 校验适用的决定证据，但 Adapter 与下游服务仍须强制当前 Actor Identity、Tenant、Resource Ownership、Scope 与 Least Privilege。
一个 Approval 能覆盖后续或修改后的动作吗？
通常不能。Approval 应绑定规范化 Argument、Operation、Schema、Resource、Actor、Policy 与 Expiry。编辑或重大状态变化会产生需要重新评估的新 Proposal。
Approval Gate 应如何处理重试？
消费 Approval 时创建稳定 Operation Record。重试复用同一个 Operation Key 和下游幂等契约。结果未知时先对账，不能消费新审批并重复副作用。
Approval Gate 应测试哪些场景？
测试绕过路径、伪造与跨租户复核人、参数变化、过期版本、Expiry、Revocation、Replay、重复消费、并发、取消、Reviewer Outage 与 Dispatch 前后 Crash。