在 LangFlow 中通过但在 n8n 生产环境中失败的 3 个测试

你构建了一个 LangFlow 原型。每个测试都通过了。你将工作流迁移到 n8n 用于生产。第一次运行就崩溃了。

这不是一个 bug。这是一种模式。

LangFlow 是一个开发环境。它假设你正在观察。它对错误和重试非常宽容。

n8n 是一个生产引擎。它无人值守运行。它期望每个节点都是一次完美的事务。如果你不处理失败，工作流就会停止。

以下是当你从原型转向生产时会失败的三个测试。

1. JSON 解析

在 LangFlow 中，你要求返回 JSON。模型返回一个字符串。你对其进行解析。它能正常工作。

在 n8n 中，模型可能会添加 Markdown 代码块标记、前导词或末尾逗号。LangFlow 会忽略这些小错误。n8n 则不会。JSON 节点会失败并停止整个工作流。

解决方法： 不要依赖更好的提示词。构建一个验证层。在解析之前，使用工具节点去除 Markdown 并清理字符串。

2. 上下文限制

在 LangFlow 中，你测试一个 8,000 token 的文档。它能工作。你尝试 12,000 token。它仍然能工作。

在 n8n 中，你的工作流会累积状态。子工作流、历史记录和元数据都会不断增加。一个在隔离状态下可以工作的文档，在作为完整流水线的一部分时可能会触及限制。模型会截断文本，导致你的输出变成乱码。

解决方法： 实现一个上下文预算检查器。在调用 LLM 之前测量你的 token 数量。如果超过限制，请尽早让工作流失败并返回清晰的错误。

3. 瞬时故障

在 LangFlow 中，如果调用失败，你再次点击“Run”。你假设那只是网络波动。

在 n8n 中，如果调用在凌晨 2 点失败，工作流就会终止。没有人会在那里点击“Run”。你的数据会卡在错误队列中。

解决方法： 不要只是添加简单的重试。使用指数退避（exponential backoff）。最重要的是，使用死信队列（dead-letter queue）。这可以保存失败的输入，以便你稍后修复问题并重新运行。

从原型转向生产的总结： • 为每个 LLM 输出添加验证层。 • 在每次调用前测量上下文使用情况。 • 实现带有死信队列的重试机制。

原型是草图，生产是建筑。不要混淆两者。

Source: https://dev.to/qawalah/3-tests-that-pass-in-langflow-but-fail-in-n8n-production-22i7

Optional learning community: https://t.me/GyaanSetuAi