TradingAgents: Framework Open Source de LLM para Negociação

A maioria dos frameworks LLM multi-agente promete mais do que entrega. TradingAgents é uma das raras exceções: de código aberto pela Tauric Research juntamente com um artigo do arXiv, agora na versão 0.2.4, e entregando o tipo de decomposição de funções limpa que outros frameworks descrevem, mas raramente implementam. O sistema espelha uma mesa de pesquisa real: analistas de fundamentos, sentimento, notícias e técnicos alimentando um debate de pesquisa Bull/Bear, depois um Trader, depois um comitê de Gerenciamento de Risco, terminando em uma decisão estruturada registrada para auditoria.

Esta revisão detalha o que o TradingAgents realmente faz, o que foi lançado na v0.2.4, como ele se compara ao LangGraph e CrewAI, e como testar as camadas de LLM e dados de mercado subjacentes com Apidog. Se você já se aprofundou na camada de contrato de agente, nosso guia agents.md para equipes de API combina naturalmente com esta publicação.

TL;DR

• TradingAgents é um framework de negociação LLM multi-agente da Tauric Research, arXiv 2412.20138, de código aberto em 2025 e agora na versão 0.2.4.
• Ele divide a negociação em agentes especialistas: Analista de Fundamentos, Analista de Sentimento, Analista de Notícias, Analista Técnico, Pesquisadores Bull/Bear, Trader e um comitê de Gerenciamento de Risco.
• A v0.2.4 adicionou agentes de saída estruturada, retomada de checkpoint LangGraph, logs de decisão persistentes e suporte a provedores como DeepSeek, Qwen, GLM e Azure OpenAI.
• O framework funciona em qualquer endpoint LLM compatível com OpenAI, o que torna os modelos hospedados, locais e auto-hospedados intercambiáveis.
• Use Apidog para simular as APIs de dados de mercado subjacentes, reproduzir o tráfego do provedor LLM e comparar o custo do modo de pensamento entre DeepSeek, OpenAI e Anthropic.
• Baixe o Apidog para integrar tudo isso ao seu CI antes de confiar em um agente com dinheiro real.

O que TradingAgents realmente é

O framework é um pacote Python e CLI que decompõe o fluxo de trabalho de negociação em funções especializadas. Cada função é um agente LLM solicitado com uma descrição de trabalho, com acesso a um conjunto de ferramentas focado e orquestrado pelo LangGraph. As decisões fluem por estágios: coletar dados, debater, decidir, registrar.

O README o descreve como código de pesquisa, não como conselho de investimento. Essa abordagem é importante. O objetivo é estudar como a colaboração multi-agente altera os resultados em comparação com configurações de prompt único, e não lançar um bot de negociação de produção a partir do seu laptop.

O que é interessante do ponto de vista da engenharia é a clareza da separação de funções. O Analista de Fundamentos avalia as finanças da empresa. O Analista de Sentimento pontua as mídias sociais. O Analista de Notícias monitora os indicadores macroeconômicos. O Analista Técnico calcula MACD e RSI. Os Pesquisadores Bull e Bear debatem. O Trader lê os relatórios de todos e decide. O Gerenciamento de Risco verifica a decisão em relação às restrições. Cada agente tem uma única tarefa e um único conjunto de ferramentas.

Este é o mesmo padrão que você projetaria para qualquer fluxo de trabalho agente complexo: funções especialistas, uma fase de debate, uma fase de decisão e uma etapa de verificação. TradingAgents é uma implementação de referência funcional que você pode ler em uma tarde.

O que a v0.2.4 entregou

O lançamento de abril de 2026 é significativo para usuários curiosos sobre produção.

• Agentes de saída estruturada. O Gerente de Pesquisa, o Trader e o Gerente de Portfólio agora emitem saída estruturada através da API de Respostas da OpenAI ou do canal de uso de ferramentas da Anthropic. Isso substitui a antiga análise de texto livre por JSON tipado, o que torna a automação subsequente confiável.
• Retomada de checkpoint LangGraph. Execuções de longa duração podem pausar e reiniciar a partir de um checkpoint salvo. Se uma API de dados de mercado for limitada ou um provedor LLM retornar 429, a execução não começa do zero.
• Log de decisão persistente. Cada decisão que o Trader toma é registrada em um log SQLite com raciocínio, entradas e carimbos de data/hora. Você obtém um rastro de auditoria que pode revisar ou alimentar de volta para avaliação.
• Suporte a múltiplos provedores. A v0.2.4 adicionou DeepSeek, Qwen, GLM e Azure OpenAI à matriz existente de OpenAI, Anthropic, Gemini e Grok. Se você busca o raciocínio mais barato por token, pode mudar para o DeepSeek V4 através de seu endpoint compatível com OpenAI. Se precisar de contexto longo ou visão, mude para o Gemini.
• Suporte Docker e correção UTF-8 do Windows. Entediante, mas importante: o framework agora inclui um Dockerfile, e o bug de codificação de caminho do Windows da v0.2.3 foi corrigido.

A arquitetura do agente em detalhes

Uma execução completa do TradingAgents se parece com isto.

1. A CLI aceita um símbolo de ticker e um intervalo de datas.
2. A Equipe de Analistas se expande: cada um dos quatro analistas busca dados de forma independente para o ticker e escreve um relatório.
3. A Equipe de Pesquisa recebe os quatro relatórios. O Pesquisador Bull escreve uma tese de alta. O Pesquisador Bear escreve uma tese de baixa. Eles debatem.
4. O Gerente de Pesquisa sintetiza o debate em uma recomendação.
5. O Trader pega a recomendação, verifica o log de decisão persistente e produz um plano de negociação.
6. A equipe de Gerenciamento de Risco revisa. Três agentes de risco (Agressivo, Conservador, Neutro) contestam o plano de diferentes ângulos.
7. O Gerente de Portfólio aprova ou envia o plano de volta para revisão.
8. A decisão final é registrada no log SQLite.

A maior parte do custo do LLM está nas etapas 3 e 6, onde múltiplos agentes debatem. É também onde modelos pequenos são expostos: um modelo de 7B executando o debate Bull/Bear produz argumentos ruidosos e repetitivos. Um modelo de raciocínio (modo de pensamento DeepSeek V4, GPT-5.5, Claude 4.5) produz um diálogo estruturado que se assemelha a uma reunião de pesquisa real.

Por que testar a camada LLM com uma ferramenta de API

Ao executar o TradingAgents, duas superfícies falham em produção: as APIs de dados de mercado (Yahoo Finance, FinnHub, Polygon, OpenBB) e as APIs do provedor LLM.

O lado dos dados de mercado é sujo. Camadas gratuitas têm limites de taxa inconsistentes, campos não documentados aparecem e desaparecem, e os limites dos dias de negociação diferem entre os fornecedores. Uma execução que funcionou na terça-feira quebra silenciosamente na quarta-feira porque um fornecedor renomeou regularMarketTime para regular_market_time.

O lado do LLM também é sujo, de uma maneira diferente. O modo de pensamento DeepSeek V4 dobra seu custo; a API de Respostas da OpenAI tem suas próprias peculiaridades; o uso de ferramentas da Anthropic retorna blocos de conteúdo que alguns parsers a jusante engasgam.

Ambas as superfícies querem a mesma coisa de você: uma coleção de requisições canônicas salvas e reproduzíveis com asserções. É exatamente para isso que o Apidog serve. Cobrimos o mesmo padrão de teste no nível de protocolo em nosso manual de teste de servidor MCP.

Simulando as APIs de dados de mercado no Apidog

Três passos para remover a instabilidade dos fornecedores das suas execuções de teste do TradingAgents.

1. Passo 1: defina os endpoints upstream. Em um projeto Apidog, adicione os endpoints Yahoo Finance, FinnHub, Polygon ou OpenBB que o TradingAgents chama. O README para cada especificação de ferramenta lista as URLs exatas. Salve cada um como uma requisição com corpos de resposta de exemplo extraídos de respostas reais.
2. Passo 2: ligue o servidor mock. O servidor mock do Apidog retorna as respostas de exemplo nos mesmos caminhos de URL que o fornecedor real usa. Aponte a configuração de ferramenta do TradingAgents para a URL mock. O Analista de Fundamentos agora é executado contra dados determinísticos; seus testes não estão mais à mercê do limite de taxa do Yahoo.
3. Passo 3: capture o desvio do fornecedor. Uma vez por semana, reproduza os endpoints ativos e compare o formato da resposta com suas 'fixtures' salvas. O Apidog destaca quaisquer campos adicionados, removidos ou renomeados. É assim que você detecta a renomeação de regularMarketTime antes que ela mate uma execução.

Usamos o padrão exato no desenvolvimento de API 'contract-first', que descreve o fluxo de trabalho mais amplo.

Testando a camada do provedor LLM

A camada do provedor precisa de três coisas testadas antes de você escalar as execuções.

• Custo por função. Execute um único ticker através dos quatro analistas e do debate. Capture a contagem de tokens por agente no log de requisições do Apidog. O debate Bull/Bear geralmente é 3-5x mais caro que os analistas; se não, o modelo está "short-circuitando".
• Formato de saída. Os agentes de saída estruturada da v0.2.4 (Gerente de Pesquisa, Trader, Gerente de Portfólio) devem sempre retornar JSON bem-formado. Adicione asserções JSONPath no Apidog para verificar. Uma regressão aqui é silenciosa e devastadora; você só descobrirá quando o código downstream falhar.
• Paridade do provedor. Ao alternar da OpenAI para o DeepSeek V4 para testar o custo, as decisões do Trader devem diferir em execuções individuais, mas convergir para conclusões semelhantes em várias execuções. Execute 50 tickers em ambos os provedores, compare o log de decisão persistente e quantifique o desvio. Nosso guia da API DeepSeek V4 abrange o formato da requisição; nosso guia da API GPT-5.5 abrange o lado OpenAI. A diferença de resposta do Apidog torna a comparação visual.

Uma execução mínima do TradingAgents

O início rápido do README se parece aproximadamente com isto.

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

Duas rodadas de debate é a menor execução significativa. A saída é gravada em tradingagents/results/ como JSON, além de um resumo de decisão em markdown.

Para alternar para DeepSeek V4 Pro para as funções que exigem raciocínio, defina o flag --models e aponte o cliente OpenAI para a URL base do DeepSeek através da configuração do provedor do framework:

export DEEPSEEK_API_KEY="sk-..."

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

O mesmo padrão funciona para Qwen 3.6, GLM 5 ou qualquer modelo local servido por Ollama ou vLLM. Nossa publicação sobre os melhores LLMs locais de 2026 aborda o lado do serviço local.

Armadilhas comuns

Estas aparecem no thread de issues do GitHub.

• Execução com um modelo pequeno. Um modelo local de 7B produz um debate Bull/Bear que entra em loop sem resolução. O framework precisa de qualidade de raciocínio de nível intermediário, no mínimo. DeepSeek V4 Flash, Qwen 3.6 32B, GPT-5.5 e Claude 4.5 são o piso realista.
• Ignorar o cache de dados de mercado. Cada analista chama a camada de dados separadamente. Sem cache, você dispara de 4 a 8 requisições de fornecedores por execução e queima rapidamente o orçamento de limite de taxa. O framework suporta cache; ative-o.
• Tratá-lo como um bot de negociação. É código de pesquisa. O desempenho do backtest é sensível à escolha do modelo, à semente do prompt, à duração do debate e à qualidade dos dados. Trate qualquer número que ele produza como uma hipótese, não como uma estratégia.
• Esquecer de registrar o gasto de tokens. Uma única execução de ticker pode custar de $0.10 a $5, dependendo do modelo e das rodadas. Registre o custo por execução no histórico de replay do Apidog; um loop descontrolado na fase de debate pode acumular dinheiro real em minutos.
• Codificar um provedor. A v0.2.0 adicionou suporte a múltiplos provedores precisamente para que você possa alternar. Use-o. Execute um pequeno lote através de três provedores e compare o log de decisão antes de se comprometer.

Onde o Apidog se encaixa no ciclo de desenvolvimento

Três lugares concretos onde o Apidog se faz valer em um projeto TradingAgents.

• O primeiro é a superfície de design. Antes de conectar o framework a fornecedores reais, esboce cada endpoint de dados de mercado no Apidog como uma requisição com corpos de exemplo. A visualização do esquema força você a ser honesto sobre quais campos o framework realmente usa. Muitas equipes descobrem que estavam pagando por um plano Polygon que mal consumiam.
• O segundo é o CI local. O servidor mock do Apidog substitui cada fornecedor enquanto os testes de unidade são executados, para que o conjunto de testes permaneça abaixo de cinco segundos e pare de depender do horário de funcionamento do mercado nos fins de semana. Cobrimos esse padrão exato em testes de API sem Postman.
• O terceiro é a diferenciação de regressão. A cada execução semanal, reproduza os endpoints ativos contra suas 'fixtures' salvas. O Apidog destaca renomeações de campos e desvios de formato. Este é o alarme mais barato possível para “a camada de dados quebrou e os agentes começaram a alucinar números”

Por que isso importa além da negociação

TradingAgents é o exemplo de código aberto mais claro de decomposição agêntica que temos atualmente. O padrão se transfere diretamente para:

• Triagem de suporte ao cliente (agentes analistas por tipo de ticket, debate, decisão)
• Revisão de código (agentes de segurança, desempenho, estilo, então um sintetizador)
• Revisão de conformidade (analistas de dados, revisores de risco, comitê de decisão)
• Resumo de pesquisa (múltiplos leitores especialistas, debate, síntese)

Se você está projetando qualquer fluxo de trabalho de agente multi-etapas, leia o código do TradingAgents primeiro. A separação de funções, o estágio de debate, as decisões de saída estruturada e o log persistente são padrões reutilizáveis. São também padrões testáveis, o que é o ponto de emparelhar o framework com o Apidog.

Casos de uso no mundo real

• Um estudante de pesquisa quantitativa usa o TradingAgents para comparar DeepSeek V4 vs GPT-5.5 vs Claude 4.5 na mesma cesta de 30 tickers. O Apidog captura cada requisição e resposta para que a comparação seja reproduzível.
• Um engenheiro de fintech usa o padrão multi-agente (não o código de negociação) para executar revisões de código em serviços internos. Agentes especialistas verificam segurança, desempenho, nomenclatura. Um sintetizador escreve o comentário do PR. Custo total da revisão por PR: cerca de US$ 0,04.
• Um desenvolvedor solo executando o TradingAgents todas as noites em uma lista de 10 tickers registra cada decisão no Postgres para posterior inspeção. O servidor mock do Apidog substitui os fornecedores de dados de mercado ativos durante as execuções de teste de fim de semana.

Conclusão

TradingAgents é um exemplo funcional e bem arquitetado de como construir um sistema LLM multi-agente que produz decisões estruturadas em vez de chat. A v0.2.4 o torna "production-curious": saídas estruturadas, retomada de checkpoint, trilha de auditoria, múltiplos provedores. Nada disso importa se você não consegue testar as camadas de LLM e dados de mercado subjacentes. É aí que a combinação com o Apidog se justifica.

Cinco pontos chave:

• TradingAgents decompõe a negociação em agentes especialistas com funções claras e uma fase de debate.
• A v0.2.4 adiciona saídas estruturadas, checkpoints do LangGraph e provedores DeepSeek/Qwen/GLM/Azure.
• Simule os fornecedores de dados de mercado no Apidog para que as execuções de teste sejam determinísticas.
• Teste a paridade do provedor LLM antes de trocar modelos em produção.
• O padrão (especialistas, debate, decisão, log) se transfere para todos os fluxos de trabalho de agentes não relacionados a negociação que você construir.

Próximo passo: clone o repositório, execute um único ticker contra o seu LLM preferido e direcione as chamadas upstream através de um servidor mock do Apidog. Você saberá em uma hora se o framework se encaixa no seu fluxo de trabalho.

Perguntas Frequentes

• É seguro usar o TradingAgents com dinheiro real?

O repositório é explícito ao afirmar que é código de pesquisa e não conselho financeiro. Trate sua saída como uma hipótese. Qualquer pessoa que o utilize em uma corretora ativa assume o risco pessoalmente; os mantenedores não endossam isso.

• Qual provedor LLM oferece o melhor equilíbrio entre custo e qualidade?

Para a maioria das cargas de trabalho no início de 2026, o DeepSeek V4 Flash com modo de pensamento supera o GPT-5.5 em custo por uma ampla margem e o iguala em qualidade no debate Bull/Bear. Consulte nosso guia da API DeepSeek V4 para o formato da requisição.

• Posso executar o TradingAgents em modelos locais?

Sim. A v0.2.0 adicionou suporte a múltiplos provedores; Ollama, vLLM e LM Studio todos servem endpoints compatíveis com OpenAI que o framework consome. Consulte nossa publicação sobre os melhores LLMs locais de 2026 para sugestões de modelos.

• Como faço para simular as APIs de dados de mercado?

Defina cada endpoint do fornecedor no Apidog, ligue o servidor mock e aponte a configuração da ferramenta do framework para a URL mock. O mesmo padrão está documentado em ferramentas de teste de API para engenheiros de QA.

• Qual é o hardware mínimo para executá-lo?

Se você estiver chamando LLMs hospedados (OpenAI, Anthropic, DeepSeek), qualquer laptop com Python 3.10+ o executa. Se você serve modelos locais, o hardware mínimo acompanha o modelo: uma GPU de 24 GB executa DeepSeek V4 Flash ou Qwen 3.6 32B; uma GPU de 8 GB executa Llama 5.1 8B. A qualidade diminui com modelos menores.

• Ele suporta simulação após o horário de negociação e nos fins de semana?

Os fornecedores de dados de mercado retornam dados históricos; o framework pode executar qualquer data que você escolher. A negociação ao vivo é um problema diferente que o framework explicitamente não resolve.

• Como ele se compara a outros frameworks multi-agente?

TradingAgents é específico para o domínio de negociação. CrewAI, AutoGen e o próprio LangGraph são de propósito geral. Se você quiser aprender o padrão e aplicá-lo em outro lugar, leia TradingAgents; se você quiser construir um sistema de agente genérico, comece com o código subjacente do LangGraph.