Bug d'appel d'outils pour les agents utilisant OpenRouter (divers modèles)

Questions
1

Décrivez le problème/l’erreur/la question

J’ai trouvé un problème avec l’appel d’outils où les agents produisent des appels d’outils vides lorsqu’ils sont utilisés dans un flux.

Configuration du flux : Nœud de déclencheur calendaire → Agent IA (avec openrouter + outil) → Nœud de fusion (et autres testés)

Lorsque j’exécute l’agent IA à l’aide du bouton « Exécuter l’étape », l’outil fonctionne parfaitement, mais lors de l’exécution du nœud dans le cadre du flux, y compris les flux en production en direct, les appels d’outils échouent silencieusement (ils ne semblent pas être utilisés par l’agent dans l’interface utilisateur, mais ils apparaissent dans les journaux comme des appels vides). Parfois, ils apparaissent vides et parfois ils apparaissent dans l’entrée de l’agent IA.

Remarques :

  • Divers modèles testés et j’ai vérifié qu’ils avaient des longueurs de contexte de jeton suffisantes. J’ai trouvé ce problème sur au moins 6 modèles différents capables d’utiliser des outils et de coûts variés.
  • Divers outils testés (recherche brave, gmail, nœud http) ont tous échoué de la même manière

Quelqu’un a-t-il de l’expérience pour corriger cela ou s’agit-il d’un bug ?

Quel est le message d’erreur (le cas échéant) ?

Pas de message d’erreur, mais les appels d’outils reviennent vides lorsqu’ils sont exécutés dans le cadre d’un flux

Veuillez partager votre flux de travail

Correct : Utiliser le bouton « Exécuter l’étape »
Les appels d’outils fonctionnent bien ainsi que l’entrée et la sortie. L’interface utilisateur du nœud (non illustrée) s’illumine également en vert avec des coches

image
image1483×264 24.3 KB

Bugué : Depuis l’intérieur d’un flux
Les outils pendant l’exécution n’apparaissent pas dans les journaux mais apparaissent miraculeusement à la fin, cependant, ce sont des appels vides et ils semblent faire des choses comme injecter des appels d’outils dans l’entrée.

image
image1422×192 19.8 KB

Exemple d’appel d’outil dans l’entrée de l’IA
image

Exemple d’échec d’outil dans l’interface utilisateur montrant un appel d’outil dans les journaux mais pas dans l’interface utilisateur

image
image813×759 54.5 KB

Exemple d’outil fonctionnant correctement lors de l’utilisation d’« Exécuter l’étape »

image
image618×793 48.9 KB

Problème associé : Tool calling bug for agents using OpenRouter (various models) · Issue #29758 · n8n-io/n8n · GitHub

(Sélectionnez les nœuds sur votre canevas et utilisez les raccourcis clavier CMD+C/CTRL+C et CMD+V/CTRL+V pour copier et coller le flux de travail.)

Partagez la sortie retournée par le dernier nœud

Exemple d’échec
[ { "response": { "generations": [ [ { "text": "I'm sorry, but I could not find any relevant information in the emails I have access to. Was there anything else I could help you with?", "generationInfo": { "finish_reason": "stop" } } ] ] }, "tokenUsage": { "completionTokens": 31, "promptTokens": 607, "totalTokens": 638 } } ]

Informations sur votre configuration n8n

  • Version n8n : 2.18.7
3

C’est normal. Tous les modèles d’IA ne fonctionnent pas de manière fiable avec les appels d’outils.
Quels modèles utilisez-vous ?
Déclarer le schéma d’appel d’outils peut améliorer la fiabilité de vos appels d’outils.
Vous devez procéder par essai-erreur

4

L’équipe IA de n8n a déjà identifié ce problème, le problème GitHub lié a été marqué avec le statut:in-linear et team:ai, ce qui signifie que ce problème est actuellement en cours de traitement.
Le problème est lié à la façon dont le nœud AI Agent interagit avec le contexte lorsqu’il est exécuté étape par étape par rapport à son exécution dans le cadre du workflow complet. Lorsqu’il est exécuté dans le cadre du workflow, le déclencheur de contexte d’entrée OpenRouter est soit ignoré dans le schéma d’appel d’outil, soit intégré tel quel dans l’invite et il ne peut effectuer aucun appel de fonction. Ce n’est pas un problème spécifique à OpenRouter, cela se produit en raison de la demande de n8n lors de l’exécution en production.
Actuellement, la seule solution de contournement cohérente est de ne pas chaîner directement le AI Agent après des nœuds en production, d’utiliser le test avec une configuration simple trigger → agent → output pour l’isoler, et de surveiller la correction dans le problème GitHub :

Utilisez-vous n8n Cloud, ou avez-vous votre propre version auto-hébergée avec docker ? Les informations de débogage montrent que vous utilisez la version docker (cloud) 2.18.7, je vérifie juste car la correction sera probablement dans une version de correctif, et il sera utile de savoir quand effectuer les mises à jour.

Bonjour Miliaga, merci pour votre réponse ! Je vais essayer d’analyser les informations d’une autre manière pour l’instant comme solution de contournement.

J’utilise n8n Cloud et je vais surveiller la mise à jour.

5

@ChrisA Solution temporaire en attente du correctif : remplacez le nœud OpenRouter Chat Model par le nœud OpenAI Chat Model. Dans les identifiants OpenAI, définissez l’URL de base sur OpenRouter et collez votre clé OpenRouter. Nom du modèle = votre slug (par exemple anthropic/claude-3.5-sonnet), puis reconnectez-le à l’Agent. En passant par le chemin OpenAI de n8n, on contourne le bug de schéma qui provoque ces appels finish_reason: stop vides quand l’agent se déclenche à partir d’un trigger au lieu d’une étape Execute.

6

Super thread, @ChrisA! C’est bien que l’équipe n8n suive déjà ce problème.

Juste pour ajouter un peu plus de contexte sur la raison pour laquelle cela se produit : la discordance entre « Execute step » et l’exécution du flux complet provient de la façon dont le contexte d’exécution est construit. Lorsque vous déclenchez via Execute Step, n8n crée un contexte frais pour ce seul nœud. Mais dans un flux complet, le contexte en amont du Schedule Trigger est transmis, et la gestion du schéma du nœud OpenRouter Chat Model ne traite pas correctement le signal finish_reason: stop dans ce scénario, ce qui amène l’agent à ignorer complètement l’appel d’outil.

La solution de contournement de @achamm est exactement correcte - utiliser le nœud OpenAI Chat Model avec une Base URL pointant vers OpenRouter est actuellement le correctif le plus fiable car il utilise le chemin de code OpenAI natif de n8n, qui traite correctement le schéma.

Quelques autres éléments utiles à essayer en attendant le correctif officiel :

  • Passez à un modèle hébergé directement sur OpenRouter mais connu pour être compatible OpenAI dans son schéma tool_call (comme openai/gpt-4o-mini via OpenRouter) pour déterminer si c’est une variance de schéma spécifique au modèle
  • Essayez d’envelopper uniquement le nœud AI Agent dans son propre sous-flux avec un déclencheur manuel pour éliminer toute fuite de contexte en amont

J’espère que le correctif arrivera bientôt sur n8n Cloud!