KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA
09. 一次真正有效的人工审批长什么样？ — keel 龙骨
“是否允许 Agent 执行操作？”这样的弹窗没有告诉审批人目标、参数、影响和来源。用户只能机械点击，人在回路中就退化成免责按钮。
“是否允许 Agent 执行操作？”这样的弹窗没有告诉审批人目标、参数、影响和来源。用户只能机械点击，人在回路中就退化成免责按钮。
人必须看到决定所需的信息
一次配置变更至少展示：
请求者：alice / on-call
执行者：config-agent/run-42
目标：tenant-a / staging / payment-service
动作：pool_limit 20 -> 40
资源版本：cfg-7
副作用：write，可补偿
依据：INC-1042，指标 evidence-7
风险：连接数上升；需观察数据库负载
策略：change-policy/v3
有效期：5 分钟，单次使用
审批人不需要看到模型隐藏推理，但必须看到事实、差异、风险和不确定性。
Approval Ticket 绑定不可变动作
ticket.action_fingerprint == command.fingerprint
ticket.requester != ticket.approver（高风险场景）
ticket.expires_at > now
ticket.policy_version is still accepted
ticket.used_at is null
PEP 在执行前验证全部条件，并原子标记 ticket 已使用。参数改动、资源版本变化或 ticket 重放都应拒绝。
防止 TOCTOU
审批时资源是 cfg-7，执行时已变成 cfg-8。即使动作 fingerprint 未变，审批所依据的 before state 已失效。解决方法：把 expected resource version 放进 Command 和 preview，在 Adapter 提交时做条件写入。
风险分级，避免审批疲劳
自动允许：受 scope 限制的低敏只读查询
一次确认：可逆的 staging 写入
双人审批：生产变更、批量外部通知
禁止自动化：超出组织政策或无法安全隔离的动作
频繁要求审批并不一定更安全。相同低风险动作可以使用受限、可撤销、短期的预授权；高风险动作则减少频率并提高信息质量。
审批人不能被 Agent 冒充
模型输出“管理员已批准”、网页中的批准文字、Reviewer 的质量通过、历史记忆里的豁免都不是 Approval Store 中的认证决定。审批来自独立身份通道，并带签名或服务端记录。
运行审批绑定实验
python courses/advanced/safety-controls/course/project/examples/04_approval_binding.py
先批准连接池改到 40，再尝试用同一 ticket 改到 80、跨资源使用、过期后使用和第二次使用。四种情况都应在 Adapter 之前失败。
检查理解
- 为什么审批要绑定 fingerprint 而不是 action 名称？
- Reviewer 说“报告通过”为什么不是发布授权？
- 哪些低风险动作反而不应每次弹窗？