Tool-Calling-Fehler bei Agents mit OpenRouter (verschiedene Modelle)

Fragen
1

Problem/Fehler/Frage beschreiben

Ich habe ein Problem mit Tool-Aufrufen, bei denen Agenten leere Tool-Aufrufe generieren, wenn sie in einem Flow verwendet werden.

Flow-Setup: Schedule-Trigger-Node → AI Agent (mit openrouter + Tool) → Merge-Node (und weitere getestete)

Wenn ich den AI Agent mit der Schaltfläche “Execute step” ausführe, funktioniert das Tool perfekt. Aber wenn ich den Node als Teil des Flows ausführe, einschließlich live-Produktions-Flows, schlagen die Tool-Aufrufe stillschweigend fehl (sie scheinen vom Agent in der Benutzeroberfläche nicht einmal verwendet zu werden, aber sie erscheinen in den Logs als leere Aufrufe). Manchmal erscheinen sie leer und manchmal erscheinen sie in der Eingabe des AI Agents.

Hinweise:

  • Verschiedene Modelle getestet und ich habe sichergestellt, dass sie ausreichende Token-Kontextlängen haben. Ich habe dieses Problem bei mindestens 6 verschiedenen Tool-fähigen Modellen unterschiedlicher Kosten gefunden.
  • Verschiedene Tools getestet (brave search, gmail, http node) – alle schlugen auf die gleiche Weise fehl

Hat jemand Erfahrung mit der Behebung dieses Problems oder handelt es sich um einen Bug?

Fehlermeldung (falls vorhanden)?

Keine Fehlermeldung, aber Tool-Aufrufe kommen leer zurück, wenn sie als Teil eines Flows ausgeführt werden

Bitte teile deinen Workflow

Korrekt: Mit der Schaltfläche “Execute step”
Tool-Aufrufe funktionieren gut, Ein- und Ausgabe funktionieren. Die Node-Benutzeroberfläche (nicht abgebildet) leuchtet auch grün mit Häkchen auf

image
image1483×264 24.3 KB

Buggy: Innerhalb eines Flows
Die Tools erscheinen während der Laufzeit nicht in den Logs, erscheinen aber magischerweise am Ende, jedoch handelt es sich um leere Aufrufe und sie scheinen Dinge wie das Einfügen von Tool-Aufrufen in die Eingabe zu tun.

image
image1422×192 19.8 KB

Beispiel eines Tool-Aufrufs in der AI-Eingabe
image

Beispiel eines Tool-Fehlers in der Benutzeroberfläche, das einen Tool-Aufruf in den Logs zeigt, aber nicht in der Benutzeroberfläche

image
image813×759 54.5 KB

Beispiel eines Tool-Betriebs bei Verwendung von “Execute step”

image
image618×793 48.9 KB

Zugehöriges Problem: Tool calling bug for agents using OpenRouter (various models) · Issue #29758 · n8n-io/n8n · GitHub

(Wähle die Nodes auf deinem Canvas aus und verwende die Tastaturkürzel CMD+C/CTRL+C und CMD+V/CTRL+V, um den Workflow zu kopieren und einzufügen.)

Gebe die vom letzten Node zurückgegebene Ausgabe an

Beispiel beim Fehlschlag
[ { "response": { "generations": [ [ { "text": "Es tut mir leid, aber ich konnte keine relevanten Informationen in den für mich zugänglichen E-Mails finden. Kann ich dir noch bei etwas anderem helfen?", "generationInfo": { "finish_reason": "stop" } } ] ] }, "tokenUsage": { "completionTokens": 31, "promptTokens": 607, "totalTokens": 638 } } ]

Informationen zu deinem n8n-Setup

  • n8n-Version: 2.18.7
3

Das ist zu erwarten. Nicht alle KI-Modelle funktionieren zuverlässig mit Tool-Aufrufen.
Welche Modelle verwendest du?
Das Deklarieren eines Tool-Calling-Schemas kann die Zuverlässigkeit deiner Tool-Aufrufe verbessern.
Du musst Versuch und Irrtum anwenden

4

Das n8n AI-Team hat dieses Problem bereits identifiziert. Der verknüpfte GitHub-Issue wurde mit den Status-Labels “status:in-linear” und “team:ai” markiert, was bedeutet, dass das Team derzeit daran arbeitet.
Das Problem hängt damit zusammen, wie der AI Agent-Knoten mit dem Kontext interagiert, wenn er Schritt für Schritt ausgeführt wird, im Vergleich zur Ausführung als Teil des gesamten Workflows. Bei der Ausführung als Teil des Workflows wird der OpenRouter-Eingabekontext-Trigger entweder im Tool-Call-Schema ignoriert oder in den Prompt eingebettet, was verhindert, dass Funktionsaufrufe ausgeführt werden können. Dies ist kein OpenRouter-spezifisches Problem, sondern tritt aufgrund von n8ns Anforderungen während der Produktionsausführung auf.
Derzeit ist die einzige zuverlässige Lösung, den AI Agent nicht direkt nach Knoten in der Produktion zu verketten. Verwende stattdessen einen Test mit einem einfachen Setup aus Trigger → Agent → Output, um ihn zu isolieren, und behalte den Fix im GitHub-Issue im Auge:

Verwendest du n8n Cloud oder hast du deine eigene selbstgehostete Version mit Docker? Die Debug-Informationen zeigen, dass du die Docker-Version (Cloud) 2.18.7 verwendest. Das ist eine nützliche Information, da der Fix wahrscheinlich in einer Patch-Version verfügbar sein wird und es sinnvoll ist zu wissen, wann Updates durchgeführt werden sollten.

Hallo Miliaga, danke für deine Antwort! Ich werde versuchen, die Informationen vorerst auf eine andere Weise zu analysieren, um eine Lösung zu finden.

Ich verwende n8n Cloud und werde auf die Aktualisierung warten.

5

@ChrisA Schnelle Lösung bis der Fix ausgerollt wird: Tauschen Sie das OpenRouter Chat Model gegen das OpenAI Chat Model Node aus. In den OpenAI-Anmeldedaten setzen Sie die Base URL auf OpenRouter und fügen Sie Ihren OpenRouter-Schlüssel ein. Modellname = Ihr Slug (z. B. anthropic/claude-3.5-sonnet), dann verbinden Sie ihn neu mit dem Agent. Wenn Sie n8ns OpenAI-Pfad verwenden, umgehen Sie den Schema-Bug, der diese leeren finish_reason: stop Aufrufe verursacht, wenn der Agent von einem Trigger aus statt vom Execute Step ausgelöst wird.

6

Großartiger Thread, @ChrisA! Gut, dass das n8n-Team das bereits im Blick hat.

Nur um ein bisschen mehr Kontext zu geben, warum das passiert: Die Abweichung zwischen “Execute step” und vollständiger Workflow-Ausführung kommt daher, wie der Execution Context konstruiert wird. Wenn du über Execute Step auslöst, erstellt n8n einen frischen Context nur für diesen Node. Aber in einem vollständigen Workflow wird der Upstream-Context vom Schedule Trigger weitergeleitet, und die Schema-Verarbeitung des OpenRouter Chat Model Node verarbeitet das finish_reason: stop Signal in diesem Szenario nicht korrekt, was dazu führt, dass der Agent den Tool Call ganz überspringt.

@achamm’s Workaround ist genau richtig - die Verwendung des OpenAI Chat Model Node mit Base URL, die auf OpenRouter zeigt, ist derzeit die zuverlässigste Lösung, da er n8ns nativen OpenAI-Code-Pfad nutzt, der das Schema korrekt verarbeitet.

Es gibt noch ein paar andere Dinge, die du versuchen kannst, während du auf den offiziellen Fix wartest:

  • Wechsel zu einem Modell, das direkt auf OpenRouter gehostet wird, aber bekanntermaßen OpenAI-kompatibel in seinem tool_call Schema ist (wie openai/gpt-4o-mini via OpenRouter), um einzugrenzen, ob es eine modellspezifische Schema-Abweichung ist
  • Versuche, nur den AI Agent Node in seinen eigenen Sub-Workflow mit einem manuellen Trigger zu verpacken, um jegliche Upstream-Context-Überlauf zu eliminieren

Hoffen wir, dass der Patch bald auf n8n Cloud landet!