Agent执行前的人审怎样设计，才能核对批准与真实动作？

执行前的人审，应批准一个内容明确、范围有限的动作。审批人看到的收件人、正文、附件或字段变更，要与真正提交给业务系统的参数一致；审批身份、有效条件、拒绝和过期状态也要由执行层检查。只在聊天里问一句“是否同意”，无法说明后台执行的究竟是哪一次、哪一版动作。

这适合已经选定任务、准备让Agent外发邮件、修改记录或进行其他有业务后果动作的团队。先由企业明确哪些动作需要谁批准，再把要求落实到工具执行和验收记录；人工审批本身不会消除资料错误或越权风险。

审批卡先让人看清会发生什么

n8n的工具人审官方文档说明，指定工具可以在调用前暂停，向人展示工具及参数，批准后执行、拒绝后取消。这是一个平台实现参考；企业仍要验证自己部署中的审批者身份、展示内容、执行内容与绕行路径。

把批准绑定到参数，而不只绑定任务名称

建议为待批准动作保留一个稳定请求标识和不可悄悄覆盖的参数版本。审批记录引用该版本；执行前重新核对批准状态、批准者权限和当前待执行参数。可将参数按固定规则转换后计算校验值，辅助比对内容是否变化；校验值不能替代审批人查看真正内容，也不能只比较一句标题。

参数包括容易被忽略的附件内容、实际收件地址、写入目标和商业条件。批准之后若这些内容发生变化，应使旧批准失效并按规则重新申请；不能让模型用“润色一下”悄悄改变已批准承诺。执行层应按已批准版本提交，而不是临时从可变会话里重新生成。

1. 审批前：生成候选动作，做必要校验，冻结供审核的参数与依据。
2. 等待时：保留待审状态，不把“消息送达审批群”记为同意。
3. 执行前：核对身份、权限、参数版本、有效性和对象当前状态；条件变化则停止或重新审批。
4. 执行后：保存外部回执并核对实际结果，将完成、失败或结果未知分别写回。

拒绝、过期与结果未知，要有不同出口

有效期长短由业务条件决定，不宜统一规定多少分钟。报价、交期或库存可能在等待期间变化，即使按钮仍可点击，也应核对批准的前提是否还成立。能否撤销已发送邮件或已发生业务动作，需要按目标系统实际能力判断，不能把“撤回批准”理解成撤销所有后果。

示例：邮件已批准，收件人改变还能发吗

示例（非客户案例）：一份产品说明邮件草稿已获批准，附件是指定版本资料，报价与交期留待业务确认。随后有人把收件人换成另一家公司，同时加入一句交期承诺。这个动作已经超出原批准对象与内容，应停止发送并重新确认。

验收时可在隔离环境准备测试收件箱和模拟客户记录：先批准版本一，再改变收件人、附件或商务条件。检查执行层是否阻止旧批准继续使用。随后分别测试拒绝、过期、权限撤销、重复点击与发送回执丢失；测试通过应以目标系统没有发生未批准动作及记录可对账为依据。

别让同一个动作从另一条路径绕过审批

盘点所有能完成该动作的入口，包括直接工具、子任务、批量路径、恢复任务和人工快捷操作。需要审批的动作应在共同的执行边界校验，不能只在一个页面按钮前拦截。若平台目前只覆盖其中一条路径，应限制开放范围或补控制后再验收。

• 查一条获批记录：能否从审批卡找到实际执行参数、外部回执与最终状态。
• 查一条拒绝记录：是否确实没有触发对应动作，后续重开是否产生新的请求。
• 查一次参数变化：旧批准是否失效，新的批准者看到的是否是新版本。
• 查一次恢复与重复通知：不会重复外发或写入，未知结果先对账。

重试与副作用核对可接着看Agent接口失败后怎样重试、续跑并避免重复执行。无法完成当前任务、需要让人接手处理的流程，则属于带上下文的人工接管，与执行前批准一个动作分别设计。

如果任务已经明确，需要把审批、系统动作和实际结果接到同一流程，可了解企业 Agent 与 AI 项目落地的接入与验收范围，并结合现行授权规则确认实施条件。