总结了 n8n 工作流中 LLM 节点的五个典型坑点:JSON 解析失败、200 响应体含错误、重复发送消息、空字段崩溃,分别给出五分复现测试和节点级修复方案。
在用 n8n 工作流构建 LLM 节点时,这些坑每个都实实在在咬过我。它们在编辑器里全都能过,一上真实流量就崩。以下是具体哪里会崩、如何在五分钟内复现、以及节点层面的修复方法。
症状:解析步骤在测试 prompt 下正常运行,到了生产环境却抛出 Unexpected token。原因:模型很客气地在前面加了 "Sure, here is the JSON:"。测试:喂给它 20 个乱七八糟的输入——错别字、表情符号、极短的字符串。修复:在该节点支持的情况下要求 JSON 输出,在 prompt 里放一个明确的 schema,并加一条回退分支,用更严格的 prompt 重试一次。
症状:运行显示绿色,但下游数据是空的。原因:大量 API 返回 HTTP 200 但 body 里带错误(限速、配额)。测试:模拟一个 429/500,看看工作流实际在干什么。修复:把 "Never Error" 关掉,在 IF 节点里检查 response body,把错误分支接到一个通知上。
症状:同一个 lead 收到了三封邮件。原因:webhook 触发器的重试机制 + 至少一次投递保证。测试:连续 POST 同一个 payload 三次。修复:一个幂等 key——对 payload 做哈希,存下来,如果已经见过就跳过。
症状:一个空字段就让整个运行崩溃。原因:只测过愉快路径。测试:用最小可能输入来跑(无姓名、无邮箱)。修复:在 AI 节点前加一个验证 IF,把有问题的行路由到"待审核"桶里,而不是直接失败。
症状:凌晨 2 点告警,因为工作流夜里静默死掉了。测试:无需测试,直接假设它会发生。修复:一个 n8n Error Workflow,在任何失败时 ping 你,外加 API 节点上的带退避的重试。
贯穿所有问题的共同线索:每一条都是没人测过的失败路径。我们演示愉快路径;生产环境只在边界处翻车。
如果你想要一个可用的起点,我的免费 AI Hook Generator 是一个官方 n8n 模板——导入后读一下便利贴,那里写了 prompt 和错误处理是如何组织的:
如果你不想自己测:我提供固定价格的售前压力测试服务,测试 n8n AI agent——你导出工作流,我返回按优先级排序的失败列表和修复补丁。