Benötige Ratschläge zur Verbesserung eines n8n AI-Agent-Workflows

Hilf mir, meinen Workflow zu erstellen
1

Hallo zusammen,

Ich habe einen KI-Workflow in n8n für interne Operationen entwickelt und würde gerne Feedback von Menschen bekommen, die sich mit ähnlichen Problemen auseinandergesetzt haben.

Der Workflow verarbeitet verschiedene Anfragen je nach Kontext. Er ruft Daten ab, leitet Aufgaben weiter, aktualisiert Systeme und übergibt Arbeiten an den richtigen Prozess. Am Anfang funktionierte es gut, aber je mehr wir den Workflow erweitert haben, desto mehr hat der Agent angefangen, schlechte Entscheidungen zu treffen, welches Tool oder welchen Workflow er aufrufen soll.

Manchmal überspringt er den Abruf, obwohl er eine Wissensdatenbank abfragen sollte. Manchmal ruft er den falschen Branch auf oder antwortet aus dem Speicher, statt die aktuellsten Daten zu nutzen. Der Prompt ist im Laufe der Zeit gewachsen, daher frage ich mich, ob das Teil des Problems ist oder ob die gesamte Architektur geändert werden muss.

Momentан verwenden wir n8n mit OpenAI, eine Vektordatenbank für den Abruf und ein paar interne APIs. Wir haben auch Workbeaver für Desktop-Aufgaben getestet, die nicht über APIs zugänglich sind, während wir n8n als Hauptorchestrierungsebene beibehalten.

Für diejenigen, die größere KI-Agenten in n8n bauen:

  • Behaltet ihr einen einzelnen Orchestrator bei, oder teilt ihr die Verantwortung auf mehrere kleinere Agenten auf?

  • Wie reduziert ihr Halluzinationen, wenn mehrere Tools verfügbar sind?

  • Verlasst ihr euch hauptsächlich auf Prompt Engineering, oder habt ihr festgestellt, dass architektonische Änderungen wirksamer sind?

  • Gibt es bewährte Verfahren, um zu entscheiden, wann ein Agent Daten abrufen sollte, statt direkt zu antworten?

Ich würde mich sehr freuen zu hören, was in euren Projekten funktioniert hat. Vielen Dank im Voraus.

2 „Gefällt mir“
2

Das riecht weniger nach einem Prompt-Problem und mehr danach, dass du aus dem Single-Orchestrator herausgewachsen bist. Wenn ein Agent jedes Tool hält und bei jedem Zug aus einem großen Menü wählt, und die Tool-Beschreibungen plus dein gewachsener Prompt kämpfen alle um das gleiche Aufmerksamkeitsbudget, dann wird die Tool-Auswahl genau dann schwammig, wenn du Branches hinzufügst. Das ist das Muster, das du beschreibst.

Was mir geholfen hat, war das Aufteilen. Behalte einen dünnen Router-Agent, dessen einzige Aufgabe die Lane-Auswahl ist, und gib dann an kleine Sub-Agenten ab, die jeweils 2 oder 3 Tools besitzen. Kleinerer Entscheidungsraum pro Agent, kürzerer Prompt für jeden, viel zuverlässigere Tool-Auswahl. Der einzelne fette Orchestrator sieht elegant aus, degradiert aber mit jedem Tool, das du anbringst.

Für das skipping retrieval Problem: Lass Retrieval nicht länger ein Tool sein, das der Agent wählen kann zu überspringen. Bei den Branches, wo die Antwort fundiert sein muss, führe Retrieval als festen Schritt aus, bevor der Agent die Anfrage überhaupt sieht, damit er immer frischen Kontext hat und nicht aus dem Speicher antworten kann. Nimm dem Modell diese Entscheidung weg, wo es um Korrektheit geht.

Prompt Engineering vs. Architektur, ab einer bestimmten Größe gewinnt Architektur und es ist nicht eng. Prompt-Tweaks haben eine Obergrenze, Routing plus scoped Sub-Agenten ist das, was hält, wenn die Oberfläche weiter wächst.

Ich habe eine Handvoll dieser Multi-Agent-Setups in der Produktion gebaut und bin gerne bereit, tiefer in die Routing-Struktur einzusteigen, wenn es hilft.

1 „Gefällt mir“
3

@James198

Du bist auf die Mauer gestoßen, auf die fast jeder wachsende n8n-Agent stößt: einen Orchestrator mit einem fetten Prompt und einem Dutzend Tools. Die Genauigkeit der Tool-Auswahl des Modells fällt ab wie ein Stein, wenn sowohl die Anzahl der Tools als auch die Länge des Prompts zunimmt. Die Symptome, die du siehst (übersprungene Abrufung, falscher Zweig, Antworten aus dem Gedächtnis), sind also der erwartete Fehler, nicht ein Tuning-Problem, das du wegpromptend lösen kannst.

Ich beantworte deine Fragen der Reihe nach.

Ein Orchestrator vs. aufgeteilt. Aufgeteilt. Wandle die ein oder zwei großen Workflows in vier oder fünf kleinere um, jeder mit einer einzigen Verantwortung, und lasse den Orchestrator sie via Webhook oder Execute Workflow aufrufen. Die einzige Aufgabe des Orchestrators ist Routing: klassifiziere die Anfrage, übergib sie an den richtigen Sub-Workflow, sammle das Ergebnis ein. Er sollte selbst nicht abrufen, aktualisieren oder APIs berühren. Jeder Sub-Agent sieht dann nur die 3 bis 5 Tools, die für seine Aufgabe relevant sind, statt des ganzen Menüs, und das Modell wählt viel öfter korrekt, wenn das Menü klein ist. Nebenbei kannst du es dann auch wirklich debuggen, weil ein Fehler jetzt auf einen kleinen Workflow begrenzt ist statt in einem Monolith begraben zu sein.

Halluzinationen reduzieren mit mehreren verfügbaren Tools. Zwei Hebel. Erstens, den Tool-Satz pro Agent verkleinern, wie oben. Zweitens, Entscheidungen vom Modell wegnehmen, überall dort, wo die Entscheidung eigentlich deterministisch ist. Wenn ein Zweig aus einem bekannten Feld mit einem Switch-Knoten gewählt werden kann, mach das und lass das LLM nicht entscheiden. Reserviere das Urteil des Agenten für die wirklich mehrdeutigen Fälle. Die meisten „er hat den falschen Zweig aufgerufen"-Probleme sind wirklich „ich habe das Modell gebeten, eine Wahl zu treffen, die eine Regel hätte treffen können."

Prompt-Engineering vs. Architektur. Prompt-Tuning hat eine Obergrenze und du siehst aus, als würdest du sie erreichen. Jenseits einer bestimmten Größe ist der Prompt das Problem, nicht die Lösung, weil du das Kontextfenster so weit vorantreibst, dass das Modell die früheren Anweisungen verliert. Ein knapper 3-Tool-Agent mit einem kurzen Prompt schlägt einen 15-Tool-Agent mit einem riesigen Prompt jedes Mal. Repariere zuerst die Architektur, dann stimme die Prompts in den kleineren Teilen ab.

Entscheiden, ob abrufen oder direkt antworten. Lass das Modell nicht auf eigenständig entscheiden, denn „aus dem Gedächtnis statt aus den neuesten Daten antworten

1 „Gefällt mir“
4

@James198 Noch ein Punkt, der für die Aufteilung spricht: Jetzt kannst du jeden Job (Sub-Workflow) und seine Tools auf das Modell abstimmen, das für diesen Teil des Jobs am besten funktioniert. Haiku ist beim Tool Calling furchtbar, genauso wie GPT 4 mini, aber Sonnet und GPT 5 funktionieren erstaunlich gut damit. Und wenn du Teile deines Workflows separierst, kannst du deine Ausgabe wirklich optimieren und verfeinern.

5

Das Problem mit falschen Branches ist interessant. Wenn es die falsche Spur wählt, sind es normalerweise immer die gleichen paar Branches, die verwechselt werden, oder ist das zufällig über alle verteilt? Und wenn es aus dem Speicher antwortet, anstatt den Vector Store abzufragen, passiert das bei einem bestimmten Anfrage-Typ (wie Status-Abfragen vs. Prozess-Auslösungen)?

Ich habe genau für dieses Muster Evaluierungs-Layer gebaut und würde gerne wissen, wie die Fehlerquote an einem typischen Tag aussieht. Die Sub-Agent-Aufteilung, die die anderen erwähnt haben, hilft, aber es gibt normalerweise immer noch eine Klassifizierungs-dann-Routing-Entscheidung, die auch nach der Aufteilung fragil ist.

6

Das Skip-Retrieval- / Wrong-Branch- / Answer-from-Memory-Ding ist der nützliche Teil. Ich nehme einen Production-Workflow für fünf Tage und sende eine geschwärzte Karte von zwei oder drei reproduzierten Fehlern, plus die erste Änderung und ein Rollback. Nur schriftlich. Du schreibst den Miss und den Workflow auf, zahlst, lässt geschwärzte Traces fallen. Keine Anrufe, kein Rewrite. Was hat der letzte Miss gekostet?