AI 代理的审批提示并不等于授权

OpenAI 的 Agents SDK 现在将人工审批视为执行环境状态：敏感工具调用可以暂停执行，展示中断信息，将决策存入 RunState，并在批准或拒绝后从同一次运行中恢复。¹

这种产品形态至少做对了一点：审批应属于执行环境，而不应只存在于聊天记录中。

更难的问题随之而来：人类到底授权了什么？

如果审批提示只写着“允许 shell 命令？”或“批准工具调用？”，它要求用户相信某个瞬间。真正的授权记录则会限定行动范围，标明风险，捕获证据，设置到期时间，并留下可审查的轨迹。AI 代理需要的是后者。因为代理会跨步骤规划、调用嵌套工具、在被拒后重试，并把流畅的解释带入决策场景，让人产生点击“同意”的压力。

要点速览

AI 代理的审批提示并不等于授权。提示可以暂停工作，但授权必须说明：谁授予权限，哪个代理获得权限，哪个工具可以运行，可以触及哪些资源，适用哪条风险通道，授权持续多久，决策依据是什么，以及操作员如何撤销。团队应将审批设计为有范围的权限对象，而不是聊天中断。真正的问题不是“有没有人点击批准？”，而是“负责任的人在什么约束下授权了哪一个具体行动？”

关键结论

对于产品团队： - 将审批呈现为类型化决策对象：行动、资源、风险、证据、到期时间和回滚方式。 - 区分低风险确认与高风险授权。

对于安全团队： - 将重复审批提示视为攻击面，而不仅仅是 UX 问题。 - 记录每一次允许、拒绝、自动允许、自动拒绝、到期和撤销。

对于代理构建者： - 在不可逆行动之前暂停，而不是等代理已经塑造结果之后才暂停。 - 将拒绝反馈给模型时，应作为受约束的指令，而不是含糊的失败。

对于操作员： - 如果看不到目标资源、权限范围和回滚路径，就不要批准工具调用。 - 优先使用短期、限定范围的授权，而不是养成“总是批准”的习惯。

审批提示为什么会失败？

审批提示失败，是因为它把高上下文决策压缩成了低上下文点击。

代理拥有的上下文通常比提示中展示的更多。它可能已经读取文件、总结线程、规划步骤、选择工具、填充参数，并决定执行时机。审批提示往往只展示最后一步。用户看到的是一条命令、一次 API 调用、一个浏览器操作，或同一个代理写出的请求许可语句。

这种界面会造成4类失败：

OWASP 的 Agentic Top 10 直接点名了劝服风险。其发布文章指出，在 ASI09 Human-Agent Trust Exploitation 下，自信的解释可能误导人类操作员批准有害行动。² 这种风险并不要求模型有恶意。一个乐于助人的代理也可能夸大薄弱方案，淡化不确定性，或把高风险工具调用埋进一串看似无害的操作中。

因此，审批需要更好的形态。人应批准的是行动记录，而不是一个请求气泡。

审批应该授权什么？

严肃的审批应在有限条件下授权一个具体行动。

论文《Authenticated Delegation and Authorized AI Agents》将更广泛的问题界定为委托权限：用户需要一种方式来限制代理权限，并通过代理专用凭证、元数据和可审计的访问控制配置，维持清晰的责任链。³

这个框架可以直接映射到产品设计。一次审批应包含：

没有这些字段，审批就只是带按钮的感觉判断。模型可以礼貌请求，人类可以快速点击。但这两件事都不能证明该行动本就应该发生。

审批状态应如何工作？

审批状态应跨越暂停点，但范围必须保持狭窄。

OpenAI 的 Agents SDK 文档描述了一种有用的执行环境模式。工具可以声明 needs_approval；运行器在执行前评估审批规则；未解决的审批会以中断形式出现；开发者可以批准或拒绝每个待处理项目；随后运行从 RunState 恢复。¹ 文档还描述了同一次运行后续调用可使用的粘性决策，例如 always_approve 和 always_reject。¹

状态机很重要，因为暂停的代理运行不应从记忆中重启、重新生成意图，或丢失审批上下文。它应从中断点恢复，并附带该决策。

粘性决策选项也带来了下一个设计要求：每个粘性审批都必须有范围和到期时间。

粘性审批可以减少疲劳。范围过宽的粘性审批，则可能把一次疲惫点击变成整次运行的完整影响范围。

审批应处于执行环境的哪个位置？

审批应位于提交点之前。

提交点，是代理从可逆工作跨入副作用的那一刻：修改生产资源、发送消息、花钱、发布内容、删除数据、轮换密钥、变更权限或部署代码。提交点之后的人类审批已经不再是授权，而是事故响应。

关于人类监督的研究也支持这一区分。2026年一篇发表于 AI and Ethics 的论文区分了操作性能动性与评估性能动性：前者是 AI 生成或行动，后者是人类能够评估、质疑和覆盖。⁴ 有效监督不能依赖某个人盯着每个 token。界面必须把人类判断保留在仍能改变结果的位置。

这给代理产品带来一条简单规则：

如果提示出现在代理已经执行高风险部分之后，它只是在制造形式感。系统已经花掉权限时，人类就无法行使评估性能动性。

如何防止审批疲劳？

审批疲劳是一种安全缺陷，因为疲劳会改变决策。

如果一次运行要求40次审批，产品很可能在用户点击之前就已经失败。操作员不再逐项判断，而是在处理烦扰。攻击者可以利用这种模式：生成重复请求，把高风险行动藏进批处理中，或使用让危险调用显得日常的措辞。

OWASP 的 Agentic Top 10 将人机信任利用列为一类核心风险。² 代理安全研究也从系统侧得出了类似结论。2026年3月一篇关于代理式 AI 安全的系统化论文，将信任边界映射到提示注入、RAG 投毒、工具与插件利用、多代理威胁等场景，并呼吁引入执行环境监控和事故响应控制。⁵ 2026年5月一篇关于安全可审计代理的论文则指出，如果系统无法将能力、记忆、目标、推理轨迹和行动连接成可查询的审计路径，那么静态物料清单和运行日志只会提供碎片化证据。⁶

审批设计应通过移除低价值提示、提升高价值提示质量来减少疲劳：

目标不是减少控制，而是减少无意义的控制。

审批 UI 应展示什么？

审批 UI 应展示决策，而不是代理的性格。

可以从一张紧凑的决策卡开始：

这张卡帮助用户回答一个问题：请求的行动是否与证据和范围相匹配？

卡片不应隐藏确切参数，也不应隐藏拒绝选项。它不应把“批准”设计成唯一顺畅路径，而让“拒绝”像异常一样处理。好的审批界面会把拒绝视为正常控制信号。代理应收到精确消息：“因来源 URL 未验证而拒绝”，或“因命令触及发布范围之外的文件而拒绝”。

团队应先构建什么？

先构建审批账本，再构建更漂亮的提示。

最小账本字段包括：

1. 运行 ID。
2. 代理 ID。
3. 操作员 ID。
4. 工具名称。
5. 工具参数。
6. 资源目标。
7. 风险通道。
8. 触发的审批规则。
9. 证据指针。
10. 决策：已批准、已拒绝、自动批准、自动拒绝、已到期或已撤销。
11. 决策时间。
12. 到期条件。
13. 执行后的结果。
14. 回滚或遏制指针。

账本会把审批从一个 UI 事件变成责任记录。它还让团队之后能够提出更好的问题：

• 哪些工具过于频繁地请求审批？
• 哪些操作员最快批准高风险行动？
• 哪些审批规则触发了误报？
• 哪些被拒绝的行动后来找到了安全替代方案？
• 哪些获批行动导致了回滚？
• 哪些粘性授权存活时间过长？

2026年5月那篇操作系统安全论文认为，代理面临的是熟悉的 OS 式问题：资源隔离、权限分离和中介通信。⁷ 审批也属于同一类。执行环境应像操作系统调解特权操作那样调解权限：范围狭窄、行为一致，并留下比请求本身更持久的日志。

简要总结

AI 代理审批需要成为授权对象。暂停并点击的提示可以阻止一次工具调用，但它本身无法承载责任。可用的审批系统会定义执行者、行动、资源、风险、证据、持续时间、到期、撤销和审计。

产品层面的教训很直接：让低风险工作保持安静，让高风险工作明确可见。系统既然可以展示限定范围的行动记录，就不要让人类去批准一段流畅的解释。

FAQ

AI 代理的审批和授权有什么区别？

审批是一次人类决策事件。授权则是在定义条件下允许代理执行具体行动的限定权限。强健的代理系统会把两者连接起来：一次人工审批会生成一条狭窄的授权记录，包含资源、风险、到期、证据和审计字段。

AI 代理的每次工具调用都需要审批吗？

不需要。团队应按风险路由审批。已知范围内的低风险读取可以静默运行并记录日志。中等风险行动可以合并审查。发送消息、发布、删除、部署、花钱、导出或更改权限等高风险行动，应在执行前暂停。

粘性审批对 AI 代理安全吗？

如果范围狭窄、时间短且清晰可见，粘性审批可以有帮助。针对只读工具、限于一次运行的审批是合理的。针对 shell、部署、支付、邮件发送或删除操作的宽泛粘性审批，则会从一次决策中产生过多权限。

AI 代理审批提示应包含什么？

审批提示应包含行动、资源、工具参数、执行者、风险通道、证据、到期时间、回滚路径和审计指针。提示还应提供拒绝、请求证据和拆分范围等决策，而不仅仅是批准。

团队如何降低代理产品中的审批疲劳？

团队可以通过以下方式降低疲劳：在策略范围内自动允许低风险行动，合并中等风险决策，只在提交点中断，展示结构化证据，设置授权到期，并把拒绝记录为正常控制路径。更好的审批会少问含糊问题，多问精确问题。

参考文献