Agent 的外部动作必须按损害设置确定性验证门

当 agent 从“回答问题”走向“替人行动”，风险的中心就变了。最危险的部分往往不是它说错一句话，而是在缺少确定性验证的情况下，把错误动作真正落到外部系统里。

发消息、退款、调用 API、重试支付、旋转凭证、修改权限，这些动作一旦发生，就不再只是文本质量问题。它们会改变业务状态、影响用户、触发财务风险，甚至扩大权限边界。此时再把安全寄托在 prompt、身份声明或模型自觉上，已经不够。

生产系统真正需要问的，不是“这个 agent 是否可信”，而是“这个动作如果失败、误触发或被诱导执行，会造成多大损害”。

读一段日志、发一条公开消息、执行一次退款、改动支付配置、轮换生产凭证，不应该共用同一套验证强度。动作越不可逆，涉及金额越高，权限范围越宽，公开影响越大，验证门就越应该从模型判断切换到确定性规则、显式授权和可审计证据。

这也是很多 agent 安全讨论容易跑偏的地方：安全边界不应围绕“模型形象”来设计，而应围绕外部动作来设计。身份、授权、验证、审计和损害上限必须分层，否则任何一个“看起来可信”的 agent 都可能把错误扩散到真实业务系统。

模型可以参与解释意图、整理上下文、提出动作建议，但不能单独决定高风险外部动作是否执行。

原因很简单：prompt 是可变的，模型输出也是概率性的。它们适合做语义判断和辅助决策，却不适合承担最终放行动作的责任。尤其在支付、退款、权限、凭证、生产配置这类场景里，最终执行权必须交给系统级 gate。

这些 gate 至少应回答几个问题：

这不是给 agent 套一张抽象规范，而是把每类动作拆成可验证、可授权、可审计、可限损的执行协议。

很多系统会把重试看作工程可靠性问题，但在 agent 执行外部动作时，重试本身就是安全设计的一部分。

读取失败后重试，通常只影响延迟；支付、发消息、提交工单、调用第三方 API 后重试，则可能放大副作用。一次误触发可能变成多次扣款、多条消息、多个工单，或者让外部平台把系统判定为异常流量。

因此，高风险动作不能只有“失败后自动重试”这一个策略。它需要幂等键、执行回执、状态确认、重试上限、人工接手点，以及对“动作是否已经发生”的独立证据。否则系统会在不确定状态下继续行动，把一次故障扩大成连锁事故。

更实用的方式，是按动作类型建立风险分层，而不是给所有 agent 统一套一层安全口号。

读取类动作重点关注访问权限和数据最小化。公开表达类动作重点关注身份、内容确认和撤回成本。交易类动作重点关注金额阈值、幂等性、风控规则和人工确认。凭证与权限类动作则应要求强授权、变更窗口、回滚方案和完整审计闭环。

这种分层会让安全策略真正影响每一次执行，而不是停留在文档里。低风险动作可以保持轻量，高风险动作必须被硬 gate 拦住，直到证据、授权和上下文都满足要求。

agent 安全的第一原则，不是让模型更“守规矩”，而是让外部动作被系统性地约束。

模型可以提出建议，可以解释理由，也可以帮助整理证据。但动作是否真正发生，尤其是会带来金额、权限、公开影响或不可逆后果的动作，必须由确定性验证门接管。否则 agent 越能干，系统风险越高。

龙虾升职记