TradingAgents: Framework Open Source de Trading LLM

La plupart des frameworks LLM multi-agents promettent plus qu’ils ne livrent. TradingAgents fait partie des exceptions : open-sourcé par Tauric Research avec un article arXiv, disponible en version 0.2.4, et construit autour d’une séparation nette des rôles. Le système reproduit un bureau de recherche : analystes fondamentaux, de sentiment, d’actualités et techniques, débat Haussier/Baissier, Trader, comité de gestion des risques, puis décision structurée journalisée pour audit.

Essayez Apidog aujourd’hui

Cet article explique ce que fait réellement TradingAgents, ce que la v0.2.4 apporte, comment le tester, et comment valider les couches LLM et données de marché avec Apidog. Si vous travaillez déjà sur les contrats d’agents, le guide agents.md pour les équipes API complète naturellement ce sujet.

En bref

• TradingAgents est un framework Python multi-agents pour workflows de trading, publié par Tauric Research avec arXiv 2412.20138.
• Il découpe le raisonnement en agents spécialisés : Analyste Fondamental, Analyste de Sentiment, Analyste d’Actualités, Analyste Technique, Chercheurs Haussiers/Baissiers, Trader et comité de Gestion des Risques.
• La v0.2.4 ajoute des sorties structurées, la reprise de points de contrôle LangGraph, des journaux de décision persistants et la prise en charge de DeepSeek, Qwen, GLM et Azure OpenAI.
• Le framework fonctionne avec des endpoints LLM compatibles OpenAI, ce qui facilite le passage entre modèles hébergés, locaux et auto-hébergés.
• Utilisez Apidog pour simuler les API de données de marché, rejouer le trafic LLM et comparer les coûts entre fournisseurs.
• Téléchargez Apidog pour intégrer ces vérifications à votre CI avant de confier un workflow à de l’argent réel.

Ce qu’est réellement TradingAgents

TradingAgents est un package Python avec CLI. Il décompose un workflow de trading en rôles spécialisés, chacun étant un agent LLM avec :

• une description de tâche claire ;
• un ensemble d’outils ciblés ;
• une place définie dans un graphe LangGraph ;
• une sortie transmise à l’étape suivante.

Le flux suit quatre grandes phases :

1. collecte de données ;
2. analyse spécialisée ;
3. débat et synthèse ;
4. décision, validation du risque et journalisation.

Le README précise qu’il s’agit de code de recherche, pas de conseil en investissement. C’est important : l’objectif est d’étudier l’effet d’une collaboration multi-agents par rapport à un prompt unique, pas de fournir un bot de trading prêt pour la production.

La partie intéressante côté ingénierie est la séparation des responsabilités :

• l’Analyste Fondamental évalue les données financières ;
• l’Analyste de Sentiment analyse les signaux sociaux ;
• l’Analyste d’Actualités surveille les informations macroéconomiques ;
• l’Analyste Technique calcule des indicateurs comme MACD et RSI ;
• les Chercheurs Haussiers et Baissiers débattent ;
• le Trader synthétise et propose un plan ;
• la Gestion des Risques challenge la décision.

C’est un modèle réutilisable pour beaucoup de workflows agentiques : spécialistes, débat, décision, validation, audit.

Ce que la v0.2.4 apporte

La version 0.2.4 est notable pour les équipes qui veulent tester TradingAgents de manière plus fiable.

Sorties structurées

Le Responsable de Recherche, le Trader et le Gestionnaire de Portefeuille produisent désormais des sorties structurées via l’API de Réponses OpenAI ou le canal d’utilisation d’outils d’Anthropic.

Au lieu de parser du texte libre, vous pouvez valider du JSON typé en aval.

Exemple d’assertion utile :

{
  "ticker": "AAPL",
  "decision": "BUY",
  "confidence": 0.72,
  "rationale": "...",
  "risk_notes": ["..."]
}

À tester systématiquement :

• le champ decision existe ;
• la valeur est dans une liste autorisée ;
• confidence est numérique ;
• rationale n’est pas vide ;
• les notes de risque sont présentes.

Reprise des points de contrôle LangGraph

Les exécutions longues peuvent reprendre depuis un checkpoint. Si une API de marché ralentit ou si un fournisseur LLM renvoie une erreur 429, l’exécution ne repart pas forcément de zéro.

C’est utile pour :

• les batchs de plusieurs tickers ;
• les backtests ;
• les runs coûteux avec débat multi-agents ;
• les tests CI où les fournisseurs externes peuvent être instables.

Journal de décision persistant

Chaque décision du Trader est enregistrée dans SQLite avec :

• les entrées ;
• le raisonnement ;
• la décision ;
• les horodatages.

Ce journal devient votre base d’audit et de comparaison entre fournisseurs LLM.

Prise en charge multi-fournisseurs

La v0.2.4 ajoute DeepSeek, Qwen, GLM et Azure OpenAI à la liste existante incluant OpenAI, Anthropic, Gemini et Grok.

Si vous voulez tester un modèle de raisonnement moins coûteux par jeton, vous pouvez utiliser DeepSeek V4 via son endpoint compatible OpenAI. Si votre priorité est le contexte long ou la vision, vous pouvez tester Gemini.

Docker et correctif UTF-8 Windows

Le framework fournit aussi un Dockerfile, et le bug d’encodage des chemins Windows présent en v0.2.3 est corrigé.

Ce n’est pas spectaculaire, mais c’est essentiel pour des exécutions reproductibles.

Architecture de l’agent

Une exécution complète ressemble à ceci :

1. La CLI reçoit un symbole boursier et une date.
2. Les quatre analystes récupèrent leurs données et rédigent leurs rapports.
3. Les Chercheurs Haussier et Baissier débattent à partir de ces rapports.
4. Le Responsable de Recherche synthétise le débat.
5. Le Trader produit un plan de trading.
6. Trois agents de risque — Agressif, Conservateur, Neutre — challengent le plan.
7. Le Gestionnaire de Portefeuille approuve ou demande une révision.
8. La décision finale est enregistrée dans SQLite.

La majeure partie du coût LLM se situe dans les phases de débat : recherche Haussier/Baissier et gestion des risques.

Les petits modèles ont tendance à produire des débats répétitifs ou bruyants. Les modèles de raisonnement comme DeepSeek V4 en mode pensée, GPT-5.5 ou Claude 4.5 produisent généralement des échanges plus structurés.

Pourquoi tester la couche LLM avec un outil API

Deux surfaces échouent souvent en production :

1. les API de données de marché ;
2. les API des fournisseurs LLM.

Côté données de marché, les problèmes typiques sont :

• limites de débit variables ;
• champs non documentés ;
• renommages de propriétés ;
• différences de calendrier entre fournisseurs ;
• réponses incomplètes selon le plan utilisé.

Une exécution qui fonctionne mardi peut casser mercredi parce qu’un fournisseur a renommé regularMarketTime en regular_market_time.

Côté LLM, les problèmes sont différents :

• coûts variables selon le mode de raisonnement ;
• formats de réponse différents entre OpenAI, Anthropic et endpoints compatibles OpenAI ;
• blocs d’outils difficiles à parser ;
• JSON partiellement valide ;
• erreurs 429 ou timeouts.

Dans les deux cas, il faut des requêtes canoniques, rejouables, avec assertions. C’est précisément le rôle d’Apidog. Le même modèle est détaillé dans le guide de test de serveur MCP.

Simuler les API de données de marché dans Apidog

Objectif : rendre les tests TradingAgents déterministes.

Étape 1 : définir les endpoints fournisseurs

Dans un projet Apidog, ajoutez les endpoints que TradingAgents appelle :

• Yahoo Finance ;
• FinnHub ;
• Polygon ;
• OpenBB.

Pour chaque endpoint :

1. créez une requête ;
2. ajoutez les paramètres attendus ;
3. enregistrez une réponse réelle comme exemple ;
4. documentez les champs utilisés par le framework.

Exemple de fixture simplifiée :

{
  "symbol": "AAPL",
  "regularMarketPrice": 192.3,
  "regularMarketTime": 1777564800,
  "currency": "USD"
}

Étape 2 : activer le serveur de simulation

Activez le serveur de mock Apidog et pointez la configuration des outils TradingAgents vers cette URL.

Résultat :

• l’Analyste Fondamental reçoit toujours la même réponse ;
• les tests ne dépendent plus de Yahoo ou FinnHub ;
• les limites de débit ne cassent plus vos runs CI ;
• les régressions deviennent reproductibles.

Étape 3 : détecter les dérives fournisseur

Une fois par semaine, rejouez les endpoints en direct et comparez-les aux fixtures enregistrées.

À surveiller :

• champs supprimés ;
• champs renommés ;
• types modifiés ;
• nouvelles structures imbriquées ;
• réponses vides sur certains tickers.

Apidog met ces différences en évidence. C’est le même principe que dans le développement d’API contract-first.

Tester la couche fournisseur LLM

Avant d’augmenter le volume de runs, testez trois points.

1. Coût par rôle

Exécutez un seul ticker avec :

• les quatre analystes ;
• le débat Haussier/Baissier ;
• le Trader ;
• la Gestion des Risques.

Capturez le nombre de tokens par agent dans le journal de requêtes d’Apidog.

Le débat Haussier/Baissier coûte souvent 3 à 5 fois plus que les analystes. Si ce n’est pas le cas, le modèle court-circuite peut-être le raisonnement.

2. Forme de sortie

Les agents à sortie structurée doivent toujours renvoyer du JSON valide.

Ajoutez des assertions JSONPath, par exemple :

$.decision
$.confidence
$.rationale
$.risk_notes

Vérifiez aussi les types :

$.confidence is number
$.decision in ["BUY", "SELL", "HOLD"]
$.rationale is not empty

Une régression de forme est dangereuse : le texte peut sembler correct, mais le pipeline aval peut planter.

3. Parité entre fournisseurs

Si vous comparez OpenAI et DeepSeek V4, ne regardez pas un seul ticker.

Procédure plus fiable :

1. choisissez 50 tickers ;
2. exécutez-les avec OpenAI ;
3. exécutez-les avec DeepSeek V4 ;
4. comparez les journaux SQLite ;
5. mesurez les écarts de décision ;
6. inspectez les cas où les décisions divergent.

Les décisions individuelles peuvent différer, mais les tendances doivent rester cohérentes sur un volume suffisant.

Pour la forme des requêtes, consultez le guide API DeepSeek V4 et le guide API GPT-5.5.

Exécution minimale de TradingAgents

Le démarrage rapide ressemble à ceci :

git clone https://github.com/TauricResearch/TradingAgents
cd TradingAgents
pip install -r requirements.txt

export OPENAI_API_KEY="sk-..."
export FINNHUB_API_KEY="..."

python -m tradingagents.cli \
  --ticker AAPL \
  --date 2026-04-30 \
  --models gpt-5.5 \
  --rounds 2

Deux tours de débat constituent une exécution minimale significative.

Les résultats sont générés dans :

tradingagents/results/

Vous y trouverez généralement :

• des fichiers JSON ;
• un résumé markdown ;
• les éléments de décision exploitables pour audit.

Pour tester DeepSeek V4 Pro sur les rôles gourmands en raisonnement :

export DEEPSEEK_API_KEY="sk-..."

python -m tradingagents.cli \
  --ticker AAPL \
  --date 2026-04-30 \
  --models deepseek-v4-pro \
  --provider deepseek \
  --rounds 2

Le même principe s’applique à Qwen 3.6, GLM 5 ou aux modèles locaux servis par Ollama ou vLLM. Pour la partie locale, consultez l’article sur les meilleurs LLM locaux de 2026.

Pièges courants

Utiliser un modèle trop petit

Un modèle local 7B peut produire un débat Haussier/Baissier répétitif, sans résolution claire.

Pour ce type de workflow, utilisez au minimum un modèle avec une capacité de raisonnement intermédiaire : DeepSeek V4 Flash, Qwen 3.6 32B, GPT-5.5 ou Claude 4.5.

Oublier la mise en cache des données de marché

Chaque analyste peut appeler la couche de données séparément.

Sans cache, une seule exécution peut déclencher 4 à 8 requêtes fournisseur. Activez la mise en cache pour éviter d’épuiser rapidement les quotas.

Le traiter comme un bot de trading

TradingAgents reste du code de recherche.

Les résultats dépendent de nombreux paramètres :

• modèle choisi ;
• seed ou formulation des prompts ;
• nombre de tours de débat ;
• qualité des données ;
• fournisseur de marché ;
• date d’exécution.

Traitez chaque sortie comme une hypothèse, pas comme une stratégie financière.

Ne pas journaliser les coûts

Une exécution sur un ticker peut coûter de 0,10 $ à 5 $ selon le modèle et le nombre de tours.

Journalisez le coût par run dans l’historique de relecture d’Apidog. Une boucle non contrôlée dans la phase de débat peut coûter cher très rapidement.

Coder en dur un seul fournisseur

La prise en charge multi-fournisseurs existe pour tester et comparer.

Avant de choisir un modèle :

1. lancez un petit lot de tickers ;
2. exécutez-le avec plusieurs fournisseurs ;
3. comparez les journaux de décision ;
4. mesurez coût, stabilité et qualité de sortie.

Où Apidog s’intègre dans le cycle de développement

Apidog s’intègre à trois endroits concrets.

1. Conception des contrats d’API

Avant de connecter TradingAgents à des fournisseurs réels, modélisez chaque endpoint de données de marché dans Apidog.

Cela vous force à clarifier :

• quels champs sont réellement utilisés ;
• quels champs sont optionnels ;
• quels types sont attendus ;
• quelles erreurs doivent être gérées.

Beaucoup d’équipes découvrent à cette étape qu’elles paient pour des données qu’elles consomment très peu.

2. Intégration continue locale

Le serveur de simulation Apidog peut remplacer les fournisseurs externes pendant les tests unitaires.

Avantages :

• tests plus rapides ;
• pas de dépendance aux heures de marché ;
• pas de quota consommé ;
• données reproductibles ;
• CI plus stable.

Ce modèle est aussi détaillé dans l’article sur le test d’API sans Postman.

3. Diff de régression

Planifiez un replay hebdomadaire contre les endpoints live.

Comparez ensuite les réponses aux fixtures enregistrées.

C’est une alarme simple pour détecter :

la couche de données a changé, et les agents risquent maintenant de raisonner sur des champs absents ou incorrects.

Pourquoi cela dépasse le trading

TradingAgents est surtout intéressant comme exemple open-source de décomposition agentique.

Le modèle se transpose à d’autres domaines :

• support client : agents par type de ticket, débat, décision ;
• revue de code : agents sécurité, performance, style, synthèse ;
• conformité : analystes de données, examinateurs de risque, comité ;
• veille documentaire : lecteurs spécialisés, débat, synthèse ;
• analyse d’incident : collecte, hypothèses concurrentes, décision, post-mortem.

Si vous construisez un workflow agentique multi-étapes, le code de TradingAgents mérite d’être lu. Les patterns importants sont :

• séparation stricte des rôles ;
• débat contrôlé ;
• sortie structurée ;
• journal persistant ;
• validations en aval ;
• tests reproductibles avec Apidog.

Cas d’utilisation réels

• Un étudiant en recherche quantitative compare DeepSeek V4, GPT-5.5 et Claude 4.5 sur le même panier de 30 tickers. Apidog capture chaque requête et réponse pour rendre l’expérience reproductible.
• Un ingénieur fintech réutilise le modèle multi-agents pour des revues de code internes : sécurité, performance, conventions de nommage, puis synthèse dans une PR. Coût estimé par revue : environ 0,04 $.
• Un développeur solo exécute TradingAgents chaque nuit sur une watchlist de 10 tickers, journalise les décisions dans Postgres, et utilise le serveur de simulation Apidog pour les tests du week-end.

Conclusion

TradingAgents est un exemple clair de système LLM multi-agents produisant des décisions structurées plutôt que de simples conversations. La v0.2.4 le rend plus exploitable : sorties structurées, checkpoints LangGraph, audit persistant et multi-fournisseurs.

Mais le framework ne vaut que si vous testez correctement ses dépendances :

• fournisseurs LLM ;
• données de marché ;
• formats de sortie ;
• coûts ;
• dérives entre fournisseurs.

À retenir :

• TradingAgents découpe le trading en agents spécialisés avec rôles clairs et débat.
• La v0.2.4 ajoute sorties structurées, checkpoints et nouveaux fournisseurs.
• Simulez les données de marché dans Apidog pour rendre les tests déterministes.
• Testez la parité entre fournisseurs LLM avant de changer de modèle.
• Le pattern spécialistes → débat → décision → journal se réutilise dans beaucoup de workflows non liés au trading.

Étape suivante : clonez le dépôt, exécutez un ticker avec votre LLM préféré, puis faites passer les appels amont par un serveur de simulation Apidog. En moins d’une heure, vous saurez si TradingAgents correspond à votre workflow.

FAQ

Est-il sûr d’utiliser TradingAgents avec de l’argent réel ?

Le dépôt indique explicitement qu’il s’agit de code de recherche, pas de conseil financier. Traitez les sorties comme des hypothèses. Toute utilisation avec un courtier réel relève de votre propre responsabilité.

Quel fournisseur LLM offre le meilleur compromis coût-qualité ?

Pour beaucoup de charges de travail début 2026, DeepSeek V4 Flash avec mode de pensée offre un coût inférieur à GPT-5.5 tout en restant compétitif sur la qualité du débat Haussier/Baissier. Consultez le guide API DeepSeek V4 pour la forme des requêtes.

Puis-je exécuter TradingAgents sur des modèles locaux ?

Oui. La prise en charge multi-fournisseurs permet d’utiliser des endpoints compatibles OpenAI servis par Ollama, vLLM ou LM Studio. L’article sur les meilleurs LLM locaux de 2026 couvre les choix de modèles.

Comment simuler les API de données de marché ?

Définissez chaque endpoint fournisseur dans Apidog, activez le serveur de simulation, puis pointez la configuration des outils TradingAgents vers l’URL mock. Le même modèle est documenté dans les outils de test API pour les ingénieurs QA.

Quelle est la configuration matérielle minimale ?

Si vous utilisez des LLM hébergés comme OpenAI, Anthropic ou DeepSeek, un ordinateur portable avec Python 3.10+ suffit.

Si vous servez des modèles locaux, le matériel dépend du modèle :

• GPU 24 Go pour des modèles plus grands comme DeepSeek V4 Flash ou Qwen 3.6 32B ;
• GPU 8 Go pour des modèles plus petits comme Llama 5.1 8B.

La qualité baisse généralement avec les modèles plus petits.

Prend-il en charge la simulation après les heures de marché et le week-end ?

Les fournisseurs de données de marché peuvent renvoyer des données historiques, donc le framework peut exécuter une date donnée. Le trading live est un autre problème, que TradingAgents ne résout pas explicitement.

Comment se compare-t-il à d’autres frameworks multi-agents ?

TradingAgents est spécialisé pour le trading. CrewAI, AutoGen et LangGraph sont plus généralistes. Si vous voulez apprendre un pattern multi-agents concret, lisez TradingAgents. Si vous voulez construire un système générique, commencez par comprendre le code LangGraph sous-jacent.