🚧 Roadmap — 本页描述的能力尚在路线图中，概念与设计已定型，接口与操作步骤以正式发布为准。
需要人批准时：异步授权
读完本指南，你将知道：
- 哪些操作不该被任何预先授权覆盖
- "Agent 暂停、带外找人批、只批这一次"的流程长什么样
- 超时、拒绝、审批人不在时该怎么设计
前置条件
- 已理解 Consent 与审批 的三种"人说了算"时刻
- 已有可触达审批人的带外通道（推送、IM、邮件、短信）
- 明确哪些操作需要逐次审批——这是产品决策，不是技术决策
什么操作需要逐次审批
判断标准很简单：做错了能不能撤回。
| 特征 | 例子 | 是否需要逐次审批 |
|---|---|---|
| 不可逆 | 转账、删除批量数据、发出对外邮件 | 需要 |
| 高金额或高影响 | 超过阈值的采购、生产环境变更 | 需要 |
| 涉及第三方权益 | 代客户签署、代客户下单 | 需要 |
| 可撤回、影响面小 | 查询、生成草稿、内部报表 | 不需要——预先授权足够 |
不要把所有操作都设成需审批。审批疲劳会让人闭眼点同意，那时审批就成了摆设。
流程：一次审批的六步
以"Agent 想执行一笔超阈值转账"为例：
- Agent → 你的应用：请求执行转账。
- 你的应用 判断这笔操作命中审批策略（金额、类型、对手方），不直接执行，而是发起一次审批请求，说清三件事：
- Agent 想做什么（收款方、金额、用途）
- 影响什么（从哪个账户出、是否可撤回）
- 为什么现在问你（触发了哪条策略）
- 带外通道 把审批请求推给负责人。Agent 此时处于挂起状态，不占用资源、不重试。
- 负责人 在自己的设备上批准或拒绝。审批界面必须显示完整上下文——批准人要能看懂自己在批什么。
- 批准 → 发放一枚仅限该次操作的授权：绑定这一笔转账的参数，一次性使用，短时有效。拒绝或超时 → 操作终止，Agent 收到明确失败原因。
- 无论结果，审批事件入审计链：谁批的、什么时候、批的是什么参数（见 审计与追责链）。
关键设计点：授权绑定操作参数。如果批准的是"转 5000 元给 A"，那么这枚授权不能用来转 5000 元给 B，也不能转 50000 元给 A。参数变了就要重新批。
设计建议
默认拒绝。 超时未批 = 拒绝，不是"继续执行"。这一条写进策略，不留可配置的余地。
审批请求要有过期时间。 一个小时前的转账请求，现在批准还合适吗？给审批请求设短窗口，过期作废。
审批人不能是发起人。 结构上禁止自审批——这条在 Agent 场景下尤其重要，因为"发起人"可能是一个 Agent，而它的技术负责人正好也是审批人。
要有降级路径。 审批人休假、通道故障、系统不可用时，Agent 应当停下来并明确报错，而不是绕过审批继续执行。
标准与协议
这个模式在标准侧对应 CIBA（Client-Initiated Backchannel Authentication，OpenID Foundation）：由后端发起认证请求、用户通过带外通道确认。它解决的正是"审批人不在 Agent 的会话里"这个结构性难题——Agent 没有浏览器可以重定向，只能靠后端去找人。
授权范围的表达则与 RFC 9396 Rich Authorization Requests 的思路一致：不只声明 scope，还声明这次授权绑定的具体资源与参数。
常见问题
审批会不会让 Agent 变得很慢？ 会——这正是设计意图。需要审批的操作本来就不该"快"。把审批范围收窄到真正不可逆的操作上，其余走预先授权。
能批准一次、之后同类操作都免批吗？ 可以做成策略（如"同一对手方、单笔低于阈值、24 小时内免批"），但要显式配置、可审计、可撤回。默认不要开。
Agent 挂起期间怎么办？ 设计成无状态等待：Agent 记下请求 ID 退出，审批结果到达后由回调或轮询恢复执行。不要让 Agent 长时间占着连接空等。
下一步
- Consent 与审批 —— 三种"人说了算"的时刻。
- 吊销与应急处置 —— 已经发生的操作怎么止损。
- 安全考量 —— 越权与冒充的防线。