n8n Agent 执行前审核：让审批人看见具体工具和参数

先挑出需要审核的动作 读取公开资料与修改记录的影响不同。可以先按工具列出动作、目标对象和是否容易撤回，再决定哪些调用需要人工确认。n8n 官方支持对所有工具或特定工具添加审核，因此没有必要仅因为流程包含 Agent 就把所有读取步骤逐一阻塞。 审核放在执行之前 官方描述的流程是：Agent 决定调用工具，工作流暂停并发出审核请求；批准后执行 AI 指定的参数，拒绝则取消该动作并把拒绝告知 AI。这个位置很关键：如果只是等执行完成后审核聊天回复，外部状态可能已经改变。 让审批信息足够具体 Human review 中可使用 $tool.name 和 $tool.parameters，后者包括通过 $fromAI() 决定的输入。编辑建议在审批信息中展示目标、关键字段和动作范围，使审批人能判断这一笔请求实际会做什么，而不是只看到“是否允许使用工具”的宽泛提示。 把一次批准绑定到具体对象 以自拟的客户标签更新为例，审核信息至少展示“为 C02 添加 follow_up 标签”，而不只是“允许更新客户”。如果工具参数由 AI 填入，可在审核消息中显示 {{ $tool.name }} 与 {{ JSON.stringify($tool.parameters, null, 2) }}，再补上工作流中可信的目标系统与固定字段。 $tool.parameters 不能被想当然地当作所有运行时配置的完整副本。涉及固定目标、凭据代表的账号或工具内部默认范围时，应把会影响这次动作的内容另外说明。否则审核人可能确认了标签，却不知道改的是测试库还是正式客户库。 参数变化后，原来的批准也不能自动代表新动作。测试时先拒绝 C02 的请求，再让用户改为 C03，核对新的审核明确显示 C03；不能复用旧批准记录，也不能只在聊天里改口而执行仍使用旧参数。这里的客户与标签都是演示对象。 配置路径与交互渠道 在 AI Agent 的 Tools 面板中选择 Human review，配置审批渠道，再把需要审核的工具接到审核步骤。官方允许审批渠道与用户聊天渠道不同，例如用户通过聊天入口提问，而特定维护者在另一渠道审核。配置后应确认请求确实送给负责这类动作的人。 拒绝也是正常结果 官方要求在系统提示中说明哪些工具需审核，以及被拒绝后如何回应。编辑建议把拒绝视为有意义的状态：告知用户本次动作未执行，说明可修改的条件，等待新的明确请求。不要用自动重试把拒绝当作临时网络失败。 分别测试批准与拒绝 先用专门的测试对象发起一条小范围调用。批准时核对执行参数与审批展示一致；拒绝时核对目标状态没有改变，并观察 Agent 是否准确说明结果。还可测试缺少必需参数的情况，确保审批人不会被要求批准一条内容尚不完整的动作。 还应核对“已批准”和“执行成功”的区别。批准只是允许工具开始，目标服务仍可能拒绝、超时或返回业务错误。完成回复应根据工具真实结果生成；审核通过后工具失败，就说明未完成或状态待确认，而不是给用户一条成功通知。若请求超时后无法确定是否已写入，应查询目标状态再安排恢复，避免第二次审核后重复写入。 上线后的维护 新增工具或改变输入结构后，重新核对审核连接和展示字段。工具名称相同并不意味着它仍然只做原来的事情。每次改动都在团队的测试流程中核对批准与拒绝结果，再用于实际动作。

本篇涉及的工具1

n8n

在指定工具调用前展示参数并请求审核

适合场景

准备让 n8n Agent 调用写入或发送类工具、希望保留具体动作审核的团队。

需要留意

批准、拒绝和参数展示均需在真实连接中验证。

了解项目 访问官网