← [ BACK_TO_NOTES ]

Agent 中的 Approval Checkpoints

Approval checkpoints 是 agent 在高风险或不可逆动作前必须停下并请求授权的控制节点，用来把自动化和人工判断组合起来。

#ai #concept #growing

[!info] related notes

所属 MOC: Agent MOC, Coding Agent MOC, Agent Evals MOC

前置概念: Agent Guardrails, Agent 中的人类监督

并列概念: Agent Runtime

易混淆概念: Agent Guardrails

关系笔记: Agent 测试与评估

实践案例: 两阶段提案合并安全边界

Agent 中的 Approval Checkpoints

一句话定义

Approval checkpoints 是执行策略要求新增授权时的控制点。先识别已存在的任务授权：范围内操作直接继续，明确禁止的操作拒绝；需要补充授权时才展示具体可审阅结果并等待决策。

核心机制 / 工作原理

审批点通常会放在这些地方：

资金、权限、生产环境等高风险动作前
会造成外部副作用的操作前
沙箱外执行或权限升级前
缺少关键用户决策时（这是澄清，不应自动等同于权限审批）

一个有效审批点通常不只是“弹个确认框”，而是会一起提交：

agent 准备做什么
为什么现在要做
影响范围是什么
可供审批人检查的 diff、命令、目标对象或风险说明

最小例子 / 最小场景

若当前任务和策略尚未授权，coding agent 在 git push、修改生产配置或运行高权限脚本前：

runtime 先拦下动作
展示变更摘要和目标命令
等待有权审批的人批准或拒绝；已明确授予且仍有效的同范围授权无需反复询问

这就是典型的 approval checkpoint。

边界与易混淆点

approval checkpoint 不等于一般 guardrail。guardrail 可以自动阻止；审批点强调显式授权。
它不只发生在最终交付前，也可能出现在执行中间的关键节点。
如果审批点放得太晚，副作用已经发生，它就不再是真正的控制点。
批准应绑定操作内容、目标版本、主体和有效期；参数修改后重新产生可审阅请求，不能沿用旧批准。
审批记录、持久检查点和幂等执行是不同职责，恢复流程仍需执行权限检查。

学习检查

不看正文回答：

Approval checkpoint 与自动 guardrail 的核心差异是什么？
为什么审批必须发生在副作用之前，而不是动作完成后？
哪些属性会让一个 Agent 动作值得进入审批：不可逆性、权限、资金、生产环境、数据外发还是其他？
一个有效审批请求为什么应该包含 diff / command / target / impact，而不是只显示“是否继续”？
审批点太多会产生什么 UX 和安全问题？太少又会怎样？
Policy approval 与 human approval 可以怎样组合？
给一个 coding agent 发布生产版本的流程，标出至少两个合理审批点并解释原因。