TradingAgents: Framework Open Source de Trading LLM

La plupart des frameworks LLM multi-agents promettent plus qu'ils ne livrent. TradingAgents est l'une des rares exceptions : open-sourcé par Tauric Research aux côtés d'un article arXiv, maintenant en version 0.2.4, et livrant le type de décomposition des rôles claire que d'autres frameworks décrivent mais implémentent rarement. Le système reproduit un véritable bureau de recherche : analystes fondamentaux, de sentiment, d'actualités et techniques alimentant un débat de recherche Haussier/Baissier, puis un Trader, puis un comité de gestion des risques, aboutissant à une décision structurée enregistrée pour audit.

Cet examen détaille ce que fait réellement TradingAgents, ce qui a été livré dans la v0.2.4, comment il se compare à LangGraph et CrewAI, et comment tester les couches LLM et de données de marché sous-jacentes avec Apidog. Si vous avez déjà approfondi la couche de contrat d'agent, notre guide agents.md pour les équipes API s'associe naturellement à cet article.

En bref

• TradingAgents est un framework de trading LLM multi-agents de Tauric Research, arXiv 2412.20138, open-sourcé en 2025 et maintenant en version 0.2.4.
• Il divise le trading en agents spécialisés : Analyste Fondamental, Analyste de Sentiment, Analyste d'Actualités, Analyste Technique, Chercheurs Haussiers/Baissiers, Trader et un comité de Gestion des Risques.
• La v0.2.4 a ajouté des agents à sortie structurée, la reprise des points de contrôle LangGraph, des journaux de décision persistants et la prise en charge des fournisseurs DeepSeek, Qwen, GLM et Azure OpenAI.
• Le framework fonctionne sur n'importe quel endpoint LLM compatible OpenAI, ce qui rend les modèles hébergés, locaux et auto-hébergés interchangeables.
• Utilisez Apidog pour simuler les API de données de marché sous-jacentes, rejouer le trafic des fournisseurs LLM et évaluer le coût du mode de pensée entre DeepSeek, OpenAI et Anthropic.
• Téléchargez Apidog pour intégrer tout cela dans votre CI avant de faire confiance à un agent avec de l'argent réel.

Ce qu'est réellement TradingAgents

Le framework est un package Python et une CLI qui décompose le flux de travail de trading en rôles spécialisés. Chaque rôle est un agent LLM invité avec une description de poste, ayant accès à un ensemble d'outils ciblés, et orchestré par LangGraph. Les décisions passent par des étapes : collecte de données, débat, décision, enregistrement.

Le README le décrit comme du code de recherche, pas un conseil en investissement. Ce cadrage est important. L'objectif est d'étudier comment la collaboration multi-agents modifie les résultats par rapport aux configurations à prompt unique, et non de livrer un bot de trading de production depuis votre ordinateur portable.

Ce qui est intéressant d'un point de vue ingénierie, c'est la propreté de la séparation des rôles. L'Analyste Fondamental évalue les données financières de l'entreprise. L'Analyste de Sentiment note les médias sociaux. L'Analyste d'Actualités surveille les indicateurs macroéconomiques. L'Analyste Technique calcule le MACD et le RSI. Les Chercheurs Haussiers et Baissiers débattent. Le Trader lit les rapports de tous et décide. La Gestion des Risques vérifie la décision par rapport aux contraintes. Chaque agent a un seul travail et un seul ensemble d'outils.

C'est le même modèle que vous concevriez pour tout flux de travail agentique complexe : rôles spécialisés, une phase de débat, une phase de décision et une étape de vérification. TradingAgents est une implémentation de référence fonctionnelle que vous pouvez lire en un après-midi.

Ce qui a été livré dans la v0.2.4

La version d'avril 2026 est significative pour les utilisateurs curieux de la production.

• Agents à sortie structurée. Le Responsable de Recherche, le Trader et le Gestionnaire de Portefeuille émettent désormais une sortie structurée via l'API de Réponses OpenAI ou le canal d'utilisation d'outils d'Anthropic. Cela remplace l'ancien analyse de texte libre par du JSON typé, ce qui rend l'automatisation en aval fiable.
• Reprise des points de contrôle LangGraph. Les exécutions de longue durée peuvent être mises en pause et redémarrées à partir d'un point de contrôle enregistré. Si une API de données de marché ralentit ou si un fournisseur LLM renvoie 429, l'exécution ne redémarre pas de zéro.
• Journal de décision persistant. Chaque décision prise par le Trader est enregistrée dans un journal SQLite avec le raisonnement, les entrées et les horodatages. Vous obtenez une piste d'audit que vous pouvez examiner ou réintroduire dans l'évaluation.
• Prise en charge multi-fournisseurs. La v0.2.4 a ajouté DeepSeek, Qwen, GLM et Azure OpenAI à la matrice existante d'OpenAI, Anthropic, Gemini et Grok. Si vous voulez le raisonnement le moins cher par jeton, vous pouvez passer à DeepSeek V4 via son endpoint compatible OpenAI. Si vous avez besoin d'un contexte long ou de vision, passez à Gemini.
• Prise en charge Docker et correctif UTF-8 Windows. Ennuyeux mais important : le framework fournit désormais un Dockerfile, et le bug d'encodage des chemins Windows de la v0.2.3 est corrigé.

L'architecture de l'agent en détail

Une exécution complète de TradingAgents se présente comme suit.

1. La CLI accepte un symbole boursier et une plage de dates.
2. L'équipe d'analystes se déploie : chacun des quatre analystes récupère indépendamment les données pour le symbole boursier et rédige un rapport.
3. L'équipe de recherche reprend les quatre rapports. Le Chercheur Haussier rédige une thèse longue. Le Chercheur Baissier rédige une thèse courte. Ils débattent.
4. Le Responsable de Recherche synthétise le débat en une recommandation.
5. Le Trader prend la recommandation, la vérifie par rapport au journal de décision persistant, et produit un plan de trading.
6. L'équipe de gestion des risques examine. Trois agents de risque (Agressif, Conservateur, Neutre) contestent le plan sous différents angles.
7. Le Gestionnaire de Portefeuille approuve ou renvoie le plan pour révision.
8. La décision finale est enregistrée dans le journal SQLite.

La majeure partie du coût LLM se situe aux étapes 3 et 6, où plusieurs agents débattent. C'est également là que les petits modèles sont exposés : un modèle 7B exécutant le débat Haussier/Baissier produit des arguments bruyants et répétitifs. Un modèle de raisonnement (mode de pensée DeepSeek V4, GPT-5.5, Claude 4.5) produit des échanges structurés qui ressemblent à une vraie réunion de recherche.

Pourquoi tester la couche LLM avec un outil API

Lorsque vous exécutez TradingAgents, deux surfaces échouent en production : les API de données de marché (Yahoo Finance, FinnHub, Polygon, OpenBB) et les API des fournisseurs LLM.

Le côté des données de marché est sale. Les niveaux gratuits ont des limites de débit incohérentes, des champs non documentés apparaissent et disparaissent, et les limites des jours de trading diffèrent selon les fournisseurs. Une exécution qui fonctionnait le mardi se brise silencieusement le mercredi parce qu'un fournisseur a renommé regularMarketTime en regular_market_time.

Le côté LLM est également sale, d'une manière différente. Le mode de pensée DeepSeek V4 double vos coûts ; l'API de Réponses OpenAI a ses propres particularités ; l'utilisation d'outils d'Anthropic renvoie des blocs de contenu que certains analyseurs en aval ont du mal à gérer.

Les deux surfaces attendent la même chose de vous : une collection de requêtes canoniques enregistrées et rejouables avec des assertions. C'est exactement à cela que sert Apidog. Nous avons couvert le même modèle de test au niveau du protocole dans le guide de test de serveur MCP.

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

Trois étapes pour éliminer la volatilité des fournisseurs de vos exécutions de test TradingAgents.

1. Étape 1 : définir les endpoints en amont. Dans un projet Apidog, ajoutez les endpoints Yahoo Finance, FinnHub, Polygon ou OpenBB que TradingAgents appelle. Le README de chaque spécification d'outil liste les URL exactes. Enregistrez chacun comme une requête avec des exemples de corps de réponse extraits de réponses réelles.
2. Étape 2 : activer le serveur de simulation. Le serveur de simulation d'Apidog renvoie les exemples de réponses sur les mêmes chemins d'URL que le fournisseur réel utilise. Pointez la configuration des outils de TradingAgents vers l'URL de simulation. L'Analyste Fondamental s'exécute désormais avec des données déterministes ; vos tests ne sont plus à la merci de la limite de débit de Yahoo.
3. Étape 3 : capturer les dérives des fournisseurs. Une fois par semaine, rejouez les endpoints en direct et comparez la forme de la réponse à vos fixtures enregistrées. Apidog met en évidence les champs ajoutés, supprimés ou renommés. C'est ainsi que vous détectez le renommage de regularMarketTime avant qu'il ne plante une exécution.

Nous utilisons le même modèle exact dans le développement d'API contract-first, qui décrit le flux de travail plus large.

Tester la couche du fournisseur LLM

La couche du fournisseur nécessite trois éléments à tester avant de monter en puissance les exécutions.

• Coût par rôle. Exécutez un seul symbole boursier à travers les quatre analystes et le débat. Capturez le nombre de jetons par agent dans le journal de requêtes d'Apidog. Le débat Haussier/Baissier est généralement 3 à 5 fois plus cher que les analystes ; sinon, le modèle est en court-circuit.
• Forme de la sortie. Les agents à sortie structurée de la v0.2.4 (Responsable de Recherche, Trader, Gestionnaire de Portefeuille) doivent toujours renvoyer du JSON bien formé. Ajoutez des assertions JSONPath dans Apidog pour vérifier. Une régression ici est silencieuse et dévastatrice ; vous ne le découvrez que lorsque le code en aval plante.
• Parité des fournisseurs. Lorsque vous passez d'OpenAI à DeepSeek V4 pour tester le coût, les décisions du Trader devraient différer sur les exécutions individuelles mais converger vers des conclusions similaires sur de nombreuses exécutions. Exécutez 50 symboles boursiers via les deux fournisseurs, comparez le journal de décision persistant et quantifiez la dérive. Notre guide API DeepSeek V4 couvre la forme de la requête ; notre guide API GPT-5.5 couvre le côté OpenAI. Le diff de réponse d'Apidog rend la comparaison visuelle.

Une exécution minimale de TradingAgents

Le démarrage rapide du README 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 l'exécution significative la plus petite. La sortie se trouve dans tradingagents/results/ sous forme de JSON et d'un résumé de décision en markdown.

Pour passer à DeepSeek V4 Pro pour les rôles gourmands en raisonnement, définissez l'indicateur --models et pointez le client OpenAI vers l'URL de base de DeepSeek via la configuration du fournisseur du framework :

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 modèle fonctionne pour Qwen 3.6, GLM 5, ou tout modèle local servi par Ollama ou vLLM. Notre article sur les meilleurs LLM locaux de 2026 couvre le côté de la diffusion locale.

Pièges courants

Ceux-ci apparaissent dans le fil des problèmes GitHub.

• Exécution avec un petit modèle. Un modèle local de 7B produit un débat Haussier/Baissier qui tourne en boucle sans se résoudre. Le framework nécessite au moins une qualité de raisonnement de niveau intermédiaire. DeepSeek V4 Flash, Qwen 3.6 32B, GPT-5.5 et Claude 4.5 sont le seuil réaliste.
• Omission de la mise en cache des données de marché. Chaque analyste appelle la couche de données séparément. Sans mise en cache, vous lancez 4 à 8 requêtes de fournisseurs par exécution et épuisez rapidement le budget de la limite de débit. Le framework prend en charge la mise en cache ; activez-la.
• Le traiter comme un bot de trading. C'est du code de recherche. La performance du backtest est sensible au choix du modèle, au prompt seed, à la durée du débat et à la qualité des données. Traitez tout chiffre qu'il produit comme une hypothèse, pas une stratégie.
• Oublier de journaliser les dépenses de jetons. Une seule exécution de symbole boursier peut coûter de 0,10 $ à 5 $ selon le modèle et les tours. Journalisez le coût par exécution dans l'historique de relecture d'Apidog ; une boucle incontrôlée dans la phase de débat peut accumuler de l'argent réel en quelques minutes.
• Coder en dur un seul fournisseur. La v0.2.0 a ajouté la prise en charge multi-fournisseurs précisément pour que vous puissiez échanger. Utilisez-la. Exécutez un petit lot via trois fournisseurs et comparez le journal de décision avant de vous engager.

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

Trois endroits concrets où Apidog s'avère indispensable dans un projet TradingAgents.

Le premier est la surface de conception. Avant de connecter le framework à des fournisseurs en direct, esquissez chaque endpoint de données de marché dans Apidog comme une requête avec des corps d'exemple. La vue du schéma vous oblige à être honnête sur les champs que le framework utilise réellement. De nombreuses équipes découvrent qu'elles payaient pour un plan Polygon qu'elles consommaient à peine.

Le second est l'intégration continue locale. Le serveur de simulation d'Apidog remplace chaque fournisseur pendant l'exécution des tests unitaires, de sorte que la suite de tests reste sous les cinq secondes et ne dépend plus des heures de marché du week-end. Nous avons couvert ce modèle exact dans le test d'API sans Postman.

Le troisième est le diff de régression. Chaque semaine, rejouez les endpoints en direct par rapport à vos fixtures enregistrées. Apidog met en évidence les renommages de champs et les dérives de forme. C'est l'alarme la moins chère possible pour "la couche de données est cassée et les agents ont commencé à halluciner des chiffres".

Pourquoi cela importe au-delà du trading

TradingAgents est l'exemple open-source le plus clair de décomposition agentique que nous ayons actuellement. Le modèle se transfère directement à :

• Triage du support client (agents analystes par type de ticket, débat, décision)
• Revue de code (agents de sécurité, de performance, de style, puis un synthétiseur)
• Examen de conformité (analystes de données, examinateurs de risques, comité de décision)
• Synthèse de recherche (plusieurs lecteurs spécialisés, débat, synthèse)

Si vous concevez un flux de travail d'agent multi-étapes, lisez d'abord le code TradingAgents. La séparation des rôles, la phase de débat, les décisions à sortie structurée et le journal persistant sont des modèles réutilisables. Ce sont également des modèles testables, ce qui est le but d'associer le framework à Apidog.

Cas d'utilisation réels

• Un étudiant en recherche quantitative utilise TradingAgents pour comparer DeepSeek V4 vs GPT-5.5 vs Claude 4.5 sur le même panier de 30 symboles boursiers. Apidog capture chaque requête et réponse afin que la comparaison soit reproductible.
• Un ingénieur fintech utilise le modèle multi-agents (pas le code de trading) pour effectuer des revues de code sur des services internes. Des agents spécialisés vérifient la sécurité, la performance, la nomenclature. Un synthétiseur rédige le commentaire de la PR. Coût total de la revue par PR : environ 0,04 $.
• Un développeur solo exécutant TradingAgents toutes les nuits sur une liste de surveillance de 10 symboles boursiers enregistre chaque décision dans Postgres pour une inspection ultérieure. Le serveur de simulation Apidog remplace les fournisseurs de données de marché en direct pendant les exécutions de test du week-end.

Conclusion

TradingAgents est un exemple fonctionnel et bien architecturé de la façon de construire un système LLM multi-agents qui produit des décisions structurées plutôt que du chat. La v0.2.4 le rend intéressant pour la production : sorties structurées, reprise des points de contrôle, piste d'audit, multi-fournisseurs. Rien de tout cela n'importe si vous ne pouvez pas tester les couches LLM et de données de marché sous-jacentes. C'est là que l'associer à Apidog prend tout son sens.

• TradingAgents décompose le trading en agents spécialisés avec des rôles clairs et une phase de débat.
• La v0.2.4 ajoute des sorties structurées, des points de contrôle LangGraph et des fournisseurs DeepSeek/Qwen/GLM/Azure.
• Simulez les fournisseurs de données de marché dans Apidog pour que les exécutions de test soient déterministes.
• Testez la parité des fournisseurs LLM avant d'échanger des modèles en production.
• Le modèle (spécialistes, débat, décision, journal) se transfère à chaque flux de travail d'agent non lié au trading que vous construisez.

Étape suivante : clonez le dépôt, exécutez un seul symbole boursier avec votre LLM préféré et faites passer les appels en amont par un serveur de simulation Apidog. Vous saurez en moins d'une heure si le framework correspond à votre flux de travail.

FAQ

• Est-il sûr d'utiliser TradingAgents avec de l'argent réel ?Le dépôt stipule explicitement qu'il s'agit de code de recherche et non de conseil financier. Traitez sa sortie comme une hypothèse. Quiconque l'utilise avec un courtier en direct prend personnellement le risque ; les mainteneurs ne l'approuvent pas.
• Quel fournisseur LLM offre le meilleur compromis coût-qualité ?Pour la plupart des charges de travail début 2026, DeepSeek V4 Flash avec mode de pensée surpasse GPT-5.5 en termes de coût avec une large marge et l'égale en termes de qualité de débat Haussier/Baissier. Consultez notre guide API DeepSeek V4 pour la forme de la requête.
• Puis-ai-je exécuter TradingAgents sur des modèles locaux ?Oui. La v0.2.0 a ajouté la prise en charge multi-fournisseurs ; Ollama, vLLM et LM Studio servent tous des endpoints compatibles OpenAI que le framework consomme. Consultez notre article sur les meilleurs LLM locaux de 2026 pour les choix de modèles.
• Comment simuler les API de données de marché ?Définissez chaque endpoint de fournisseur dans Apidog, activez le serveur de simulation et pointez la configuration des outils du framework vers l'URL de simulation. 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 pour exécuter cela ?Si vous appelez des LLM hébergés (OpenAI, Anthropic, DeepSeek), n'importe quel ordinateur portable avec Python 3.10+ l'exécute. Si vous servez des modèles locaux, le matériel minimal suit le modèle : un GPU de 24 Go exécute DeepSeek V4 Flash ou Qwen 3.6 32B ; un GPU de 8 Go exécute Llama 5.1 8B. La qualité diminue 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é renvoient des données historiques ; le framework peut exécuter n'importe quelle date que vous choisissez. Le trading en direct est un problème différent que le framework ne résout pas explicitement.
• Comment se compare-t-il aux autres frameworks multi-agents ?TradingAgents est spécialisé pour le domaine du trading. CrewAI, AutoGen et LangGraph lui-même sont à usage général. Si vous voulez apprendre le modèle et l'appliquer ailleurs, lisez TradingAgents ; si vous voulez construire un système d'agents générique, commencez par le code LangGraph sous-jacent.