Bonjour à tous,
J'ai un problème en utilisant le nœud AI Agent avec les modèles de raisonnement DeepSeek
(deepseek-v4-flash / deepseek-reasoner) et n'importe quel outil connecté.
**Erreur :**
400 Bad Request: Le reasoning_content en mode thinking doit être renvoyé à l'API.
**Ce qui se passe :**
Quand l'AI Agent invoque un outil lors d'une conversation, n8n semble supprimer le
champ reasoning_content du message de l'assistant avant de renvoyer l'historique
à l'API de DeepSeek. Depuis DeepSeek V3.2, ce champ est obligatoire dans les requêtes
d'appel d'outil multi-tours — sans lui, l'API rejette la requête avec une erreur 400.
**Étapes pour reproduire :**
1. Configurez un nœud AI Agent avec DeepSeek Chat Model (deepseek-v4-flash ou deepseek-reasoner)
2. Connectez n'importe quel outil (par ex. HTTP Request, Calculator)
3. Exécutez l'agent avec une invite qui déclenche l'utilisation d'un outil
4. Observez l'erreur 400
**Problèmes GitHub associés :**
- https://github.com/n8n-io/n8n/issues/22579
- https://github.com/n8n-io/n8n/issues/29119
- https://github.com/n8n-io/n8n/issues/29661
Cela semble affecter de nombreux utilisateurs. Quelqu'un a-t-il trouvé une solution
de contournement fonctionnelle, ou y a-t-il une date prévue pour un correctif officiel ?
Merci !
Bonjour @Hetvi_Shah
Veuillez utiliser ce nœud communautaire à la place pour désactiver le mode réflexion
https://www.npmjs.com/package/n8n-nodes-deepseek-v4
Remarque : Vous ne pouvez installer ce nœud que sur les instances n8n auto-hébergées. Les nœuds communautaires non vérifiés ne sont pas disponibles sur n8n Cloud.
Ceci se produit généralement dans la boucle d’appels d’outils, et non dans la première requête du modèle.
La séquence à vérifier est :
- La première réponse DeepSeek comprend
tool_callsplusreasoning_content. - n8n exécute l’outil.
- La requête suivante du modèle doit rejouer le message d’assistant avec la charge utile de raisonnement spécifique au fournisseur préservée.
Si l’étape 3 supprime reasoning_content, le mode de réflexion DeepSeek rejette la requête de suivi avec le 400 que vous voyez. La désactivation du mode de réflexion peut être une solution temporaire, mais le véritable correctif consiste à ce que l’adaptateur/nœud préserve et rejoue les charges utiles de raisonnement entre les appels d’outils.
Pour le débogage, capturez à la fois la réponse brute initiale et le corps de la requête sortante suivante. Si la première contient du contenu de raisonnement et la seconde ne le contient pas, le bogue se trouve dans le pont entre l’exécution de l’outil et l’appel chat-completions suivant.
Liste de contrôle connexe :
https://inferflow.hashnode.dev/deepseek-reasoning-content-and-openai-compatible-sse-debugging
Bienvenue @Hetvi_Shah!
C’est un problème connu que l’équipe n8n suit. La solution temporaire consiste à installer le nœud communautaire n8n-nodes-deepseek-v4 (Paramètres > Nœuds communautaires, auto-hébergé uniquement) et à désactiver le mode Thinking dans les paramètres du nœud - cela empêche la génération du champ reasoning_content et évite complètement l’erreur 400. Pour les utilisateurs du cloud, la seule option actuellement est d’éviter d’utiliser DeepSeek Reasoner comme modèle de base pour les agents compatibles avec les outils jusqu’à ce que le correctif officiel soit disponible. Vous pouvez suivre la progression du correctif dans les problèmes GitHub que vous avez déjà liés.
Bienvenue @Hetvi_Shah!
Bon rapport de problème avec les liens GitHub. Pour une solution pratique en production dès maintenant : basculez le modèle sur deepseek-chat (pas les variantes reasoner). Le modèle deepseek-chat n’inclut pas reasoning_content dans sa réponse, il n’y a donc rien à supprimer et la boucle d’appel d’outil fonctionne sans l’erreur 400. Vous perdez l’avantage de la chaîne de raisonnement, mais vous gagnez une exécution stable des outils. Si vous avez spécifiquement besoin du mode de raisonnement, le seul chemin fonctionnel pour le moment est via le nœud communautaire n8n-nodes-deepseek-v4 en auto-hébergé, qui inclut un bouton pour désactiver le mode de réflexion selon la suggestion de @kjooleng.
Bienvenue à nouveau @Hetvi_Shah 
Suite rapide à mes réponses précédentes, avec une solution de contournement plus robuste qui continue d’utiliser DeepSeek comme modèle de chat Agent IA avec outils.
Je viens de publier un nouveau nœud communautaire auto-hébergé appelé n8n-nodes-deepseek-chat-model qui expose une variante DeepSeek Chat Model (Corrected) spécifiquement accordée pour éviter l’erreur reasoning_content dans les boucles d’appel d’outils :
-
npm :
n8n-nodes-deepseek-chat-model -
Lien : https://www.npmjs.com/package/n8n-nodes-deepseek-chat-model
Au lieu de s’appuyer sur le mode réflexion et de combattre ensuite la charge utile, ce nœud vous permet d’exécuter DeepSeek en mode sans réflexion d’une manière qui fonctionne bien avec le flux d’appel d’outils de l’Agent IA, afin que vous ne voyiez plus :
Le reasoning_content en mode réflexion doit être renvoyé à l’API.
Comment l’utiliser (auto-hébergé uniquement)
-
Allez dans Paramètres → Nœuds communautaires sur votre n8n auto-hébergé
-
Cliquez sur Installer et collez :
n8n-nodes-deepseek-chat-model -
Après l’installation, redémarrez votre conteneur n8n pour que le nœud soit disponible partout (en particulier en mode file d’attente)
-
Dans le nœud Agent IA de votre flux de travail, définissez le modèle de chat sur DeepSeek Chat Model (Corrected)
-
Désactivez le mode réflexion dans les paramètres de ce nœud
-
Gardez vos outils configurés comme d’habitude et exécutez l’agent
Avec cette configuration, DeepSeek s’exécute proprement avec les outils via l’Agent IA, et le champ reasoning_content n’est jamais émis, donc l’erreur 400 disparaît sans avoir besoin d’aucun pont HTTP personnalisé.
Pour n8n Cloud, ce n’est toujours pas utilisable (nœud communautaire, auto-hébergé uniquement), mais pour quiconque en auto-hébergé qui a été bloqué par ce problème, ce devrait être un moyen pratique de mettre DeepSeek + outils en production pendant que l’équipe principale travaille sur un correctif de première partie.
Merci pour la contribution, j’avais le même problème, j’ai utilisé le nœud que tu as créé et j’ai pu le résoudre.
Je suis intéressé par apprendre à créer mes propres nœuds, tu as une recommandation pour commencer à les développer? Merci!
@EzeMorales Heureux que le nœud t’ait été utile ! Pour créer tes propres nœuds, le meilleur point de départ est le kit de démarrage pour nœuds communautaires n8n sur GitHub (cherche « n8n-nodes-starter » - il te fournit un échafaudage TypeScript complet avec la bonne structure). Les points clés à comprendre dès le départ : chaque nœud est une classe avec un objet description (définit les champs/identifiants) et une méthode execute() (ta logique). Regarde d’abord des nœuds communautaires plus simples pour voir des motifs réels - le code source du nœud DeepSeek est une bonne référence puisque tu sais déjà ce qu’il fait. La section des docs n8n sur « Creating nodes » te guide dans l’ensemble du flux depuis la configuration du développement jusqu’à la publication npm.
Nous suivons cela en interne sous la référence AI-2422 pour résoudre ce problème.
La meilleure façon de commencer est de suivre le processus dans la documentation pour utiliser la nouvelle option CLI, ce que nous recommandons à quiconque souhaite créer un nœud. Le dépôt de démarrage GitHub provient de cet outil CLI mais pourrait être quelques versions en retard.
J’ai trouvé une solution temporaire en attendant que l’équipe n8n résolve ce problème (AI-2422).
Utilisez le nœud ‘OpenRouter Chat Model’ comme modèle pour l’agent IA et configurez OpenRouter pour acheminer les requêtes vers un modèle DeepSeek, tel que deepseek-v4-flash.
Lorsque vous utilisez votre propre clé API de fournisseur dans OpenRouter via BYOK, le premier million de requêtes BYOK par mois sont exemptés des frais de service d’OpenRouter.
Avec cette configuration, je peux continuer à utiliser le mode de raisonnement et les capacités d’appel d’outils de DeepSeek dans n8n en attendant la résolution du problème.
