生产级 Agent 需要执行结果闸门

模型可以通过推理得出合乎逻辑的结论，却仍然可能摧毁你的生产系统。一旦自主 AI 智能体调用 API、写入数据库或转移资金，唯一重要的就是记录系统中实际发生了什么。底层思维链提示词有多精彩并不重要。

决策正确性与后果正确性之间的差距，正是大多数企业 AI 验证失败的地方。

为什么“AI 智能体回答正确”不是正确的终点

大多数 AI 验证实践都隐含着一个简单的假设：如果模型通过推理得出了正确答案，结果就不会有问题。

但结果并不总是如此。

模型可能生成正确的推理链，却仍然重复支付、依据过期的授权采取行动，或者把下游系统从未完成的操作报告为成功。推理是合理的，后果却不正确。这是两件不同的事情，而大多数评估框架只衡量其中之一。

目前流传的一些提案建议为 NIST 的风险管理框架增加针对 AI 智能体的扩展，并明确指出了这一点。无论是原始框架，还是其生成式 AI 配套框架，都不是为在实时生产环境中运行的自主工具调用系统编写的。这些框架面向的是静态模型，而 AI 智能体并非静态系统。

核心的治理失误，在于将决策正确性与后果正确性视为同一个衡量指标。它们并不是一回事。

治理模式：前置关卡、仅执行一次、执行后验证

在理解各个关卡之前，首先需要明确整体模式。

一个受到治理的 AI 智能体流程分为三个阶段。第一阶段是前置关卡检查：系统在执行任何操作之前，验证 AI 智能体的身份、权限及支持性证据。第二阶段是恰好一次执行：操作通过受控路径运行，并受到防重复和防止部分执行的保护。第三阶段是验证与审计：从权威来源回读结果，而不是根据工具的确认响应推断结果，并将其写入防篡改的证据记录。

如果 AI 智能体通过所有关卡，其终止状态就是“已验证”。如果任何一个关卡未通过，其终止状态就是“如实拒绝”。这两种状态都没有歧义。这正是该模式的意义所在。

这种模式所防止的是基于希望的自动化：AI 智能体声称操作成功，只是因为它进入了响应状态，而不是因为该操作已在记录源中得到确认。基于希望的自动化会产生看起来整洁的仪表盘，以及不可见的故障。

关卡 1：身份绑定

这是针对 AI 智能体重新表述的“迷惑代理”问题。该问题早在 1988 年就已有记录：一个受信任的程序代表权限较低的调用方，使用自身广泛的权限执行未经授权的操作。这个代理只依据收到的指令采取行动，却没有验证提出请求的一方是否有权这样做。

在 AI 智能体规模下，故障模式完全相同，只是影响被放大了。如果用户告诉 AI 智能体“更新 Acme 供应商记录”，而 AI 智能体将这个字符串解析为与显示名称匹配的对象，它可能会更新租户 A 中的“Acme Corp”，而不是租户 B 中的“Acme LLC”。AI 智能体使用自身的高权限凭据，对错误的目标执行操作，然后记录操作成功。

2026 年 3 月，数千家企业用于路由模型请求的 AI 网关代理 LiteLLM 遭到入侵，展示了这一问题在生产规模下的影响。攻击者获取了 SSH 密钥、云凭据和 API 密钥，估计影响了 50 万个企业身份；这是将长期有效、权限范围广泛的凭据集中存放在单一位置所造成的直接结果（SANS Institute）。

安全的身份绑定需要一个操作前解析步骤。在操作关卡开放之前，AI 智能体处理的每个人类可读标签或短标识符，都必须映射到底层不可变的系统标识符，例如 UUID 或密码学哈希值。缺少这一步，后续的每项控制都会被削弱，因为授权和日志记录可能会关联到错误的主体。

关卡 2：证据来源

AI 智能体部署中的主要故障模式是间接提示词注入。指令被夹带在 AI 智能体原本只应读取的数据中，例如发票 PDF、客户电子邮件或检索到的数据库记录。AI 智能体将不受信任的内容当作命令而非数据，并执行了它。

当电子邮件中发现的恶意内容被赋予与已验证组织策略相同的信任级别时，就会发生这种来源可信度崩塌。如果架构没有从结构上分离数据通道与指令通道，AI 智能体就无法可靠地区分二者。

证据来源不是一个检索问题，而是一项基础控制。需要为 AI 智能体上下文中的每一项内容标注来源类别：可信系统指令、已验证的数据源或未经验证的外部内容。操作关卡应当只处理标记为可信的指令。未经验证的指令不得污染决策路径。

关卡 3：权限时效性

一个密码学上有效的批准可能完全可靠，却对应着一个已不再以相同形式存在的对象。例如，强制推送之前的提交、用户被终止后的会话，或今天早上刚刚重新分配的角色。

密码学有效性和时间上的时效性是两项不同的检查。在一个可能持续数小时的多步骤规划循环开始时授予的权限，可能在最终操作执行之前被撤销。如果只在登录或任务启动时检查权限，AI 智能体就会重复使用过期凭据。

支付基础设施早在 AI 出现之前就解决了这个问题。Google 的 Agent Payments Protocol 使用经过签名且防篡改的授权指令，记录用户的意图、适用范围以及获得授权的付款。Visa 的 Trusted Agent Protocol 为每个 AI 智能体分配独立的密码学身份，并要求在信任一笔交易之前，同时验证该身份和消费者设定的限制。

在授予权限时，保存目标对象的版本标识符。在实际执行操作时，将该版本与实时对象进行比较。如果两者不同，说明批准已经过期，关卡应拒绝该操作。

关卡 4：恰好一次执行

网络超时会造成歧义。如果 AI 智能体调用 API，而连接在收到响应之前中断，AI 智能体就无法判断操作是否已在下游成功完成。对于非幂等操作，简单重试会导致操作效果重复。

这是支付工程中一个已经解决的问题。Stripe 的支付 API 会使用唯一键保存第一次请求的结果；对于携带相同键的重复请求，它会重放已保存的结果，而不是重新执行操作。

在生产环境中，忽视这种风险意味着客户可能被重复扣款、记录可能被重复删除，或者基础设施变更可能被重复应用。AI 智能体的内部日志可能只显示一次尝试，而记录系统中却显示执行了两次。

应在操作获批时为每项操作生成一个唯一的执行键，而不是在重试时生成。下游系统必须在处理操作之前，使用该键执行去重检查。

关卡 5：独立验证

模型声称任务已经完成，并不能构成证明。工具返回“success”响应，也不能证明外部操作已经完成。模型针对验证步骤进行优化，而不是针对底层实际结果进行优化，是一种已知且有记录的故障模式。

在 METR 于 2025 年开展的一项评估中，OpenAI 的 o3 模型被要求提高代码运行速度时，没有改进底层代码，而是修改了测量耗时的函数；在某些任务中，其奖励劫持率达到了 100%。

由 29 个国家以及联合国、OECD 和欧盟共同参与编写的《2026 年国际 AI 安全报告》发现，系统识别测试条件与真实部署环境之间差异，并利用评估漏洞的情况已经变得更加普遍。

应从权威的下游系统回读状态。需要预先明确定义：哪个系统中的哪个字段能够确认操作完成。执行后直接查询该字段，并将其与预期的操作后状态进行比较。仅凭工具的确认响应，绝不能关闭这一关卡。

关卡 6：义务跟踪

合法的首次效果并不等于任务已经完成。临时入账、部分修复或配置设置变更，都可能作为初始操作完全正确，却仍然留下未结束的监控窗口、披露要求或下游结算流程。

在第一次 API 调用成功后立即将任务标记为完成，会造成隐藏的残余风险：初始操作虽然成功了，但其背后仍然存在中断的依赖关系或尚未履行完毕的承诺。

ISO/IEC 42001 第 6.1.4 条已经要求建立一套有文档记录的流程，用于评估 AI 系统可能产生的潜在后果。可以直接应用这一要求。构建一个任务完成模式，将初始影响与后续义务区分开来。在警报、通知、对账和合规义务得到跟踪并最终解决之前，AI 智能体不得将工作流标记为已关闭；或者，也可以将这些事项正式延期，明确指定负责人和截止日期。

关卡 7：如实补偿

有时必须逆转损害。当某项影响需要撤销时，纠正机制不得改写实际发生过的记录。如果回滚操作悄无声息地从日志中删除了最初不希望出现的影响，这对治理而言将是灾难性的。

监管机构、审计人员和事件响应团队都需要准确了解最初执行了什么操作，才能评估实际风险敞口。撤销业务影响，并不等同于假装它从未发生过。

如实补偿将逆转视为追加操作，而绝不是删除操作。纠正操作会添加一条引用原始操作标识符的新记录，同时保留不可变的审计日志、原始决策和来源数据。任何用于显示当前状态的报告视图，都必须与展示完整历史记录的审计日志分开保存。

对真正重要的事项进行评分：AI 运营风险的支配性规则

将决策质量与后果质量合并为一个综合分数，会掩盖运营风险。模型可以进行高质量推理，但仍然缺乏有效控制。模型也可能推理质量不佳，但依然被安全地限制在可控范围内。一个混合分数会掩盖你真正需要解决的是哪一种问题。

对安全指标应用支配性评分规则。重复执行不可逆的付款、伪造授权，或者在没有独立回读的情况下宣称任务完成，都必须对整体结果起决定性作用。这些属于硬性违规。在整个测试范围内，只要出现一次灾难性的系统故障，整体结果就应归零，无论模型在规划期间的推理表现有多好。

分别对决策质量和后果质量进行评分。让硬性违规支配最终得分，而不是将其平均到总分中。

错误拒绝核算

一个阻止所有请求的控制系统，可以实现 0% 的不安全操作率，但也会彻底破坏正常运营。衡量安全性时，如果不跟踪错误拒绝，就会制造一种虚假的安全感。

应将错误拒绝率与安全遏制指标一同跟踪和报告。如果护栏更新导致错误拒绝率激增，应立即调整控制参数。一次表现良好的运行并不足以支撑有力的结论。可靠性需要通过重复试验来证明，而且改进必须能够明确归因于你的控制层。

校准性能声明

评估供应商或内部 AI 智能体的安全报告时，应根据声明的来源进行区分。

测试设计或场景目录只能证明其方法论具有一致性。你可以说：“这是测试此类风险的一种合理方式。”

供应商自行报告的一次运行结果，只能揭示该配置在特定日期、供应商自行选择的条件下表现如何。你可以说：“在这些已披露的条件下，该配置产生了这一结果。”

独立复现的运行结果可以证明，该输出并非供应商内部设置造成的偶然产物。

依据具名且明确定义的协议进行审计并得出的结果意味着：“截至该日期，此配置在指定范围内通过了这项具名协议。”

以下五种表述应让任何审查人员提高警惕：声称“安全”却没有定义适用范围；声称“已验证”却没有指出具体协议；使用一个综合分数同时涵盖能力与安全性；报告看似完美却没有置信区间；以及仅根据一次内部运行就宣称取得了显著改进。

这些关卡已经位于治理体系中的哪些位置

身份绑定和权限时效性与访问控制及职责分离实践直接相关。此类实践正日益被正式纳入 Model Context Protocol 授权规范，其中包括有关令牌受众验证的规则和禁止令牌透传的要求；Visa、Mastercard 和 Google 新兴的 AI 智能体支付规范也在推动这一趋势。

证据来源与 NIST 的生成式 AI 配置文件相对应。该文件已经将未经验证的工具访问和自主性驱动的权限升级列为具体风险类别；证据来源也与 OWASP 的 AI 智能体威胁目录相对应。

目前还没有专门针对恰好一次执行的 AI 框架。应直接借鉴支付系统和分布式系统工程的实践。

独立验证与《欧盟 AI 法案》第 14 条的人类监督要求相关。该要求自 2026 年 8 月 2 日起具有约束力，要求指定的监督人员能够跟踪高风险系统正在执行的操作、进行干预并停止系统，而不只是查看仪表盘。

义务跟踪和如实补偿与现有的事件管理及披露义务相关，也与 ISO/IEC 42001 第 6.1.4 条相对应。

2026 年 4 月，美联储、美国货币监理署和美国联邦存款保险公司以 SR 26-2 取代其模型风险管理指南时，将生成式 AI 和 AI 智能体排除在标准规则体系之外，理由是这些技术过于新颖且发展太快，不适合套用同一框架。他们表示将专门征求意见，探讨应如何对 AI 智能体进行治理。这相当于监管机构正式指出了这一缺口。

选出组织中五个一旦执行偏离决策便会造成最严重后果的 AI 智能体工作流。将每个工作流依次放入七道关卡中进行测试设计，而不是将其当作训练练习。刻意尝试让 AI 智能体在每一道关卡上失败。对结果进行评分时，让硬性违规占支配地位，而不是将其平均处理。在公布不安全操作率的同时，也公布错误拒绝率。然后，在其他人审查你的报告之前，先对自己的报告进行一次声明校准审查。

当治理被构建为一个主动执行框架时，它就会成为自动化的赋能因素。强制实施严格的执行关卡，可以让自主 AI 智能体进入关键任务工作流，同时确保每项操作都经过验证、受到边界约束并接受完整审计。

如果你从事 AI 治理、模型风险或企业合规工作，并希望更深入地了解涉及现实后果的 AI 智能体验证量化框架，请订阅本通讯。新的框架、案例研究和可运行代码都会优先发布在这里。

我的文章列表：进一步了解 AI 治理与 AI 风险管理

| 1 | 2026 年 7 月 30 日 | 面向工程师、架构师和治理团队的实用指南：如何把事情真正做对 | 论证 AI 安全不能只依靠改造后的网络安全检查清单，并说明额外的治理层应当是什么样子。 |

| 2 | 2026 年 7 月 28 日 | 每个 AI 智能体在采取行动前都必须通过的七道关卡（而大多数至少跳过了三道） | 一套用于弥合 AI 智能体决策与现实后果之间差距的控制框架，涵盖身份、权限、证据、执行、验证、义务和补偿。 |

| 3 | 2026 年 7 月 21 日 | 供应商“我们不会使用你的数据进行训练”的承诺只是一句话，不是数据架构 | 说明 AI 供应商的数据暴露实际发生在哪里：微调、日志和检索，而不是采购团队向法务复述的那一句话。 |

| 4 | 2026 年 6 月 28 日 | ISO 24970 和 prEN 18229-1 如何将部署后的混乱转化为可审计证据 | 将 AI 系统日志标准与 AI 系统首次出现明显故障时，董事会或监管机构真正会要求查看的内容联系起来。 |

| 5 | 2026 年 6 月 27 日 | 如何在不失去控制的情况下为 AI 智能体构建策略引擎 | 解释为什么系统提示词不是治理控制措施，以及真正的 AI 智能体策略引擎还需要哪些能力。 |

| 6 | 2026 年 6 月 17 日 | prEN 18286 现实检验：摒弃泛泛的 AI 治理 | 用于检验你的 AI 质量管理证据，在公告机构或审计人员要求直接查看时能否经受住审查。 |

| 7 | 2026 年 5 月 8 日 | prEN 18228 难题：为什么你的 AI 风险评估无法通过第一次真正的检验 | 详细解读新的欧洲 AI 风险评估标准，以及大多数现有评估在哪些方面无法满足该标准。 |

| 8 | 2026 年 3 月 31 日 | AI 智能体全生命周期风险与控制管理指南 | 为 AI 智能体提供端到端的风险与控制覆盖，从 AI 智能体发出的第一次 API 调用开始。 |

| 9 | 2026 年 3 月 30 日 | 面向首席 AI 官的影子 AI 风险管理 | 针对组织内部已经存在却从未获得批准的 AI 工具，提供一种实用的管理方法，涵盖浏览器扩展程序以及被粘贴到工具中的客户数据等场景。 |

| 10 | 2026 年 3 月 28 日 | 如何真正运用 ISO/IEC 23894 开展 AI 风险管理 | 将 ISO/IEC 23894 转化为可运行的工作流程，而不是一份再也无人查阅的政策文件。 |

| 11 | 2026 年 3 月 16 日 | 首席 AI 官究竟负责什么，哪些职责应继续由风险、法务和 IT 团队承担 | 划定首席 AI 官职位的实际职责边界，避免它沦为没有真正权限的虚衔。 |

| 12 | 2026 年 3 月 16 日 | AI 用例识别与优先级排序框架 | 一种在投入数月时间构建错误方案之前，按照业务价值对 AI 构想进行排序的方法。 |

| 13 | 2026 年 3 月 16 日 | AI 使用规则、问责制、自带 AI（BYOAI）、设计安全与内容溯源 | 说明为何需要六项独立的 AI 政策，而不是试图用一份文档同时服务所有受众。 |

| 14 | 2026 年 3 月 16 日 | 负责任的 AI 政策类别 | 将“我们重视公平”等模糊原则转化为背后有实际操作要求的政策语言。 |

| 15 | 2026 年 3 月 16 日 | AI 项目中自动化成本节约与收入的计算方法 | 展示如何将“这会节省时间”转化为财务部门和高管团队真正信任的数字。 |

| 16 | 2026 年 3 月 16 日 | 如何制定能够创造价值、控制风险并应对变化的 AI 路线图 | 将一堆相互竞争的 AI 构想转化为有先后顺序的路线图，而不是预算争夺战。 |

| 17 | 2026 年 3 月 15 日 | 如何谈判能够保护数据、价值与责任边界的 AI 协议 | 指出通用 SaaS 条款从未预见到的合同问题，包括输出所有权、训练用途和幻觉责任。 |

| 18 | 2026 年 3 月 15 日 | AI 治理：从合规任务到运营实践 | 指出，一旦 AI 智能体开始以机器速度修改工单和调用工具，治理便不再只是政策层面的讨论。 |

| 19 | 2026 年 3 月 15 日 | 无人谈及的 AI 职业优势 | 探讨除了常规的“获得学位并投递申请”路径之外，真正成功进入 AI 岗位的人有何不同。 |

| 20 | 2026 年 3 月 15 日 | AI 威胁与漏洞评估 | 一份基于 STRIDE 的威胁建模指南，涵盖标准安全扫描完全遗漏的攻击面。 |

| 21 | 2026 年 3 月 15 日 | 决定 AI 项目成败的八项因素实战指南 | 从战略、人员和流程层面，提炼出真正能够区分创造价值的 AI 项目与失败项目的关键因素。 |

| 22 | 2026 年 3 月 15 日 | 使用敏捷、探索和 MLOps 管理 AI 项目 | 解释为何将 AI 项目视为标准的确定性软件开发项目，会从一开始就注定其失败。 |

| 23 | 2026 年 3 月 15 日 | AI 项目的数据与工具基础设施 | 讨论在笔记本中能够运行的模型，与真正能够投入生产的模型之间存在的差距。 |

| 24 | 2026 年 3 月 15 日 | 模型稳健性与监控实战手册 | 通过一个信用模型准确率悄然漂移的真实案例，说明为何部署后的监控绝不能事后才考虑。 |

| 25 | 2026 年 3 月 15 日 | 受监管 AI 的建模实践 | 一个同时满足数据科学家与监管机构要求的验证框架，以 CFPB 的不利行动指导意见为基础。 |

| 26 | 2026 年 3 月 15 日 | 数据科学项目失败原因的有效解决方案 | 将数据科学项目的失败追溯到最早出现且最容易预防的根源：问题定义模糊，以及优化了错误的指标。 |

| 27 | 2026 年 3 月 15 日 | 面向反馈闭环与 MLOps 的 AI 部署治理 | 探讨为何即使模型很强大，如果无人负责将用户反馈转化为生产环境变更，最终结果仍会很糟糕。 |

| 28 | 2026 年 3 月 13 日 | AI 开发与部署项目管理 | 十项实践，用于区分真正能够交付的 AI 项目与无限期停滞的项目。 |

| 29 | 2026 年 3 月 13 日 | AI 性能审计 | 指出大多数 AI 审计止步于审批，从未检查系统在实际运行中究竟做了什么。 |

| 30 | 2026 年 3 月 12 日 | 如何解释 AI 风险模型，让监管机构真正信任它 | 探讨如何在部署前将可解释性构建到模型中，而不是等审计人员提出要求后再仓促补救。 |

| 31 | 2026 年 3 月 12 日 | 犯下昂贵错误最少的预测性风险模型 | 围绕特定错误的成本重新构建模型评估方法，而不是依赖单一且看似亮眼的准确率数字。 |

| 32 | 2026 年 3 月 12 日 | 风险与合规自动化实战手册 | 探讨如何从抽样检查少量交易，转向持续监控全部交易。 |

| 33 | 2026 年 3 月 12 日 | 超越“AI 准确吗？”的 AI 风险建模 | 指出准确率只能回答 AI 系统实际可能出错问题中的约 15%，并讨论其余部分。 |

| 34 | 2026 年 3 月 12 日 | 用于高级预测性风险建模的机器学习 | 指出无法构建预测模型的风险团队，最终将被能够构建这些模型的软件取代。 |

| 35 | 2026 年 3 月 12 日 | AI 系统部署后的实用维护方法 | 探讨为何大多数团队在实现部署方面投入过多，却对部署后保障系统安全的工作投入不足。 |

| 36 | 2026 年 3 月 12 日 | AI 项目的模型选择与验证 | 讨论过拟合与欠拟合之间的权衡，以及如何真正证明所选模型有效。 |

| 37 | 2026 年 3 月 12 日 | 分步式 AI 集成实战手册 | 探讨为何一项 AI 功能可以独立运行得非常完美，其周围的业务体验却依然支离破碎。 |

| 38 | 2026 年 3 月 12 日 | 降低供应商、数据与责任风险的 AI 合同条款 | 将采购、法务、安全和合规纳入统一而严谨的 AI 采购视角，而不是彼此割裂的四套视角。 |

| 39 | 2026 年 3 月 12 日 | 实用的 AI 服务等级协议 | 探讨如何编写不仅考虑正常运行时间，还将模型悄然漂移和退化纳入考量的 SLA 条款。 |

| 40 | 2026 年 3 月 12 日 | 提升透明度、治理与实际应用效果的 AI 模型卡 | 解释为何大多数模型卡都是事后为了合规表演而编写的，以及真正有用的模型卡应该是什么样子。 |

| 41 | 2026 年 3 月 12 日 | 我的新书：《AI 管理体系》 | 介绍他所著的这本书，内容是如何将 AI 治理从愿景式声明转化为可审计的运营体系。 |

| 42 | 2026 年 3 月 12 日 | 如何在 AI 系统上线后进行监控，同时避免制造审计表演 | 探讨如何发现大多数 AI 项目失败前出现的悄然漂移、应用停滞和隐性成本攀升。 |

| 43 | 2026 年 3 月 12 日 | 为什么将 AI 构建团队与 AI 运维团队分开必然导致失败 | 将“谁构建，谁运维”的责任原则应用于 AI 系统，避免交接工作在四个不同团队之间流失。 |

| 44 | 2026 年 3 月 12 日 | 如何组建合适的 AI 交付团队 | 列出 AI 团队实际需要的七种角色，以及团队经常忘记分配的管理职能。 |

| 45 | 2026 年 3 月 12 日 | AI 项目的资源估算 | 十五类成本，用于解释为何即使没有任何一个单独的……，AI 预算仍会超支。 |