Hilf mir, meinen Workflow aufzubauen: Agent-Node mit Gemini + Perplexity Tool + HTTP Tool stürzt vor Output-Parser ab. Fehler wechselt zwischen a.ok(nodeExists) und Out-of-Memory

Hallo, ich bin neu bei n8n. Ich habe angefangen, einen Workflow zu erstellen, um mich automatisch auf Rollen zu bewerben, die zu meinem Profil passen, aber ich kann den Flow einfach nicht zum Laufen bringen. Ist das ein Architektur-Problem oder mache ich noch etwas anderes falsch? Ist das machbar oder bin ich zu ambitioniert? Falls nicht möglich, was könnte ich tun, um es zumindest nutzbar zu machen? – Zum Beispiel einfach nur, dass der Workflow alle Links und Infos in eine Datentabelle einfügt, damit ich leichter anwenden kann. Sollte ich von vorne anfangen?

Diese Automatisierung muss:

  • Jeden Tag um 9 Uhr morgens laufen.

  • Mehrere Job-Portale täglich nach Positionen durchsuchen, die zur Erfahrung eines Kandidaten passen (einzelner Kandidat).

  • ATS-Schlüsselwörter, URL, Unternehmen, Job-Informationen, Rolle erkennen und Prompt-Injektionen sowie Nachweise erkennen.

  • Die Informationen in eine Tabelle extrahieren.

Ein zweiter Trigger sollte maßgeschneiderte Versionen des Lebenslaufs und des Anschreibens für jeden Kandidaten erstellen und diese Dateien in einem Drive-Ordner speichern. Er muss auch Formulare automatisch ausfüllen, damit der Kandidat entscheiden kann, ob er sich bewerben möchte oder nicht. Er muss die CV-Dokumente auf jede Website hochladen.

Falls das nicht möglich ist oder Einschränkungen hat, sagen Sie mir Bescheid und wir machen etwas Einfacheres. Ich habe Zugriff auf Perplexity und Google Studio.

1 „Gefällt mir“

Willkommen @Camila_Andrea!

Der a.ok(nodeExists)-Fehler bedeutet normalerweise, dass ein Knoten in der Tool-Kette des Agenten referenziert, aber nicht richtig verbunden ist – überprüfe sorgfältig, dass jeder Tool-Knoten (Perplexity, HTTP) eine ordnungsgemäße Verbindung zum „Tool"-Eingang des AI Agent-Knotens hat, nicht nur zum Hauptfluss. Das OOM-Problem ist ein separates Problem: Mit Gemini + mehreren Tools kann der Agent viele Male in einer Schleife laufen und dabei ein großes Kontextfenster ansammeln, was den Speicher erschöpft. Setze eine maximale Iterationsbegrenzung auf dem Agent-Knoten (unter Einstellungen) – beginne mit 5–10 und schaue, ob es abgeschlossen wird.

Für die Architektur: dein Umfang ist okay, aber ich würde es in zwei separate Workflows aufteilen – einen für die Stellensuche/Extraktion, einen für die Dokumentgenerierung. Alles in einem einzigen Agenten mit so vielen Tools auszuführen macht das Debuggen viel schwieriger.

1 „Gefällt mir“

Hey Camila,

Das ist tatsächlich ein richtig cooles Projekt, und es ist in n8n definitiv machbar — aber die Architektur muss neu überdacht werden.

Der Crash, den du siehst, kommt wahrscheinlich daher, dass der Agent-Node versucht, zu viel auf einmal zu verarbeiten. Wenn du mehrere Tool-Aufrufe (Perplexity-Suche + Job-Board-Scraping + Formular-Ausfüllung) in einem einzelnen Agent-Node kombinierst, kann das die Speichergrenzen überschreiten, besonders bei Gemini.

Hier ist, was ich dir vorschlagen würde:

  1. Teile es in separate Workflows auf. Versuche nicht, alles in einem Agent-Node zu machen. Splitte es auf:
    Workflow A: Tägliches Cron → Job-Boards durchsuchen → Matches filtern → in Datenbank speichern
    Workflow B: Ausgelöst pro Match → Perplexity für ATS-Keyword-Analyse → in Tabelle formatieren
    Workflow C: Manueller Trigger → personalisierter Lebenslauf/Anschreiben pro ausgewähltem Job generieren

  2. Der Agent-Node funktioniert am besten für Entscheidungsfindung, nicht für die Verkettung mehrerer schwerer HTTP-Anfragen. Nutze den Agent, um zu entscheiden, WELCHE Jobs du anwenden sollst, nicht um die Jobs selbst zu scrapen.

  3. Für den Auto-Fill-Teil des Formulars — das ist das kniffligste Stück. Die meisten Job-Boards nutzen einzigartige Formularstrukturen. Ein praktischerer Ansatz ist es, den Workflow alles vorbereiten zu lassen (Lebenslauf, Anschreiben, Antworten) und dich manuell zu benachrichtigen. Ich habe festgestellt, dass dieser 80/20-Ansatz massive Entwicklungszeit spart.

Ich baue n8n-Workflows wie diesen beruflich — diese Art von mehrstufiger KI-Automatisierung ist tatsächlich meine Spezialität. Wenn du möchtest, dass ich dir bei der Architektur oder beim Aufbau helfe, schreib mir eine DM. Ich freue mich auf einen kurzen Call und kann die Architektur mit dir durchgehen.

Auf jeden Fall ein großartiges Projektidee — verwirf es nicht, strukturiere es einfach neu.

1 „Gefällt mir“

Zwei verschiedene Fehler, die abwechselnd auftreten, bedeuten üblicherweise zwei echte Probleme übereinander, und die Antwort oben hat sie korrekt aufgeteilt. Es lohnt sich, sie in dieser Reihenfolge anzugehen.

Der a.ok(nodeExists)-Fehler ist ein Verdrahtungsproblem: Ein Tool-Node (Perplexity, das HTTP-Tool) wird vom Agent referenziert, ist aber nicht korrekt mit dem Tool-Input des AI-Agent-Node verbunden. Jedes Tool muss mit dem ai_tool-Input des Agents verbunden sein, nicht in die Hauptausführungsleitung. Öffne den Agent-Node und bestätige, dass jedes Tool in seiner Tools-Liste angezeigt wird. Wenn eines in die Hauptleitung verdrahtet ist statt in den Tool-Input, bekommst du genau diesen Fehler.

Die Out-of-Memory ist ein separates Problem und resultiert daraus, dass der Agent in einer Schleife läuft. Bei Gemini plus mehreren Tools ruft der Agent, wenn er nicht konvergiert, immer wieder Tools auf und sammelt Kontext an, bis die Instanz kein Speicher mehr hat. Begrenze das: Setze ein maximales Iterationslimit für den Agent, damit er nicht unbegrenzt loopen kann, und reduziere, was jedes Tool zurückgibt (das HTTP-Tool, das eine riesige Response in den Kontext wirft, ist eine häufige OOM-Ursache). Behebe erst die Verdrahtung, damit es überhaupt läuft, dann füge das Iterationslimit hinzu, damit ein nicht-konvergierender Durchlauf sauber fehlschlägt, statt Speicher zu verbrauchen.

Für einen Anfänger ist das ein machbarer Workflow, du bist nicht zu ehrgeizig, du bist nur auf zwei der Standard-Agent-Fallen auf einmal gestoßen. Bringe ein Tool verdrahtet und funktionstüchtig zum Laufen, bevor du das zweite hinzufügst – es ist viel leichter, ein Tool zu debuggen als drei. Bei welchem Tool hast du verdrahtet, als der nodeExists-Fehler zuerst auftauchte?

1 „Gefällt mir“

Dieser wechselnde Fehler tritt auf, wenn die Node.js-Speicherheap-Zuweisung (max-old-space-size) vollständig von den gleichzeitig ausgeführten Daten überfordert wird, die durch die Gemini- und Perplexity-Kontextfenster fließen. Wenn der Container überfordert ist, löscht er entweder die Knotenzustandsverfolgung (a.ok(nodeExists) oder stürzt mit einem Out-of-Memory-Fehler ab.

Um zu verhindern, dass dies deine Instanz zum Absturz bringt, musst du n8n dazu zwingen, vergangene Ausführungsprotokolle zu bereinigen und den Node.js-Speicherfootprint in deinen Docker-Umgebungsvariablen zu vergrößern.

Füge diese jetzt direkt zu deinem Container-Setup hinzu:
NODE_OPTIONS=–max-old-space-size=4096
EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=24

Wenn du hochkomplexe KI-Schleifen für ein Kundenprojekt ausführst und ein robustes Server-Setup brauchst, das unter Last nicht vor Montagmorgen zusammenbricht, lass uns in Kontakt treten. Ich bin ein Backend-Infrastruktur-Ingenieur; ich kann heute noch schnell einen Screen-Share mit dir machen, deine Docker-Compose-Layer optimieren und deine KI-Parsing-Engines für pauschal 250 Dollar stabilisieren. Schreib mir eine DM, wenn du das innerhalb von 30 Minuten behoben bekommen möchtest!