Ein n8n-Workflow mit Sprachmodell h\u00e4lt im Dauerbetrieb, wenn er nur einen Job erledigt, sein Ausgabeformat per Schema erzwingt und Fehler auf mehreren Ebenen abf\u00e4ngt. Dazu geh\u00f6ren Retry, ein Fehlerausgang pro kritischem Node und ein Error Workflow, der Ihnen eine E-Mail schickt. Timeouts verhindern h\u00e4ngende L\u00e4ufe. Usage-Daten und Logs bewahren Sie pro Lauf auf, damit Kosten und Ausf\u00e4lle nachvollziehbar bleiben. Getestet wird mit echten Daten, nicht mit dem einen sch\u00f6nen Beispiel.<\/p>\n
Sie brauchen eine laufende n8n-Instanz, einen API-Zugang zu einem Sprachmodell, echte Beispieldaten aus Ihrem Anwendungsfall und ein Postfach f\u00fcr Fehlermeldungen. Wenn Sie n8n selbst hosten, ben\u00f6tigen Sie au\u00dferdem Zugriff auf die Umgebungsvariablen, weil dort die globalen Timeouts liegen.<\/p>\n
Die Anleitung setzt voraus, dass Sie Workflows, Credentials und Sub-Nodes in n8n bereits kennen. Sie erfahren hier nicht, wie man einen ersten Workflow baut, sondern wie man einen vorhandenen so h\u00e4rtet, dass er auch beim dritten, zehnten und hundertsten Lauf noch brauchbare Ergebnisse liefert.<\/p>\n
Die Schritte folgen einer sinnvollen Reihenfolge: zuerst der Zuschnitt, dann das Ausgabeformat, dann die Fehler, zuletzt Kosten und Nachvollziehbarkeit. Jeder Schritt hat einen Zweck und einen Pr\u00fcfpunkt, an dem Sie erkennen, ob er sitzt.<\/p>\n
Zweck: Ein Workflow, der nur eine Aufgabe hat, l\u00e4sst sich einzeln testen, einzeln abschalten und bei einem Fehler schnell eingrenzen. Aus Erfahrung sind mehrere kleine Automatisierungen<\/a> besser als eine gro\u00dfe, und jede sollte im Idealfall nur einen Job haben. Wer Klassifizieren, Anreichern, Versenden und Archivieren in einem Workflow b\u00fcndelt, sucht bei einem Fehler lange und riskiert, dass ein kleiner Defekt alles lahmlegt.<\/p>\n Pr\u00fcfpunkt: Sie k\u00f6nnen die Aufgabe des Workflows in einem Satz ohne „und“ beschreiben. Gelingt das nicht, teilen Sie ihn auf und verbinden die Teile \u00fcber Webhooks oder Sub-Workflows.<\/p>\n Zweck: Beispieldaten, die Sie sich selbst ausdenken, sind fast immer sauberer als die Wirklichkeit. Ein typisches Szenario: Ein Workflow klassifiziert eingehende Anfragen<\/a> aus einem Kontaktformular. Im Test funktionieren einige ordentlich formulierte Nachrichten. Im Betrieb kommen eine leere Nachricht, ein extrem langer Text mit Signaturen und eine Anfrage in einer anderen Sprache. Genau diese F\u00e4lle bringen das Ausgabeformat durcheinander.<\/p>\n Pr\u00fcfpunkt: Sie haben aus dem echten Datenbestand mindestens je ein Beispiel f\u00fcr den Normalfall, den leeren Fall, den \u00fcberlangen Fall und den ungew\u00f6hnlichen Fall durchlaufen lassen und die Ergebnisse einzeln angesehen.<\/p>\n Zweck: Alles, was nach dem Sprachmodell kommt, verarbeitet Daten maschinell. Freitext mit eingestreutem JSON bricht dort fr\u00fcher oder sp\u00e4ter. n8n bietet daf\u00fcr den Structured Output Parser, der die Ausgabe anhand eines JSON Schemas erzeugt. Das Schema l\u00e4sst sich aus einem JSON-Beispiel generieren oder manuell als JSON Schema eingeben. Referenzen mit Angeschlossen wird der Parser \u00fcber die Option Require Specific Output Format an ausgew\u00e4hlte AI-Root-Nodes<\/a>. Beachten Sie die Warnung aus der n8n-Dokumentation: Strukturierte Ausgabe direkt in Agent-Workflows ist h\u00e4ufig unzuverl\u00e4ssig. n8n empfiehlt, Parsing und Validierung in einer separaten LLM Chain zu erledigen. Wenn Ihr Workflow keine Werkzeuge braucht, nehmen Sie von vornherein eine Chain statt eines Agents.<\/p>\n Bei lokalen Modellen gilt eine Einschr\u00e4nkung: Die Ollama-Model-Node unterst\u00fctzt laut Dokumentation keine Tools, n8n empfiehlt die Verbindung mit einer Basic LLM Chain<\/a>. Zus\u00e4tzlich bringen manche Anbieter eigene JSON-Modi oder Tool Calling mit. Wie die entsprechende Option bei Ihrem Anbieter hei\u00dft und was sie leistet, pr\u00fcfen Sie direkt in den Einstellungen des Modell-Nodes und in der Herstellerdokumentation. Die Bezeichnungen unterscheiden sich, und eine pauschale Aussage w\u00e4re hier ungenau.<\/p>\n Pr\u00fcfpunkt: Die Testdaten aus Schritt 2 liefern ohne Handarbeit Ausgaben, die dem Schema entsprechen. Ein absichtlich schwieriger Fall, etwa eine leere Eingabe, erzeugt entweder ein g\u00fcltiges Ergebnis oder einen sauberen Fehler, aber keinen halb gef\u00fcllten Datensatz.<\/p>\n Zweck: Wenn das Parsing beim ersten Versuch scheitert, kann der Auto-fixing Output Parser ein weiteres Sprachmodell aufrufen, das die Ausgabe korrigiert<\/a>. Das f\u00e4ngt kleine Formatfehler ab, ohne dass der Lauf abbricht. Es hat aber einen Preis: Jeder Korrekturversuch ist ein zus\u00e4tzlicher Modellaufruf und verursacht zus\u00e4tzliche Token-Kosten.<\/p>\n Pr\u00fcfpunkt: Sie wissen aus den Ausf\u00fchrungsprotokollen, wie oft die Korrektur tats\u00e4chlich anspringt. Springt sie bei vielen L\u00e4ufen an, liegt das Problem im Prompt oder im Schema, und Sie sollten dort ansetzen, statt jedes Mal ein zweites Modell zu bezahlen.<\/p>\n Zweck: Externe APIs fallen aus, Modelle antworten versp\u00e4tet, Rate Limits greifen. Ein Workflow, der das nicht einplant, bleibt stehen oder macht still falsche Dinge. Die Gegenma\u00dfnahmen greifen auf verschiedenen Ebenen:<\/p>\n2. Mit echten Daten testen<\/h3>\n
3. Das Ausgabeformat per Schema erzwingen<\/h3>\n
$ref<\/code> unterst\u00fctzt der Parser nicht<\/a>. Halten Sie das Schema deshalb flach und schreiben Sie es ohne Verweise aus.<\/p>\n4. Den Auto-fixing Output Parser gezielt einsetzen<\/h3>\n
5. Fehler auf drei Ebenen abfangen<\/h3>\n