AI Agent 策略检查：Proposal Envelope 设计模式

AI agent 在商业场景中开始发挥作用，恰恰也是它们开始变得有风险的时刻。

阅读一份文档，风险很低。起草一封回复，通常在可控范围内。但发送回复、修改 CRM 阶段、退款给客户、编辑账单记录、邀请用户、删除文件，或公开发布内容，就完全不同了。这些操作会超出工作空间的范围，并对业务产生影响。

这就是为什么围绕 agent 的操作层和 agent 本身同样重要。一家企业不仅需要智能，还需要一种可重复的方式，来决定某个 AI 提议的动作是被允许、需要审批、必须阻止，还是因为状态发生变化而需要重新检查。

我反复回到的一个模式是 proposal envelope（提议信封）。

什么是 proposal envelope？

proposal envelope 是 AI agent 在修改业务系统、发送外部消息、触碰资金、更新权限，或做出公开承诺之前，必须产出的一份结构化记录。

它将精确的提议动作、来源证据、风险等级、审批负责人、过期时间、幂等键、回滚路径和日志目的地打包在一起，供人类或策略层在动作产生副作用之前进行审查。

流程如下：

agent output
-> proposal envelope
-> policy check
-> approval inbox
-> state re-check
-> action
-> evidence log

agent 仍然可以处理混乱的上下文，仍然可以准备有用的工作。但在一个操作产生副作用之前，它必须产出一份结构化的提议，供另一层进行检查。

为什么这在真实工作流中很重要

大多数早期的 agent 工作流都是从小型实验起步的。

创始人让 agent 起草邮件。团队加入一个 Slack 审批步骤。CRM 工作流增加了一个条件。客服自动化在出现退款相关词汇时暂停。账单异常发给邮件。公开发布的内容在文档中等待。

每条规则单独看可能都是合理的。问题在于审查系统变得分散了。

没有人能轻易看到：

• 哪些提议正在等待
• 哪些审批已过期
• 哪些操作已经执行
• agent 使用了哪些证据
• 另一个工作流是否触碰了同一条记录
• 审批之后业务状态是否发生了变化

这就是一个获得授权的 AI 工具仍然可能表现得像影子 AI 的原因。应用可能获得了批准，但具体的交互行为并没有被治理。连接器存在，但工作流没有一份共享的策略契约。

envelope 应该包含什么

一个有用的 proposal envelope 包括：

• Actor（执行者）：哪个 agent、工作流、用户或调度任务请求了这个操作
• Goal（目标）：这个操作应该推进哪个业务目标循环
• Target system（目标系统）：Gmail、CRM、账单、日历、文件存储、Slack、Discord 或其他工具
• Exact action（精确操作）：具体的消息、更新、记录变更、邀请、发布或要创建的任务
• Affected record（受影响的记录）：被操作触及的客户、潜在客户、发票、文档、对话、账户、项目或频道
• Source evidence（来源证据）：agent 使用的邮件、文档、笔记、策略、工单或记录
• Risk class（风险等级）：低、需审查、敏感、阻止，或企业定义的自定义级别
• Approval owner（审批负责人）：有权批准该提议的人员或角色
• Expiry time（过期时间）：审批何时失效
• Idempotency key（幂等键）：防止重复发送、重复更新或重复退款的键
• Rollback path（回滚路径）：什么可以撤销、什么不能撤销、有什么缓解措施
• Log destination（日志目的地）：最终决定、证据和结果应该记录在哪里

这比一条模糊的"agent 想更新某些东西"的通知要容易审查得多。

策略检查应该决定什么

策略检查应该是枯燥的。这恰恰是它的特点。

它的职责不是重新思考整个业务问题，而是对提议进行分类并决定下一步：

• Allow（允许）：安全、可逆、在范围内、影响低
• Require approval（需要审批）：面向客户、财务、公开、涉及权限或模糊的情况
• Deny（拒绝）：超出工具范围、缺少证据、不支持的声明、禁止的操作或不安全的目标
• Escalate（升级）：需要指定负责人、法务审查、创始人审批、经理审批或手动处理
• Ask for more context（请求更多上下文）：因为缺少或过时而无法判断的提议

决策应该附带原因。审查者应该知道工作流是因为缺少证据、客户影响、资金流动、公开可见性、策略不匹配还是状态过期而暂停的。

审批收件箱不仅仅是通知

真正的审批收件箱是一个提议副作用的队列。

每个条目应该展示将要发生什么、为什么 agent 认为应该发生、哪些记录受到影响、使用了哪些来源、谁可以批准，以及提议何时过期。审查者不需要从头重建整个对话线程。

这很重要，因为审查时间是 AI 的隐性成本。一份节省五分钟但需要十分钟事实核查的草稿，并不是改进。

审批收件箱应该通过携带证据和约束条件来加快审查者的速度。

状态重新检查防止审批过时

审批只在特定的业务状态下有效。

如果客户在审批后回复了，批准的后续操作可能是错误的。如果价格已经变动，旧的续订草稿可能是错误的。如果另一个工作流已经更新了 CRM 记录，重试可能会创建重复任务。如果库存发生了变化，履约消息可能不再准确。

在执行之前，工作流应该重新检查仍然必须为真的最小状态：

• 目标仍然是活跃的
• 受影响的记录没有发生冲突性变更
• 审批没有过期
• 提议仍在批准的范围内
• 幂等键尚未被执行
• 来源证据对于该操作仍然足够新

这是许多 agent 演示在真实运营中失败的地方。演示展示的是一个操作。企业需要操作在运行时刻仍然是正确的。

确定性工作流工具的位置

工作流自动化工具非常适合确定性管道：触发器、转换、Webhook、重试、路由、记录更新和定时任务。

proposal envelope 模式并不与这些竞争。它在确定性部分执行之前，给 AI 部分一个契约。

一个实用的设置可能是这样的：

workflow trigger
-> AI drafts proposal
-> policy check
-> approval inbox
-> workflow executes approved action
-> log result

这种分离很重要。工作流不应该要求 agent 在每个步骤上即兴发挥。

agent 处理复杂的判断：客户是什么意思、适用哪个策略、应该提议什么操作，以及什么证据支持它。工作流在提议被允许或批准后处理可靠的执行。

一个具体例子：续订邮件

假设一家小型 SaaS 公司希望 agent 帮助挽回有流失风险的续订。

agent 审查账户笔记、工单、使用量、账单状态和最新的人类消息。它判定应该向一个客户发送包含拟议支持方案的挽留邮件。

不直接发送，agent 创建一个 proposal envelope：

• Goal（目标）：降低活跃客户账户的流失风险
• Target（目标）：Gmail 和 CRM
• Action（操作）：发送一封特定的续订邮件并创建一个 CRM 后续任务
• Evidence（证据）：最近的客服对话、使用量下降、续订日期、账户所有者的备注
• Risk（风险）：需要审查，因为消息涉及服务承诺
• Re-check（重新检查）：如果客户已回复、续订状态已变更，或已存在其他任务，则不发送
• Log（日志）：将最终邮件、审批决定、证据和结果保存到账户时间线

这是可审查的业务执行。agent 做了有用的工作，但人类审批的不是黑盒。他们审批的是一个有证据和边界支撑的具体副作用。

在 agent 接触实时系统之前的检查清单

• 定义哪些操作类型是低风险、需要审查、敏感或被阻止的
• 在任何外部副作用之前要求 proposal envelope
• 将 proposal envelope 路由到一个审批收件箱或共享审查契约
• 为审批添加过期时间
• 对发送、记录更新、退款、邀请和任务创建使用幂等键
• 在执行前立即重新检查状态
• 记录提议、证据、策略决定、审查者、操作结果和失败状态
• 用完成的目標循环来衡量成本和结果，而不是用 agent 运行次数

如果这些要素缺失，下一个改进不是更强大的 agent。下 一个改进是围绕 agent 建立更好的操作契约。

在 Manor AI，我们正在围绕以下内容设计工作空间层：agent、skill、context、审批门控、策略检查、证据日志，以及使业务执行可审查的目标循环。

Originally published on the Manor AI blog: https://manorai.xyz/blogs/blog-ai-agent-policy-checks-proposal-envelope