n8n AI 工作流失败怎么监控？用 Error Trigger 留下执行线索

n8n AI 工作流失败时，可以用一个以 Error Trigger 开头的错误工作流，保存失败流程、最后执行节点、错误消息和可用的执行链接。先把失败线索留全，才能判断问题发生在模型、工具还是前面的数据处理。

本文面向已有 n8n AI 流程的维护者，配置依据为 2026 年 10 月 1 日读取的官方文档。没有在读者的实例中执行，也不展示线上故障统计。下面的失败演示应建在单独的测试工作流中，不改正在服务用户的正式流程。

先分清手动测试与自动失败

Error Trigger 官方文档明确：它在关联工作流自动运行并失败时触发，不能靠手动点击主流程 Execute workflow 验证错误工作流。错误工作流本身无需发布；需要自动触发的是产生失败的主测试流程。

这也解释了常见情况：编辑器里模型节点报错了，错误工作流却没有执行。先核对执行模式，再查 Error workflow 是否选对，不要马上判定错误处理失效。

建立 Error Handler 并保存最小记录

1. 新建工作流，命名为 AI Error Handler Demo。
2. 添加 Error Trigger 作为第一个节点，后面连接 Code。
3. Code 选择 JavaScript、Run Once for All Items，粘贴下面代码。
4. 在该错误工作流的 Settings 中确保成功的生产执行会保存；这样处理器成功后，仍能从它的执行详情看到记录。保存工作流。

return $input.all().map(item => {
  const d = item.json;
  const e = d.execution ?? {};
  const t = d.trigger ?? {};
  return {
    json: {
      recorded_at: new Date().toISOString(),
      workflow_id: d.workflow?.id ?? null,
      workflow_name: d.workflow?.name ?? null,
      execution_id: e.id ?? null,
      execution_url: e.url ?? null,
      last_node: e.lastNodeExecuted ?? t.error?.node?.name ?? null,
      message: e.error?.message ?? t.error?.message ?? "未提供错误消息",
      mode: e.mode ?? t.mode ?? null,
      retry_of: e.retryOf ?? null
    }
  };
});

执行 ID 和 URL 不是每次都有。错误处理文档说明，它们要求执行保存在数据库；触发器本身失败时，还可能根本没有主执行记录。上述代码把缺失字段保留为 null，并兼容 execution.error 与 trigger.error 两类结构。

保存选项见 工作流设置文档中的 Save failed production executions 和 Save successful production executions。若实例管理员强制执行数据脱敏，节点输入输出可能不可见；这时应通过有权限的管理者核对记录，不把看不到字段直接解释为未触发。

不要把完整输入、请求头或错误堆栈直接发送给外部接收方。本例只在执行详情中保留必要线索；如果错误消息本身带有敏感数据，也应在进入通知系统前脱敏。

把已有 AI 流程关联到处理器

打开要监控的工作流，进入 Options → Settings，在 Error workflow 中选择 AI Error Handler Demo，保存。模型或工具节点的真实错误会按工作流失败处理，但业务上的错误答案不会自动成为执行错误。

例如，模型返回了可解析文本，节点成功，内容却遗漏工单状态；Error Trigger 不会因此触发。需要先用规则节点检查必需字段，判定失败后通过 Stop And Error 明确抛错。Stop And Error 文档提供 Error Message 与 Error Object 两种方式。

用独立 Webhook 测试流程验证链路

为避免真的调用付费模型，本次用可识别的固定错误代替模型失败。新建 AI Failure Probe，连接 Webhook → Stop And Error：

1. Webhook 的 HTTP Method 设 POST，Path 填一个只用于此次测试的路径，例如 ai-failure-probe。
2. Authentication 选 Basic Auth，并在凭证中设置仅用于本测试的账号密码。
3. Stop And Error 选 Error Message，填 AI_DEMO_MISSING_SUMMARY。
4. 在 AI Failure Probe 的 Settings 中关联上面保存的错误工作流，并保存失败的生产执行。
5. 发布测试主流程，复制 Webhook 显示的 Production URL，使用能发送 POST 的客户端调用一次，并填写测试 Basic Auth。

本测试将 Webhook 的 Respond 明确设为 When Last Node Finishes，让响应等待后续节点处理。若使用 Immediately，调用端会先收到 Workflow got started；即使后面 Stop And Error 失败，也不能把这个先行响应当作工作流成功。响应方式不会代替下面对失败执行和处理器记录的核对。

Webhook 文档区分 Test URL 与 Production URL。这里必须调用已发布测试流程的 Production URL；在编辑器 Listen for test event 时发送的测试请求，不能替代本次自动失败验收。

请求返回后，打开主流程 Executions，确认这次生产执行在 Stop And Error 失败，再打开错误处理器的 Executions，确认它完成了对应的一次处理。Code 输出的 message 应为 AI_DEMO_MISSING_SUMMARY，workflow_name 应指向 AI Failure Probe，last_node 应定位 Stop And Error。若保存了主执行，execution_url 应能打开同一条失败记录。客户端响应的正文和状态以实际响应配置为准，不能单独证明 Error Trigger 已触发；主流程失败且处理器留下对应记录才算这条链路通过。

核对完成后取消发布测试主流程，删除测试客户端保存的密码。如果准备把处理器接进真实 AI 流程，先换一个符合业务命名和保存期限的处理器，再按同样方式验证一次。

看不到记录时按这个顺序排查

它能监控什么，不能代替什么

这条方案保存执行失败的线索，不自动评判回答正确性、不恢复超时调用，也没有发送邮件或 Slack 通知。要接通知时，只发送脱敏后的必要字段，并记录通知自身是否成功。要捕获内容质量失败，则必须先定义业务验证规则，再让验证失败成为可追踪的工作流错误。