按操作后果设计智能体审批机制

AI Agent 能查资料、生成 SQL，也能发邮件、改权限、部署生产代码。能力越多，越需要回答一个产品问题：哪些步骤可以自动完成，哪些必须停下来让用户确认？作者给出的主张是，审批应跟着行动后果走，而不是每次调用工具都弹窗，也不是用户点过 Start 就一路放行。

这篇文章提供了一套从风险分类、审批预览到执行校验的设计思路。它没有给出团队实验或落地效果数据，但对正在给 Agent 接工具的开发者很有参考价值：确认按钮只是入口，权限和执行规则才决定它能否拦住错误。

哪些操作需要审批，要看做错以后会怎样

作者先划了一条边界：思考与行动应该分开。整理需求、查公开资料、读文档，通常只产生信息；发送外部消息、修改用户权限、部署生产代码，则会改变外部世界。

同样是摘要出错，留在内部供人阅读，影响可能有限；发给 10,000 名客户，后果就完全不同。模型对文本有多自信，不能替代对发送范围的判断。

审批应该跟着行动后果走，而不是跟着模型信心走。

作者建议按风险区分工具操作。公开搜索、读取用户已提供的文件，通常无需反复确认；修改日历、准备数据库更新，需要结合上下文；生产部署、权限变更、外部通信，通常应明确确认。这里的分类是设计起点，具体边界由产品决定。

规模和环境也要进入规则。同样是发邮件，发给一名内部同事与发给 5,000 名客户，需要的控制不同。原文给出了一组示例阈值：

• 操作 1 个临时文件可以自动执行，超过 10 个文件需要审批。
• 操作 1 条测试记录可以自动执行，超过 100 条生产记录需要审批。
• sandbox 中低于 $5 的测试交易可以自动执行，任何真实支付都需要审批。

这些数字是示例，原文没有解释如何定出来，也没有覆盖所有中间区间，不能直接复制成完整策略。

环境规则同样如此：Development 自动执行，Staging 自动执行并记录日志，Production 明确审批。它表达的是生产环境应更谨慎，不代表开发环境的所有动作都天然安全。

用户应该批准最终动作，确认发生在准备完成之后

作者反对过早审批。让 Agent 比较三个监控平台，如果打开网页、继续阅读、比较价格都需要确认，用户很快会厌烦。合理的边界是让它完成研究，等到开通付费订阅或修改生产配置时，再请求批准。

关键做法是把准备与执行拆开。例如数据库更新，可以先分析记录、生成 SQL、计算影响行数，展示完成后再执行。这样，用户看到的是可检查的结果。

审批信息也需要足够具体。原文的邮件示例包含三个要素：使用 support@company.com，向「Trial Expiring」分组中的 126 名客户，发送展示出来的邮件。用户由此能判断操作对象、账号和发送内容，还应知道是否可以撤销。

用户批准的应该是实际提交的数据，而不是一句笼统的任务描述。

批量操作可以减少打扰。按同一规则更新 40 条客户记录，适合展示影响范围后一次审批。前提是操作相似、规则一致，用户能检查受影响对象。不能借批量处理，把更新记录、外发消息等不同意图的动作混在一起。

审批还必须绑定具体参数。用户批准向 Vendor A 支付 $50，不能拿这次批准去向 Vendor B 支付 $500；收件人、金额或消息内容发生重要变化，就应让原批准失效。

即便参数没改，也要在执行前重新校验。原文举例，用户批准删除超过两年未活跃的账号，但可能在提案出现 30 分钟后才确认。系统仍需检查目标记录是否符合条件、权限是否有效、操作是否仍被允许。

确认页面展示过哪些对象，执行时又会影响哪些对象，这条链路必须连得起来。

审批之外，执行层还要有独立约束

让模型判断「这件事危险吗」可以辅助解释，却不该成为唯一防线。作者给出的规则很直接：工具是 delete_database_rows，环境是 production，就要求审批。策略由应用执行，模型负责在边界内完成任务。

工具权限与凭证也要收窄。只读分析任务不应获得完整管理员权限；不同环境使用对应凭证。某些访问还可以限时，例如用户批准共享文件夹访问 30 分钟，流程结束后不再长期保留。

撤销能力可以降低错误成本。更新数据库时保存旧值，外发内容先存成定时草稿，都能为人工检查留下余地。不过，可恢复不等于可以跳过所有确认，仍要看动作后果。

另一个容易被确认界面掩盖的问题是重试。支付请求超时后，Agent 可能不知道交易是否成功。作者建议使用幂等性（idempotency）：为一次动作创建唯一 ID，重试沿用同一个 ID，由接收服务识别重复请求，避免执行两次。这里需要接收服务配合，单靠 Agent 记住一个编号不够。

批量任务还要提前定义部分失败怎么办。100 个操作中只有部分成功，是继续剩余操作、回滚成功项，还是再次请求审批？文章列出了选项，没有给出统一答案，选择取决于业务。

最后是审计与反馈。系统应记录任务发起人、提议内容、执行参数和时间，也应记录拒绝。用户反复拒绝过早发邮件、选择昂贵方案或修改错误字段，可能暴露的是规划问题。

作者还建议观察预览后取消率，以及按工具、风险等级划分的批准率：某类低风险动作若有 99.9% 被立即批准，门槛可能多余；另一类动作若有 30% 被拒绝，审批可能有价值。这些都是判断示例，并非文章公布的测量结果。

我的判断

这套思路最有价值的地方，是把审批从一个弹窗扩展成完整流程：先限制能力，再准备可检查的动作，批准后校验并执行，最后留存记录。对工具调用型 Agent，这比单纯在提示词里要求「危险操作先询问」更容易形成可预测的行为。

但原文整体属于设计经验，没有提供实现代码、对照实验或真实团队数据。「审批越少越有效」也有前提：被放行的动作确实风险较低，用户还能理解剩余提示。高批准率本身无法证明门槛多余，也可能只是用户习惯了直接点击。

几个实现难点也没讲透：消息怎样算「显著变化」，批量目标变化后是否重新审批，审批怎样与执行参数可靠关联。文章能帮助确定检查方向，还不足以直接变成生产系统的规格。

与每一步都确认相比，这种做法保留了自动化效率；与启动时一次授权相比，它让用户在后果明确时再决定。代价是应用必须维护权限、环境、参数和审批状态，不能把这些责任全部交给模型。

能拿来做什么

• 给现有 Agent 的工具列出一张动作表，分别标注只读或写入、目标环境、影响范围和可撤销性，再明确哪些自动执行、哪些需要确认。
• 在前端审批页面展示实际收件人、执行账号、最终内容或受影响记录，并说明触发审批的原因，例如将修改 438 条生产记录，让用户有依据作判断。
• 在 Node 执行层把准备和提交拆开，批准关联到具体参数；提交前重新校验权限与目标状态，重要参数变化后重新申请批准。
• 为支付等可重试动作接入接收服务支持的幂等机制，为批量操作定义部分失败策略，同时记录批准、拒绝和实际执行结果，方便排查和调整规则。