TradingAgents: Framework de Trading Open Source con LLM

La mayoría de los frameworks LLM multiagente prometen más de lo que cumplen. TradingAgents es una excepción poco común: es de código abierto, publicado por Tauric Research junto con un artículo en arXiv, y en la versión 0.2.4 implementa una descomposición de roles clara. El sistema replica una mesa de investigación: analistas de fundamentos, sentimiento, noticias y técnicos alimentan un debate alcista/bajista; después intervienen el Comerciante, el comité de Gestión de Riesgos y una decisión estructurada registrada para auditoría.

Prueba Apidog hoy

Esta guía explica qué hace TradingAgents, qué cambió en la v0.2.4, cómo se compara con LangGraph y CrewAI, y cómo probar sus capas LLM y de datos de mercado con Apidog. Si ya trabajas con contratos de agentes, la guía agents.md para equipos de API encaja bien con este flujo.

TL;DR

• TradingAgents es un framework LLM multiagente para trading, publicado por Tauric Research, descrito en arXiv 2412.20138 y disponible como código abierto.
• Divide el flujo de trading en agentes especializados: Analista Fundamental, Analista de Sentimiento, Analista de Noticias, Analista Técnico, Investigadores Alcistas/Bajistas, Comerciante y Gestión de Riesgos.
• La v0.2.4 añadió salidas estructuradas, reanudación desde checkpoints de LangGraph, registros persistentes de decisiones y soporte para DeepSeek, Qwen, GLM y Azure OpenAI.
• Puede ejecutarse contra endpoints LLM compatibles con OpenAI, incluidos modelos alojados, locales o autoalojados.
• Puedes usar Apidog para simular APIs de datos de mercado, reproducir tráfico de proveedores LLM y comparar coste entre proveedores.
• Descarga Apidog para integrar estas pruebas en CI antes de confiar decisiones automatizadas a datos o modelos externos.

Qué es realmente TradingAgents

TradingAgents es un paquete y CLI de Python que divide un flujo de decisión de trading en roles especializados. Cada rol es un agente LLM con:

• una responsabilidad concreta;
• un conjunto limitado de herramientas;
• una fase definida dentro del grafo de ejecución;
• entradas y salidas que otros agentes consumen.

La orquestación se apoya en LangGraph. El flujo general es:

1. recopilar datos;
2. generar informes por analista;
3. debatir tesis alcistas y bajistas;
4. producir una decisión;
5. revisar riesgos;
6. registrar el resultado.

El README lo presenta como código de investigación, no como asesoramiento financiero. Esa distinción es importante: el objetivo es estudiar cómo la colaboración multiagente cambia los resultados frente a configuraciones de un solo prompt, no lanzar un bot de trading listo para producción.

La parte interesante para ingeniería es la separación de responsabilidades:

• el Analista Fundamental evalúa datos financieros;
• el Analista de Sentimiento revisa señales sociales;
• el Analista de Noticias sigue indicadores y eventos macro;
• el Analista Técnico calcula indicadores como MACD y RSI;
• los Investigadores Alcista y Bajista debaten;
• el Comerciante sintetiza y decide;
• Gestión de Riesgos valida la decisión contra restricciones.

Ese patrón también sirve fuera del trading: especialistas, debate, decisión, verificación y registro.

Qué cambió en la v0.2.4

La versión 0.2.4 es relevante si quieres probar TradingAgents con criterios más cercanos a producción.

1. Agentes con salida estructurada

El Gerente de Investigación, el Comerciante y el Gerente de Cartera ahora emiten salida estructurada usando la API de Respuestas de OpenAI o el canal de uso de herramientas de Anthropic.

Esto reemplaza análisis de texto libre por JSON tipado, lo que facilita:

• validación automática;
• pipelines posteriores;
• trazabilidad;
• pruebas de regresión.

2. Reanudación desde checkpoints de LangGraph

Las ejecuciones largas pueden pausarse y reiniciarse desde un checkpoint guardado.

Esto ayuda cuando:

• una API de datos de mercado devuelve rate limit;
• un proveedor LLM responde con 429;
• una ejecución se corta por red;
• necesitas repetir solo una fase del grafo.

3. Registro persistente de decisiones

Cada decisión del Comerciante se registra en SQLite con:

• razonamiento;
• entradas;
• timestamps;
• resultado final.

Esto crea una pista de auditoría que puedes revisar, comparar o usar como base para evaluación posterior.

4. Soporte multiproveedor

La v0.2.4 añadió DeepSeek, Qwen, GLM y Azure OpenAI a la matriz ya existente de OpenAI, Anthropic, Gemini y Grok.

Si quieres probar razonamiento más barato por token, puedes usar DeepSeek V4 mediante su endpoint compatible con OpenAI. Si necesitas contexto largo o visión, puedes cambiar a Gemini.

5. Docker y correcciones en Windows

La versión también incluye Dockerfile y corrige el problema de codificación UTF-8 en rutas de Windows detectado en la v0.2.3.

Arquitectura del agente paso a paso

Una ejecución completa se ve así:

1. La CLI recibe un ticker y una fecha o rango de fechas.
2. El Equipo de Analistas se activa.
3. Cada analista obtiene datos para el ticker y genera un informe.
4. El Equipo de Investigación recibe los informes.
5. El Investigador Alcista escribe una tesis larga.
6. El Investigador Bajista escribe una tesis corta.
7. Ambos debaten.
8. El Gerente de Investigación sintetiza el debate.
9. El Comerciante consulta la recomendación y el registro histórico.
10. El Comerciante produce un plan.
11. Gestión de Riesgos revisa el plan desde perfiles agresivo, conservador y neutral.
12. El Gerente de Cartera aprueba o devuelve el plan.
13. La decisión final se guarda en SQLite.

Las fases más costosas suelen ser:

• el debate Alcista/Bajista;
• la revisión del equipo de Gestión de Riesgos.

Ahí es donde se nota más la calidad del modelo. Un modelo pequeño puede generar argumentos repetitivos o poco resolutivos. Un modelo de razonamiento tiende a producir una discusión más estructurada.

Por qué probar la capa LLM y la capa de datos

En una ejecución real, suelen fallar dos superficies:

1. APIs de datos de mercado.
2. APIs del proveedor LLM.

Las APIs de datos de mercado pueden cambiar campos, aplicar límites de tasa inconsistentes o devolver datos con formas diferentes según el proveedor. Por ejemplo, una ejecución puede fallar si un campo cambia de regularMarketTime a regular_market_time.

Las APIs LLM fallan de otra manera:

• cambios en formato de respuesta;
• bloques de tool use difíciles de parsear;
• diferencias entre proveedores;
• aumentos de coste por modo de razonamiento;
• respuestas no válidas para agentes con salida estructurada.

Ambas capas necesitan lo mismo: solicitudes canónicas guardadas, reproducibles y con aserciones. Ese es un buen caso de uso para Apidog. El mismo patrón aparece en el playbook de pruebas de servidores MCP.

Simular APIs de datos de mercado con Apidog

Puedes estabilizar tus pruebas de TradingAgents con un mock server.

Paso 1: define los endpoints upstream

En un proyecto de Apidog, crea las solicitudes que TradingAgents usa contra proveedores como:

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

Guarda cada endpoint con ejemplos reales de respuesta. Lo importante es capturar la forma exacta del JSON que consumen los agentes.

Paso 2: activa el mock server

Configura el mock server de Apidog para devolver esas respuestas en las mismas rutas que usa el proveedor real.

Después, apunta la configuración de herramientas de TradingAgents a la URL simulada.

Resultado: el Analista Fundamental, el Analista Técnico y el resto de agentes consumen datos deterministas durante pruebas.

Paso 3: detecta deriva del proveedor

Una vez por semana, reproduce las solicitudes contra el proveedor real y compara la forma de respuesta con tus ejemplos guardados.

Busca cambios como:

• campos renombrados;
• campos eliminados;
• campos agregados;
• tipos modificados;
• arrays vacíos inesperados.

Este flujo sigue el mismo enfoque de desarrollo de API contract-first.

Probar la capa del proveedor LLM

Antes de escalar ejecuciones, valida tres cosas.

1. Coste por rol

Ejecuta un solo ticker y captura el consumo por agente.

Ejemplo de medición útil:

Rol	Tokens entrada	Tokens salida	Coste estimado
Analista Fundamental
Analista Técnico
Investigador Alcista
Investigador Bajista
Comerciante
Gestión de Riesgos

El debate Alcista/Bajista suele ser bastante más caro que los informes individuales. Si no lo es, revisa si el modelo está acortando demasiado la discusión.

Puedes capturar el tráfico en Apidog y comparar ejecuciones por proveedor.

2. Forma de salida

Los agentes de salida estructurada deben devolver JSON válido.

Añade aserciones JSONPath para validar campos mínimos. Por ejemplo:

{
  "decision": "buy",
  "confidence": 0.72,
  "rationale": "...",
  "risk_notes": [...]
}

Aserciones útiles:

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

Una regresión aquí puede pasar desapercibida hasta que falle el código posterior.

3. Paridad entre proveedores

Si cambias de OpenAI a DeepSeek V4 para reducir coste, no esperes decisiones idénticas en cada ejecución. Lo razonable es buscar convergencia estadística.

Un flujo práctico:

1. Selecciona 50 tickers.
2. Ejecuta TradingAgents con OpenAI.
3. Ejecuta los mismos tickers con DeepSeek V4.
4. Compara el registro persistente de decisiones.
5. Mide desviaciones por acción: comprar, mantener, vender.
6. Revisa casos con desacuerdo fuerte.

La guía de DeepSeek V4 cubre la forma de solicitud. La guía de GPT-5.5 cubre el lado de OpenAI.

Ejecución mínima de TradingAgents

Un flujo inicial típico se ve así:

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

Dos rondas de debate suelen ser el mínimo útil para observar la dinámica entre agentes.

La salida se guarda en:

tradingagents/results/

Normalmente incluye JSON y un resumen de decisiones en Markdown.

Para cambiar a DeepSeek V4 Pro en roles con razonamiento intensivo:

export DEEPSEEK_API_KEY="sk-..."

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

El mismo patrón aplica a Qwen, GLM o modelos locales servidos mediante Ollama o vLLM. Para opciones locales, revisa la guía sobre los mejores LLM locales de 2026.

Errores comunes

Usar un modelo demasiado pequeño

Un modelo local de 7B puede producir debates repetitivos o poco concluyentes. Para este tipo de flujo, necesitas calidad de razonamiento suficiente, especialmente en las fases de debate y riesgo.

No cachear datos de mercado

Cada analista puede llamar a la capa de datos por separado. Sin caché, una sola ejecución puede multiplicar solicitudes al proveedor y agotar límites de tasa.

Activa el almacenamiento en caché si el framework lo permite en tu configuración.

Tratarlo como un bot de trading

TradingAgents es código de investigación. El rendimiento depende de:

• modelo;
• prompts;
• duración del debate;
• proveedor de datos;
• calidad de datos históricos;
• configuración de riesgo.

Trata los resultados como hipótesis, no como estrategia lista para operar.

No registrar gasto de tokens

Una ejecución por ticker puede variar mucho en coste según modelo y rondas. Registra consumo por ejecución y alerta sobre anomalías.

Puedes usar el historial de reproducción de Apidog para detectar bucles caros o cambios de formato.

Acoplarte a un solo proveedor

La v0.2.0 añadió soporte multiproveedor. Úsalo.

Ejecuta un lote pequeño en varios proveedores y compara decisiones antes de comprometer una configuración.

Dónde encaja Apidog en el ciclo de desarrollo

Hay tres puntos concretos donde Apidog aporta valor en un proyecto con TradingAgents.

1. Diseño de contratos

Antes de conectar proveedores en vivo, documenta cada endpoint de datos de mercado como una solicitud con respuesta de ejemplo.

Esto te obliga a definir:

• qué campos consume cada agente;
• qué tipos espera;
• qué valores son opcionales;
• qué errores debe manejar el sistema.

2. CI local

Durante pruebas unitarias, reemplaza proveedores reales por el mock server de Apidog.

Ventajas:

• pruebas más rápidas;
• sin dependencia de horarios de mercado;
• sin rate limits;
• sin costes de proveedor;
• datos deterministas.

Este enfoque también se describe en Pruebas de API sin Postman.

3. Detección de regresiones

Cada semana, reproduce endpoints reales contra tus contratos guardados.

Si cambia la forma de una respuesta, Apidog puede ayudarte a detectar la deriva antes de que los agentes empiecen a razonar sobre datos rotos.

Por qué importa más allá del trading

TradingAgents es un ejemplo claro de descomposición agéntica. El patrón se puede adaptar a otros dominios:

• triage de soporte: agentes por tipo de ticket, debate y decisión;
• revisión de código: seguridad, rendimiento, estilo y sintetizador;
• cumplimiento: analistas de datos, revisores de riesgo y comité de decisión;
• investigación: lectores especialistas, debate y síntesis.

La idea reutilizable es:

1. dividir el problema en roles;
2. limitar herramientas por rol;
3. permitir debate controlado;
4. producir salida estructurada;
5. registrar cada decisión.

También es un patrón comprobable, lo que hace natural combinarlo con Apidog.

Casos de uso reales

Un estudiante de investigación cuantitativa puede usar TradingAgents para comparar DeepSeek V4, GPT-5.5 y Claude 4.5 sobre una misma cesta de 30 tickers. Apidog captura cada solicitud y respuesta para que la comparación sea reproducible.

Un ingeniero fintech puede reutilizar el patrón multiagente, no necesariamente el código de trading, para revisar servicios internos. Agentes especializados revisan seguridad, rendimiento y nomenclatura; un sintetizador genera el comentario de PR.

Un desarrollador individual puede ejecutar TradingAgents cada noche sobre una watchlist y guardar decisiones en Postgres. Durante pruebas de fin de semana, el mock server de Apidog reemplaza las APIs de datos de mercado.

Conclusión

TradingAgents es un ejemplo funcional de cómo construir un sistema LLM multiagente que produce decisiones estructuradas en lugar de conversaciones sueltas. La v0.2.4 refuerza ese enfoque con salidas estructuradas, checkpoints, auditoría y soporte multiproveedor.

Pero el sistema solo es útil si puedes probar sus dependencias: datos de mercado y proveedores LLM. Ahí es donde Apidog encaja bien.

Cinco conclusiones prácticas:

• TradingAgents separa el trading en agentes con roles claros.
• La v0.2.4 añade salidas estructuradas, checkpoints de LangGraph y nuevos proveedores.
• Simula datos de mercado en Apidog para obtener pruebas deterministas.
• Valida paridad entre proveedores LLM antes de cambiar modelos.
• El patrón de especialistas, debate, decisión y registro se puede reutilizar fuera del trading.

Siguiente paso: clona el repositorio, ejecuta un ticker con tu LLM preferido y redirige las llamadas upstream a través de un mock server de Apidog. En una hora sabrás si el framework encaja con tu flujo de trabajo.

Preguntas frecuentes

¿Es seguro usar TradingAgents con dinero real?

El repositorio indica que es código de investigación y no asesoramiento financiero. Cualquier uso con una correduría real implica riesgo propio.

¿Qué proveedor LLM ofrece mejor relación coste-calidad?

Depende del workload, pero para muchas pruebas de razonamiento DeepSeek V4 Flash con modo de pensamiento puede ser competitivo en coste. Consulta la guía de la API de DeepSeek V4 para la forma de solicitud.

¿Puedo ejecutar TradingAgents con modelos locales?

Sí. El soporte multiproveedor permite usar endpoints compatibles con OpenAI, incluidos Ollama, vLLM y LM Studio. Revisa la guía sobre LLM locales de 2026.

¿Cómo simulo APIs de datos de mercado?

Define cada endpoint en Apidog, activa el mock server y configura TradingAgents para usar esa URL. El mismo patrón aparece en la guía de herramientas de prueba de API para ingenieros QA.

¿Cuál es el hardware mínimo?

Si usas LLM alojados, basta una laptop con Python 3.10+. Si sirves modelos locales, el hardware depende del modelo y del runtime que uses.

¿Funciona fuera del horario de mercado?

Puede ejecutarse con datos históricos para la fecha que elijas. El trading en vivo es un problema diferente y el framework no lo resuelve explícitamente.

¿Cómo se compara con otros frameworks multiagente?

TradingAgents está especializado en trading. CrewAI, AutoGen y LangGraph son más generales. Si quieres estudiar un patrón multiagente aplicado a un dominio concreto, TradingAgents es una buena referencia. Si quieres construir un sistema genérico, probablemente empieces directamente con LangGraph o un framework de propósito general.