Ich habe einen AI-Agenten in n8n gebaut (und hier ist genau das, was kaputt gegangen ist)

Ich habe das letzte Wochenende damit verbracht, einen autonomen Recherche-Agenten in n8n zu entwickeln. Das Ziel war einfach: Geben Sie ihm den Namen eines Unternehmens, und lassen Sie ihn dessen Website durchsuchen, aktuelle Nachrichten finden und eine Zusammenfassung schreiben.

Es hat perfekt funktioniert - genau 12 Minuten lang.

Dann stieß er auf einen 404-Fehler auf einer Website. Anstatt die Suche abzubrechen oder zu überspringen, versuchte der Agent es erneut. Und noch einmal. Und immer wieder. Als ich mein OpenAI-Dashboard überprüfte, hatte er bereits 40.000 Token in einer engen Schleife verbraucht, entschuldigte sich bei sich selbst für den Fehler und versuchte denselben fehlerhaften Link fünfzig Mal.

Gebäude KI-Agenten unterscheidet sich von der Erstellung von Standard-Automatisierungen. Wenn in einem Standard-Workflow ein Schritt fehlschlägt, wird der Workflow angehalten. In einem agentenbasierten Workflow "denkt" die KI, dass sie das Problem beheben kann, was es oft verschlimmert.

Wenn Sie von linearen Automatisierungen zu KI-Agenten übergehen, sind die Dinge wird brechen. Im Folgenden erfahren Sie, was genau bei meiner Einrichtung schief gelaufen ist, warum es passiert ist und welche spezifischen Korrekturen Sie benötigen, um Ihre Agenten produktionsreif zu machen.

1. Die "Entschuldigungsschleife" des Todes

Der gefährlichste Teil eines KI-Agenten ist sein Wunsch, hilfreich zu sein.

Wenn mein Agent auf einen Tool-Fehler stieß (z. B. eine fehlgeschlagene HTTP-Anfrage), schickte die n8n-Ausgabe die Fehlermeldung zurück an den LLM. Der LLM, der sich wie ein höflicher Chatbot verhielt, antwortete: "Ich entschuldige mich für den Fehler. Lassen Sie mich das noch einmal versuchen."

Daraufhin wurde genau dasselbe Programm mit genau denselben Parametern ausgelöst. Das Programm schlug erneut fehl. Der LLM entschuldigte sich erneut.

Realitätsprüfung: Ein nicht überwachter KI-Agent ist wie ein entschlossener Praktikant, der nicht weiß, wann er um Hilfe bitten muss. Er wird Ihr Budget aufbrauchen, wenn er versucht, ein Problem zu lösen, das er nicht lösen kann.

Die Lösung: Erzwingen einer "Aufgeben"-Bedingung

Sie können sich nicht darauf verlassen, dass der LLM erkennt, dass er feststeckt. Sie müssen eine Grenze hart kodieren.

Ich habe eine einfache Zähler-Knotenpunkt in n8n, die sich jedes Mal erhöht, wenn der Agent zum Entscheidungsschritt zurückkehrt.

1. Legen Sie eine Schleifengrenze fest: Wenn die Anzahl der Schleifen 5 übersteigt, erzwingt der Workflow einen Stopp und sendet mir eine Warnung.
2. Injektionssystem Anweisungen: Ich habe die System-Eingabeaufforderung aktualisiert: "Wenn ein Werkzeug zweimal mit demselben Fehler fehlschlägt, versuchen Sie es NICHT erneut. Markieren Sie die Aufgabe als fehlgeschlagen und fahren Sie fort."

2. Explosion der Kontextfenster (Speicheraufblähung)

In n8n, der Fensterpufferspeicher Knoten kann sich die KI an frühere Nachrichten erinnern. Das ist großartig für Gespräche, aber fatal für die Datenverarbeitung.

Mein Agent untersuchte eine Website und erhielt 5.000 Wörter Text. Der Agent analysierte ihn und ging dann zum nächsten Schritt über. Die 5.000 Wörter des ausgewerteten Textes blieben jedoch im Gesprächsverlauf erhalten.

Als der Agent den Auftrag ausführen wollte nächste Aktion wurde der gesamte Verlauf - einschließlich des umfangreichen Textes - an OpenAI zurückgesendet. Meine Token-Nutzung wuchs nicht linear, sondern exponentiell.

Die Mathematik des Crashs:

• Schritt 1: Sendeaufforderung (500 Token).
• Schritt 2: Scrapen Sie die Website (Ergebnis: 6.000 Token).
• Schritt 3: Der Agent "denkt" über den nächsten Schritt nach. Eingabe: 6.500 Token.
• Schritt 4: Der Agent führt eine Suche durch. Eingabe: 7.000 Token.
• Schritt 5: Agent fasst zusammen. Eingabe: 8.000 Token.

Bei Schritt 5 musste ich für den ursprünglichen Text immer wieder bezahlen.

Die Lösung: Der "vergessliche" Workflow

Ich ersetzte den Standard-Speicher-Knoten durch einen strengen Schiebefenster gekoppelt mit einem zusammenfassenden Schritt.

1. Geschichte begrenzen: Behalten Sie nur die letzten 3 Interaktionen.
2. Flüchtige Daten: Ich habe den Arbeitsablauf so geändert, dass große Datenblöcke (wie z. B. Website-Scrapes) von einem getrennt Kette, und nur die Zusammenfassung dieser Daten wird in den Speicher des Hauptagenten zurückgegeben.

Profi-Tipp: Geben Sie niemals Rohdaten (HTML, JSON-Dumps, lange Artikel) direkt in den Konversationsspeicher Ihres Agenten ein. Verarbeiten Sie sie, extrahieren Sie die Erkenntnisse und füttern nur die Einsicht zurück an den Agenten.

3. Die JSON-Formatierungshalluzination

Ich wollte, dass mein Agent das Endergebnis als strukturiertes JSON ausgibt, damit ich es in ein Google Sheet einfügen kann.

• Aufforderung: "Ausgabe der Unternehmensdaten im JSON-Format".
• Ergebnis:

Here is the JSON you requested:
{
  "company": "Evalics",
  "status": "Active"
}
Hope that helps!

Sehen Sie das Problem? Die KI hat Konversationsfüller hinzugefügt ("Hier ist das JSON...", "Hoffentlich hilft das!"). Als n8n versuchte, dies mit einem JSON-Knoten zu parsen, stürzte es sofort ab, weil die Ausgabe nicht gültig JSON-es war Text mit JSON.

Die Lösung: Parser für strukturierte Ausgabe

Hier gibt es zwei Möglichkeiten, und ich habe aus Gründen der Redundanz schließlich beide verwendet:

1. Verwenden Sie den "JSON Output Parser" (LangChain/n8n): Dieser Knoten dient dazu, den Gesprächsstoff zu entfernen und das JSON-Objekt zu extrahieren.
2. System Prompt Enforcement: Ich habe die Eingabeaufforderung geändert in: "Du bist eine JSON-erzeugende Maschine. Geben Sie KEINEN Konversationstext aus. Beginnen Sie mit { und enden Sie mit }."

Noch besser: OpenAI und Anthropic unterstützen jetzt Strukturierte Ausgaben (oder JSON-Modus) nativ. Wenn Sie dies in den Modelleinstellungen innerhalb von n8n aktivieren, wird die API gezwungen, gültiges JSON zurückzugeben, wodurch der "chatty"-Wrapper vollständig entfällt.

4. Werkzeugverwirrung (wenn die KI den falschen Hammer wählt)

Mein Agent hatte Zugang zu drei Instrumenten:

1. google_search
2. website_scraper
3. email_sender

Wenn ich das Programm aufforderte, "Informationen über Unternehmen X zu finden", verwendete es manchmal google_search, aber ein anderes Mal wurde versucht, mit website_scraper auf die Zeichenfolge "Firma X" (die keine URL ist), was einen Fehler verursacht.

Die KI verstand nicht ganz wenn welches Werkzeug zu verwenden, da meine Werkzeugbeschreibungen vage waren.

Wichtige Erkenntnis: Das Feld "Beschreibung" in Ihren n8n-Werkzeugdefinitionen ist eigentlich eine Aufforderung. Die KI liest es, um zu entscheiden, ob sie dieses Werkzeug verwenden soll.

Die Lösung: Prompt Engineering für Tools

Ich habe die Werkzeugbeschreibungen so umgeschrieben, dass sie unglaublich präskriptiv sind:

• Alte Beschreibung: "Kratzt eine Website."
• Neue Beschreibung: "Verwenden Sie dies NUR, wenn Sie eine gültige URL haben, die mit http/https beginnt. Verwenden Sie dies nicht für die Suche nach Firmennamen. Verwenden Sie zuerst google_search für die Suche nach URLs."

Nachdem ich die "Einsatzregeln" für die Tools geklärt hatte, hörte der Agent auf, nach Schlüsselwörtern zu suchen, und begann, zuerst nach URLs zu suchen.

5. Das "stille Scheitern" (Halluzinierter Erfolg)

Der gruseligste Fehler war kein Absturz, sondern eine Lüge.

Der Agent konnte keine E-Mail-Adresse für einen Lead finden. Anstatt "Nicht gefunden" zurückzugeben, wurde eine E-Mail vorgetäuscht: [email protected]. Es sah echt aus. Es hatte das richtige Format. Er war völlig unecht.

Dies liegt daran, dass LLMs Vorhersagemaschinen und keine Datenbanken sind. Es sagte voraus, dass eine E-Mail-Adresse sollte dort existieren.

Die Lösung: Schritte zur Verifizierung

Ich habe eine Verifikationsschicht zum Workflow.

1. Quellenangabe: Ich habe den Agenten aufgefordert, die Quell-URL wo es die Daten gefunden hat.
2. Null Output Training: Ich habe es explizit in der Systemsteuerung trainiert: "Wenn Sie die Informationen auf der Seite nicht finden können, geben Sie 'NULL' zurück. Raten Sie nicht."

Die Kosten von Fehlern

Wir denken oft, dass Automatisierung "kostenlos" ist, wenn sie erst einmal aufgebaut ist, aber schlechte Agenten sind teuer. Während meines "kaputten" Wochenendes:

• Broken Agent: 50 Schleifen x 2.000 Token x $0,01/1k = $1,00 pro Einzelfahrt.
• Fester Agent: 4 Schritte x 500 Token x $0,01/1k = 0,02 $ pro Einzelfahrt.

Das ist ein 50-fache Kostendifferenz. Wenn Sie damit 100 Leads pro Tag bearbeiten, kostet Sie die gebrochene Version 3.000 $/Monat. Die feste Version kostet 60 USD/Monat.

Zusammenfassung: Wie man Agenten baut, die nicht kaputt gehen

Die Entwicklung in n8n ist sehr leistungsfähig, weil man den logischen Ablauf visuell sehen kann, aber man muss sich gegen die probabilistische Natur der KI absichern.

1. Töte die Schleife: Setzen Sie eine harte Grenze (max. 3-5 Wiederholungen) für jede autonome Schleife.
2. Trimm den Speicher: Verwenden Sie ein gleitendes Fenster oder einen Zusammenfassungsknoten. Speichern Sie niemals Rohdaten-Dumps im Kontext.
3. Struktur durchsetzen: Verwenden Sie den JSON-Modus oder Ausgabeparser, um zu verhindern, dass nachgelagerte Knoten durch Konversationsflusen beschädigt werden.
4. Seien Sie konkret: Behandeln Sie Werkzeugbeschreibungen wie Code-Kommentare. Sagen Sie der KI genau, wann nicht ein Werkzeug zu benutzen.
5. Überprüfen: Zwingen Sie die KI dazu, Quellen zu nennen oder NULL zurückzugeben, anstatt zu raten.

KI-Agenten sind nicht sofort einsatzbereit. Sie benötigen eine "Sandbox-Phase", in der man ihnen beim Scheitern zusieht, die Löcher flickt und sie dann - und nur dann - frei laufen lässt.

Verwandte Ressourcen

• AI-Agenten vs. Automatisierungen
• N8n Memory Bloat Fixes bewältigen große Nutzlasten ohne Abstürze
• N8n Workflow Design Patterns Fehlerbehandlung Produktionseinrichtung
• Wahre Kosten der KI-Automatisierung 2025

Offizielle Quellen

• n8n AI Agent Dokumentation
• OpenAI Leitfaden für strukturierte Ausgaben
• LangChain-Speicher-Konzepte

Von Kevin Michael Schindler, Experte für KI-Automatisierung bei Evalics