AI代理审批流：人工确认为何总被无脑点击？

审批弹窗的困境：第一天新鲜，一周后形同虚设

给 AI 代理的工具调用加上审批提示，几乎所有开发者都经历过这样的过程：LangGraph 的中断、OpenAI 远程 MCP 的 require_approval、Claude Code 的询问规则，第一天大家还会认真看，但一周之后，大多数人连内容都不看就直接点“是”。这是 Reddit 社区最近一个讨论帖中提出的核心问题：哪些审批步骤还能真正被阅读？

帖子指出，问题不在于审批机制本身，而在于规则存放的位置。如果代理自己持有密钥，规则又写在自己的配置里，那这套审批几乎等同于“荣誉系统”——代理完全有条件绕开或忽略规则。

规则与密钥分离：让审批不再是“自己监督自己”

帖子作者认为，要打破这种“荣誉系统”，关键是把规则和密钥从代理的配置中剥离出来。他提到了几种可行的方案：

• 按工具设置拒绝规则，但放在代理无法修改的地方；
• 在代理前面加一道 OPA（Open Policy Agent）检查；
• 使用 MCP 网关（比如 Hush Security 这类方案）来统一持有密钥。

这些方案的共同点是：代理不再同时拥有“钥匙”和“规则”。它必须通过外部系统才能执行敏感操作，而外部系统可以独立执行策略，不受代理自身配置的影响。

OPA（Open Policy Agent） 是一个开源的通用策略引擎，由 CNCF 孵化并已毕业。它使用声明式的 Rego 语言编写策略，并通过一个独立的服务（或库）对外提供决策接口：调用方把请求的上下文（谁、要做什么、对什么资源）发给 OPA，OPA 返回允许或拒绝。其关键价值在于策略与执行分离——策略集中存放、独立版本管理，被管控的应用无法自行篡改。用在 AI 代理场景中，代理每次敏感工具调用前都需向 OPA 询问，而策略文件由运维或安全团队维护，代理既看不到也改不了，从而把「自我监督」变成「外部仲裁」。

MCP 网关 则是面向 Model Context Protocol 的中间层。MCP 是让 AI 代理连接外部工具与数据源的开放协议，但若代理直接持有各工具的下游凭据，一旦被提示注入或配置被改，凭据就会泄露。MCP 网关把凭据集中托管，代理只与网关通信，由网关代其向上游服务鉴权，并可在转发时执行策略校验、审计与限流。这样敏感凭据不进入代理的运行环境，代理即使被攻破也无法直接调用下游系统。

什么样的审批才能真正奏效？

帖子进一步指出，真正能保持有效性的审批有两个特征：触发频率低，并且展示实际内容。

所谓“展示实际内容”，是指审批界面要明确告诉审批人：这封邮件要发给谁、金额是多少、哪条记录会被修改。如果审批只显示“是否允许该工具调用”，那它很快就会退化成无脑点击的按钮。

这个观点在社区中得到不少认同。高频审批几乎必然导致“审批疲劳”，而缺乏上下文的审批则让人无法判断风险。两者叠加，审批就变成了走过场。

权限分层：读放开、写询问、破坏性操作默认关闭

除了审批设计，帖子还提出了一套更基础的权限模型：读操作直接放行，写操作需要询问，破坏性操作默认关闭，除非有人为了特定任务手动开启。

这套模型的逻辑是：审批应该用在真正需要人类判断的地方，而不是对所有操作一视同仁。读操作风险低，没必要打断；写操作可能产生副作用，需要确认；破坏性操作（如删除、覆盖）则应默认禁止，必须显式授权。

GitHub Environments：一个值得借鉴的审批模型

帖子最后提到了 GitHub Environments 的设计：密钥只有在评审者批准之后才会到达任务。

这个模型的可取之处在于，审批不是一道“确认弹窗”，而是一个门禁——不批准，密钥根本不会出现在执行环境中。审批人对结果负责，而不是对按钮负责。相比单纯的弹窗确认，这种机制更接近真正的安全控制。

GitHub Environments 是 GitHub Actions 中的部署目标抽象，可为不同环境（如 staging、production）分别配置保护规则。其中最相关的机制是 required reviewers：工作流在进入该环境前会暂停，等待指定评审者批准；在批准之前，环境专属的 secrets 不会被注入到 job 中。这与普通「确认弹窗」的本质区别在于，审批卡在凭据发放这一环，而不是卡在动作执行之后——未获批就根本拿不到执行所需的密钥。此外它还支持等待计时器、限定可部署分支等规则，可与本文主张的「低频、高影响、结果负责」审批原则相互印证。

总结

审批流程的设计不能只靠“加一个确认框”。当规则和密钥都在代理手里时，审批就是摆设；当审批频率过高、信息不足时，审批就会沦为无脑点击。真正有效的做法是：分离规则与密钥、只在低频且高风险的操作上触发审批、在审批中展示具体影响，并用权限分层从源头减少不必要的审批需求。