n8n AI Agent 报错排查：超时、限流、格式错误怎么处理

Q: n8n AI Agent 节点报 60 秒超时，改哪个设置？

自托管环境下，任务运行器(Task Runner)的默认超时是 60 秒，由环境变量 N8N_RUNNERS_TASK_TIMEOUT 控制，调大这个值即可让长耗时的 LLM 调用跑完，但要注意这只影响任务运行器层面，云端(Cloud/Premium)的网关超时是另一套限制，改这个环境变量不管用。

Q: AI Agent 节点报错 Internal error 400 Invalid value for 'content' 是什么原因？

这是 Prompt 字段传入了 null。常见于 Prompt 设成 Define below 但表达式没取到值，或者接在 Chat Trigger 节点后面时 chatInput 字段本身是空的，先检查上游节点输出，再确认表达式引用的字段确实有值。

Q: Simple Memory 节点报错要怎么修？

多半是节点版本太旧(它以前叫 Window Buffer Memory)，直接删掉这个子节点重新添加一个新的 Simple Memory，n8n 会自动挂载最新版本，不需要手动升级。

Q: AI Agent 调用工具时偶尔报 Failed to parse tool arguments，怎么办？

这个错误在实际使用中出现概率不算低，本质是模型返回的工具调用参数不是合法 JSON，常见诱因是模型陷入重复调用同一个工具的循环导致输出被截断。官方建议不要让 AI Agent 自己解析结构化输出，改成后面接一个独立的 LLM Chain 节点专门做解析，成功率明显更稳。

AIEII

n8n 的 AI Agent 节点报错，十有八九落在三类里：任务跑到一半被掐掉(超时)、模型接口不搭理你(限流)、工具调用回来的东西看不懂(格式解析失败)。这三类报错的排查路径完全不一样，混在一起查最浪费时间。

先说结论：超时看你是自托管还是云端，两层限制不是一回事；限流报错不能只指望 Retry On Fail 自动兜底，某些 Chat Model 节点根本不会自动重试 429；格式解析失败大概率不是你的 Prompt 写得不好，而是不该让 Agent 自己去解析结构化输出。往下逐条拆。

先分清楚是哪一类报错

拿到报错先别急着改代码，对一下症状。

症状关键词	属于哪一类	排查方向
执行卡住不动，最后报 timeout / Gateway timed out	超时	任务运行器超时 or 网关超时
报错文本含 429 / rate limit / too many requests	限流	Chat Model 节点重试设置
Internal error 400 Invalid value for ‘content’	输入格式	Prompt 字段是否传了 null
Failed to parse tool arguments / Invalid JSON in model output	工具调用格式	是否该拆分出独立解析节点
A Chat Model sub-node must be connected	节点连接缺失	检查子节点连线

超时报错：先分清任务运行器超时和网关超时

自托管 n8n 的 AI Agent 节点默认跑不满 1 分钟就会被打断，这是任务运行器(Task Runner)自己的保护机制，由环境变量 N8N_RUNNERS_TASK_TIMEOUT 控制，默认值 60 秒。LLM 调用如果本身就要几十秒(尤其是接了多个工具、要来回调用好几轮的 Agent 场景)，60 秒经常不够用，直接把这个值调大就能解决，比如设成 300 或更高。

要注意一个反直觉的坑：n8n 社区反馈过，只要工作流里存在 AI Agent 相关节点，哪怕这个节点根本没被执行到，同一个工作流里的 Code 节点也可能莫名其妙报 300 秒超时。遇到这种"明明没跑到那个节点却超时"的情况，先怀疑是不是这个已知问题，而不是死磕自己的 Code 逻辑。

云端(Cloud/Premium)环境是另一套限制。有反馈显示，LLM 单次查询超过 4 分钟左右会被网关直接掐断，报 Gateway timed out，这一层不受 N8N_RUNNERS_TASK_TIMEOUT 控制。如果你的 Agent 场景本身需要模型想很久(比如带深度推理或者多轮工具调用),更现实的做法是拆短单次调用的粒度,而不是指望改环境变量解决云端网关的硬限制。

限流报错(429)：Retry On Fail 不是万能开关

n8n 官方文档给限流报错的统一措辞是"The service is receiving too many requests from you"，对应 HTTP 429。官方给了三种处理方式：

Retry On Fail：在节点 Settings 里打开，配合 Wait Between Tries(ms)，把等待时间设得比接口的限流窗口长一点，比如接口限一秒一次，就设 1000ms 以上。
Loop Over Items + Wait：在调用前接 Loop Over Items，调用后接 Wait 节点再连回 Loop Over Items，把请求拆小批、批间强制停顿。
HTTP Request 节点自带的 Batching：Add Option 里选 Batching，配置 Items per Batch 和 Batch Interval(ms)。

但这里有个容易踩的坑：OpenAI Chat Model 节点在部分版本上，对 429 错误不会自动重试，即使你打开了 Retry On Fail 也不生效，这是 n8n 官方仓库里挂着的已知问题。如果你已经照着上面配了 Retry On Fail 还是频繁 429，别继续加大等待时间，先确认是不是这个节点本身没把 429 纳入可重试的错误类型，换成在 AI Agent 节点外层用 Loop Over Items + Wait 兜一层，比死等节点内部重试更稳。

另外 Anthropic 和 OpenAI 的限流响应结构不一样：Anthropic 会带 retry-after 头，OpenAI 则要读 error.code 才能分清是速率限制还是配额耗尽，配额耗尽的 429 重试再多次也没用，这种情况要去后台加额度，不是工作流能解决的。

工具调用格式错误：先怀疑要不要让 Agent 自己解析

这一类报错最容易让人怀疑自己 Prompt 写得不好，但实际上大多是结构性问题。

Internal error 400 Invalid value for ‘content’: expected a string, got null：Prompt 字段拿到了 null。常见于两种情况，一是 Prompt 参数设成 Define below，但里面的表达式没取到实际值；二是接在 Chat Trigger 节点后面，用的是自动传入的 chatInput，但上游给的这个字段本身是空的。查的时候直接去看输入数据面板，确认 Prompt 最终渲染出来的字符串不是空的。

A Chat Model sub-node must be connected：字面意思，AI Agent 节点没连 Chat Model 子节点就执行了，打开节点点 “+ Chat Model” 补上。

Simple Memory 节点报错：这个节点以前叫 Window Buffer Memory，报错大概率是版本太旧，删掉重新拖一个新的进来，不用手动升级。

Failed to parse tool arguments from chat model response：这是最麻烦的一种，模型返回的工具调用参数不是合法 JSON。有反馈这个问题不算罕见的边缘情况,一批调用里能摸到个位数比例的失败率,常见诱因是 Agent 陷入重复调用同一工具的循环，把输出结构搅乱了。官方给的建议很直接：不要让 AI Agent 节点自己解析结构化输出，改成后面单独接一个 LLM Chain 节点专门做解析，让 Agent 只管拿到原始文本，解析交给独立节点处理，比塞在 Agent 内部一次性做完更稳定。

这背后也有个版本变化要知道：n8n 从 1.82.0 起，AI Agent 节点的 Agent Type 只保留了一种模式(Tools Agent)，以前那种要挑选 Agent 类型的界面已经没了，如果你看的教程截图还有下拉选 Agent Type，那是老版本的界面，现在不用选了。

条件分支兜底写法

与其等报错发生了再去后台翻日志，不如在工作流里直接接一层兜底分支，让错误落到看得见的地方，而不是让整条流程静默失败。做法：

打开 AI Agent 节点的 Settings，把 On Error 改成 Continue Using Error Output，节点右侧会多出一个错误输出口，报错时不会中断整条工作流，而是把错误信息当数据往下传。
接一个 IF 节点，用表达式判断 {{$json.error.message}} 里的关键词，分流处理：
- 含 429 或 rate limit → 接 Wait 节点等一段时间后，用 NoOp 节点接回原来的调用分支重试。
- 含 timeout → 走一条"降级"分支，比如换成更快的模型或者精简 Prompt 后再试一次，而不是死等。
- 含 parse 或 Invalid JSON → 不要静默重试，直接接一个通知节点(飞书 / 邮件 / Telegram)把原始报错内容推出去，人工介入比让它自己重试更可靠，因为格式解析失败往往会反复复现同一个问题。
每条分支最后都接回主流程的下一步，或者显式标记为失败结束，避免出现工作流"看起来跑完了但其实中间那步啥都没做"的情况。

这套写法的核心是把"错误类型判断"从人工翻日志挪到工作流内部，报错发生时你能立刻知道是哪一类、该走哪条恢复路径，而不是每次都要重新查一遍上面那几张表。

我的判断

这三类报错里，超时和限流本质是资源和配额问题，靠加超时时间、加等待间隔基本都能解决，不需要改设计。但工具调用格式解析失败不一样，它更像是在提示你 Agent 节点的职责边界设错了，把"决策该调用哪个工具"和"把工具返回的原始文本解析成结构化数据"这两件事都塞进同一个节点，出错概率天然更高。按官方建议把解析拆到独立的 LLM Chain 节点，代价是多一个节点、多一次模型调用，但换来的稳定性在生产环境里划算。如果你的工作流报错频率高到需要经常人工看日志，先加条件分支兜底，把日志翻查这件事变成主动通知，省下来的时间比省下来的那一次模型调用值钱得多。