用途：为 n8n 工作流设计错误处理，让失败变得响亮、结构化、可恢复。默认情况下节点抛错会终止整个工作流；对无人值守场景（webhook/API、定时任务、队列 worker、智能体工具）这是错误默认，调用方会超时或收到空 500，运维方无告警。
主要能力：一是逐节点错误输出。设置节点 onError: "continueErrorOutput" 会创建第二个输出 main[1]，再把它接到真实处理节点。只做一步会出问题：只设 onError 不接线，错误被静默丢弃且运行显示成功；只接线不设 onError，该输出永不触发、工作流仍中断。验证要点是确认节点的 onError 与 connections["节点"].main[1] 都到位，validate_workflow 对半接线不报错。有效值：stopWorkflow（默认）、continueRegularOutput、continueErrorOutput。
二是先自愈再接线。对调用网络服务的节点（HTTP Request、Gmail/Slack、数据库、AI 节点等）设置 retryOnFail、maxTries、waitBetweenTries，吸收瞬时失败。引擎限制：重试对所有错误触发、无状态码过滤，maxTries 上限 5，waitBetweenTries 上限 5000ms。
API 工作流规范：每个路径（成功与错误）都必须终止于 Respond to Webhook，否则调用方超时。多个可失败节点可扇入一个错误 Respond。4xx（缺字段、未授权、禁止、未找到）在上游用 IF/Switch 判断，5xx 走错误输出。responseCode 默认 200，错误分支必须显式设置状态码。可按原因映射状态码（400/401/403/404/409/429/500/502/503/504），错误体默认 { "error": "<code>", "message": "<text>" }，不要泄露堆栈、SQL、上游响应体或令牌。
工作流级错误工作流：用 Error Trigger 节点另建工作流，捕获未被逐节点处理的情况，向不同渠道告警（避免递归陷阱），可加 Data Table 兜底。注意：分配错误工作流是 n8n UI 设置（Workflow Settings → Error Workflow），社区 MCP 无对应工具，需用户手动配置；MCP 可构建错误工作流、设置 onError/retryOnFail、接线错误输出、验证、自动修复、测试与查看执行。
适用场景：webhook/API 必配；定时/队列/智能体工具等无人值守必配；仅自己盯着的一次性运行可选默认行为。限制：部分实例级设置和 UI 配置需手动完成，资料未提供具体版本或定价信息。