Como a IA decide quando comprar ou vender? Por dentro de um agente de trading com ChatGPT ou Claude

O modelo propõe uma ação; a aplicação determina o que ele pode fazer

Um bot de trading com ChatGPT ou Claude é um sistema montado em torno de um modelo. A aplicação escolhe sua tarefa, observações, instruções e ferramentas disponíveis. O modelo usa esse contexto para produzir uma resposta, uma proposta estruturada ou uma solicitação de ferramenta. A aplicação decide quais solicitações são admissíveis, quanto capital podem comprometer e como registrar a execução. O nome de um produto não especifica essas regras.

Não existe uma receita universal de indicadores nessa interface. Uma aplicação pode pedir a interpretação de um relatório de resultados; outra pode fornecer variáveis de momentum e solicitar BUY, SELL ou HOLD. Uma terceira pode usar uma estratégia numérica convencional enquanto a IA apenas ajuda a escrever seu código. Para entender uma decisão, identifique o papel do modelo e examine a informação que ele realmente recebeu.

OpenAI e Anthropic documentam fluxos de ferramentas do cliente nos quais o modelo solicita uma função com nome e argumentos, e a aplicação despacha sua implementação. Essa solicitação é uma mensagem intermediária. Uma ferramenta de dados precisa fornecer as observações relevantes; um adaptador de corretora e autorização da conta precisam existir antes que uma solicitação admitida se torne uma ordem real. Produtos de chat para consumidores e aplicações de modelos para desenvolvedores têm integrações e permissões diferentes. [1] [2]

Nosso guia anterior de agentes de trading com IA explica a arquitetura. Esta investigação acompanha a fronteira de controle: uma proposta construída é avaliada, dimensionada, reservada, parcialmente executada e conciliada. Também mostra como a mesma ação proposta muda quando a informação ou o estado da conta falha em uma verificação.

Comece por uma decisão completa, examinada passo a passo

Considere 16 casos de controle deliberadamente construídos em torno do mesmo mandato de negociação. A proposta BUY básica é admitida para 20.86 unidades. Sua perda modelada no stop é de US$ 49.98061318 diante de um orçamento planejado de US$ 50. Um gap de preço imposto posteriormente produz uma perda simulada de US$ 60.38976622. A admissão correta não cria uma operação lucrativa nem garante que a perda fique dentro do orçamento.

Instrumento, preços, evidências, propostas e resultado posterior são construídos. Nenhuma API de modelo foi chamada, e nenhuma proposta é atribuída a ChatGPT ou Claude. O propósito é examinar os mecanismos da decisão ao registro contábil sem inventar saídas de modelos, tempos de API ou histórico de trading.

O artigo apresenta o pacote de decisão, a proposta, as fórmulas de dimensionamento, os 16 resultados e as transições de caixa e posição. A conta do exemplo termina com US$ 9,939.61023378 e quantidade de ativo zero. Dezesseis casos construídos não são dezesseis observações de mercado nem uma estimativa de precisão do modelo.

Congele o que pode ser conhecido antes de pedir uma decisão

O pacote construído usa o instrumento artificial TP-USD. Às 12:00:00 UTC de 22 de outubro de 2026, a conta tem US$ 10,000 em caixa, nenhuma posição e nenhuma ordem pendente. O ponto médio de referência da cotação é 100, com compra a 99.95 e venda a 100.05. Um registro de variável já concluído contém um retorno construído de três barras de +1%. A variável fornece uma premissa ilustrativa para a solicitação BUY; não tem valor preditivo demonstrado.

O pacote de decisão registra IDs de origem, horários de observação, horários de disponibilidade e versão da conta. Um registro pode descrever um evento anterior e só ficar disponível depois. O controlador verifica os dois horários contra seu próprio recebimento e o limite temporal da proposta. Um assistente não torna um registro futuro utilizável atribuindo-lhe um as_of anterior.

O resultado posterior de 97.50 pertence apenas ao simulador. Ele é excluído do pacote do proponente e dos parâmetros de política do controlador. A admissão e o tamanho anteriores dependem da informação disponível na entrada; o resultado subsequente determina o P&L posterior. Essa separação trata de uma fronteira de informação da aplicação. Não estabelece o que um modelo pré-treinado talvez já saiba sobre eventos históricos reconhecíveis.

O estado atual da conta importa tanto quanto preços atuais. O pacote vincula o snapshot de mercado a account-v001, e os horários de observação e disponibilidade da conta são verificados separadamente. Uma cotação correta não demonstra que um saldo em cache ainda reflita outra ordem. Uma implementação em produção precisa de conciliação com a fonte oficial e reserva coordenada no momento da admissão.

Peça uma proposta limitada e deixe as quantidades sob controle do código

O exemplo abaixo é uma proposta construída, não uma conversa com qualquer provedor. Ele solicita BUY para um snapshot identificado, cita dois IDs de registro e propõe um stop de referência de 98. Não pode fornecer a quantidade da ordem, mudar a conta, selecionar um destino arbitrário de execução ou aumentar o orçamento de risco. Essas autoridades permanecem com a aplicação.

{
  "proposal_id": "proposal-001",
  "action": "BUY",
  "instrument": "TP-USD",
  "snapshot_id": "tp-snapshot-001",
  "as_of": "2026-10-22T12:00:00Z",
  "valid_until": "2026-10-22T12:00:30Z",
  "evidence_ids": [
    "quote-Q001",
    "feature-F001"
  ],
  "observed_reference_price": 100,
  "stop_reference_price": 98,
  "rationale": "Constructed example only: the positive feature motivates a hypothetical BUY request; no forecasting evidence is supplied.",
  "confidence_label": "MEDIUM"
}

Uma saída estruturada ou interface estrita de ferramenta facilita a imposição de campos e valores permitidos. Não demonstra que uma interpretação econômica esteja correta. As APIs também têm resultados excepcionais, como recusas, respostas incompletas e erros de ferramenta; a aplicação precisa examinar o estado de conclusão e validar o que recebe. A validação de formato e as verificações financeiras abaixo respondem a perguntas diferentes. [3] [4]

O controlador compara o preço observado estruturado com a cotação oficial e os IDs citados com os registros disponíveis. Não determina se a justificativa em texto livre decorre desses registros. A diferença aparece no caso em que só a apresentação muda: a justificativa afirma falsamente que o preço é 120, enquanto o preço estruturado continua em 100. O tamanho admitido não muda, e a frase sem apoio continua sem apoio.

Acompanhe o cálculo da proposta BUY admitida

O controlador permite uma intenção ativa ou posição, orçamento de perda planejada de 0.5% do patrimônio a mercado e nocional ao ponto médio de referência de no máximo 25% do patrimônio. O incremento de quantidade é 0.01 e o mínimo presumido de ordem, antes das taxas, é US$ 10. São escolhas de política divulgadas para o exercício, não limites recomendados ou especificações atuais de uma plataforma.

A convenção de entrada executa na oferta de venda × 1.0005 e cobra 0.1% do valor executado em USD. Para o planejamento, o stop referenciado ao ponto médio 98 é convertido em uma compra modelada usando meio spread de 0.05%; depois recebe outro ajuste adverso de 0.05% e a mesma taxa. A perda planejada exata por unidade é o caixa pago na entrada menos o recebimento líquido modelado no stop.

O preço executado na entrada é 100.100025; o caixa por unidade, incluindo comissão, é 100.200125025. O preço modelado no stop é 97.90202450, e o recebimento líquido modelado é 97.80412247550. A diferença é 2.39600254950 por unidade. Um orçamento de US$ 50 permite aproximadamente 20.86809132 unidades antes do arredondamento. O limite nocional de 25% permite 25 unidades, e o caixa disponível permite mais. O limite de risco é o vinculante, portanto a quantidade admitida é 20.86.

entry_cash_per_unit = ask × (1 + adverse_fraction) × (1 + fee_fraction)
modeled_stop_net_per_unit = stop_mid × (1 - half_spread_fraction) × (1 - adverse_fraction) × (1 - fee_fraction)
planned_loss_per_unit = entry_cash_per_unit - modeled_stop_net_per_unit
risk_quantity = marked_equity × risk_budget_fraction / planned_loss_per_unit
cap_quantity = marked_equity × reference_notional_cap_fraction / reference_mid
cash_quantity = authorized_available_cash / entry_cash_per_unit
quantity = floor(min(risk_quantity, cap_quantity, cash_quantity) / quantity_increment) × quantity_increment

Nessa quantidade, o nocional ao ponto médio é US$ 2,086.00, a perda planejada no stop é US$ 49.98061318 e o caixa reservado para entrar é US$ 2,090.17460802. Nocional de referência e compromisso de caixa diferem porque execução e comissão de entrada estão no segundo. O rótulo de confiança HIGH não aparece em nenhum ponto do cálculo de tamanho.

A mesma proposta BUY pode virar uma ordem menor, uma operação ignorada ou um bloqueio

A tabela considera os 16 casos construídos. A maioria altera uma condição conceitual do BUY básico. O SELL com posição existente é um controle positivo identificado separadamente, e os dois reenvios de ID declaram seu estado anterior de intenção. Cada caso começa nas condições de conta declaradas. Eles não devem ser somados como operações de uma única carteira.

Os controles positivos importam: rejeitar tudo também rejeitaria os casos admissíveis de BUY, SELL com posição e limite mais restrito. HOLD, SELL sem posição, operação ignorada por valor insuficiente, bloqueio por estado desconhecido e supressão de duplicata têm significados diferentes. Não devem ser todos rebatizados como uma escolha da IA de esperar.

O limite de 5% admite 5.00 unidades. No caso com gasto de caixa autorizado de US$ 5, o patrimônio a mercado continua em US$ 10,000, mas a quantidade candidata cai para 0.04 e falha no mínimo. A operação é ignorada, não arredondada para cima. O caso UNKNOWN bloqueia uma substituição até a conciliação do estado; não presume que a ordem anterior tenha falhado.

São exemplos controlados de comportamento da aplicação, com a condição alterada e o encaminhamento resultante apresentados juntos. Não fornecem taxa de erro do modelo, acerto de mercado, sucesso de ataque ou confiabilidade em produção. A pergunta útil é qual regra explica cada solicitação admitida, reduzida, ignorada ou bloqueada.

Uma reserva, uma ordem e uma execução alteram registros diferentes

A admissão cria intent-proposal-001 e reserva US$ 2,090.17460802. O caixa ainda é US$ 10,000 nesse momento; a reserva limita o que pode ser comprometido em outro lugar. A execução simulada informa 12.00 unidades às 12:00:01 UTC e as 8.86 restantes às 12:00:02. A oferta de venda artificial é mantida constante nas duas execuções. São casos de execução com preço estável imposto, não cotações de mercado observadas posteriormente.

Após a primeira execução, o caixa é US$ 8,797.59849970, a posição é de 12.00 unidades e US$ 887.77310772 continuam reservados. O patrimônio marcado ao ponto médio 100 é US$ 9,997.59849970. Deduzir a reserva novamente subestimaria o patrimônio: ela é um compromisso interno sobre o caixa, não uma perda econômica adicional. Caixa disponível e patrimônio da conta respondem a perguntas diferentes.

Reprocessar o ID idêntico da primeira execução deixa a conta inalterada. Uma proposta nova, com versão atualizada da conta, continua bloqueada enquanto a primeira intenção está parcialmente executada. Após a segunda execução, a conta detém 20.86 unidades e US$ 7,909.82539198 em caixa. A reserva restante passa a zero. O histórico verifica a ingestão interna de execuções e os compromissos em uma máquina de estados simulada de processo único.

A impressão digital da intenção usa campos estruturados e normalização decimal exata; o texto de apresentação não tem autoridade. Uma solicitação estruturada idêntica com o mesmo ID não cria outra intenção interna, enquanto uma solicitação alterada sob esse ID gera conflito. Isso não garante execução exatamente uma vez em uma corretora externa. A recuperação real precisa consultar ordens e execuções, persistir o estado conciliado e lidar com relatórios alterados, cancelamentos parciais e incerteza de rede.

A operação admitida perde mais que seu orçamento planejado

Às 12:05:00 UTC, o simulador recebe o ponto médio congelado separadamente em 97.50, abaixo do stop de referência armazenado em 98. O mecanismo independente de stop cria paper-stop-exit-001 para a posição inteira. A execução de saída é 97.50 × 0.9995 × 0.9995 = 97.402524375, com outra comissão de 0.1%. A saída é acionada pela regra armazenada no simulador; não é uma nova previsão do modelo.

Aos pontos médios de referência, o movimento perde 20.86 × (97.50 − 100) = US$ 52.15. Compra/venda e execução adversa acrescentam US$ 4.11986304 de desvio de execução. As comissões de entrada e saída somam US$ 4.11990318. A perda líquida é US$ 60.38976622, ou 0.60389766% do patrimônio inicial, deixando US$ 9,939.61023378 e nenhuma posição no ativo. Cada custo é deduzido uma vez.

A perda planejada no stop, US$ 49.98061318, usava uma saída presumida sem gap perto do ponto médio 98. O gap imposto invalida essa hipótese de execução. Passar na verificação de risco, portanto, não limita a perda realizada a US$ 50. A resposta relevante é examinar a hipótese de planejamento e a exposição a gaps, preservando o registro original da decisão.

Os saldos de caixa, posição e custos conciliam: o patrimônio inicial mais o P&L líquido equivale ao caixa final da conta sem posição. O caixa sem negociação rende zero neste exercício sem juros. Uma trajetória imposta não estabelece um ranking de investimento, retorno esperado ou probabilidade de perda futura.

Uma razão declarada ajuda na inspeção, mas não é prova causal

O caso que altera apenas a apresentação responde precisamente a uma pergunta: linguagem mais enfática não aumenta o tamanho neste controlador. Também expõe um limite. O programa aceita o BUY estruturado e deixa sem verificação a afirmação falsa de preço no texto. IDs de evidência correspondentes estabelecem consistência de referência; não provam que a justificativa seja verdadeira, que o registro citado implique a conclusão ou que a operação tenha vantagem.

Chen e colegas testaram se o raciocínio gerado por modelos revelava dicas influentes em questões controladas de múltipla escolha. Dicas que influenciaram respostas nem sempre foram reconhecidas. O resultado recomenda cautela ao tratar uma explicação como auditoria causal completa; não mede este sistema de trading nem prova que toda explicação seja falsa. Preserve o pacote real, chamadas de ferramentas, saídas e resultados do controlador junto a uma justificativa concisa. [5]

Um rótulo HIGH, a verossimilhança de um token de resposta e uma probabilidade empiricamente calibrada de ganho após custos são grandezas diferentes. Kadavath e colegas estudaram autoavaliação dependente da tarefa e da forma de solicitação em modelos anteriores. Seus resultados não transformam um campo de confiança em uma probabilidade validada. Alegar calibração financeira exige instrumento, horizonte, regra de negociação, modelo de custos e resultados posteriores definidos. Nosso protocolo de previsão de mercados trata isso como investigação separada. [6]

Para sinais baseados em texto, exija afirmações verificáveis: o que foi divulgado, quando ficou disponível e qual registro sustenta a interpretação. Audite a extração factual e o apoio semântico separadamente da validade da ordem. Ler um documento corretamente ainda pode levar a uma operação perdedora se o mercado já refletia a notícia ou se o movimento relevante ocorreu antes da execução.

Texto importado não pode conceder autoridade para negociar

Um documento regulatório, uma página de notícias ou um resultado de ferramenta pode conter instruções dirigidas ao modelo. A aplicação deve tratar esse material como evidência a avaliar, não como autorização para mudar contas, aumentar a alavancagem ou desativar limites. A orientação da Anthropic descreve essa fronteira de injeção indireta. Mantenha as ferramentas permitidas e os limites financeiros impostos fora do texto gerado pelo modelo. [7]

O benchmark original de segurança de agentes AgentDojo estuda tarefas legítimas e ataques em ambientes de aplicação simulados. Ele motiva testar tanto a conclusão útil das tarefas quanto o redirecionamento nocivo, em vez de verificar apenas se um modelo recusa todos os pedidos. Seus resultados não são certificação de segurança de um bot de trading. [9]

O caso de quantidade malformada mostra que uma proposta não pode acrescentar um campo de dimensionamento não autorizado a este contrato. O caso narrativo mostra que o texto não sobrepõe o controlador. Nenhum é teste de injeção de prompt contra ChatGPT ou Claude, porque nenhum modelo consumiu um ataque aqui. Uma avaliação real de segurança voltada ao modelo precisa enviar o material adversarial ao modelo e às ferramentas reais e inspecionar o estado final.

Uma proposta maliciosa válida pelo esquema ainda pode caber em todos os limites financeiros. Controles independentes restringem ações permitidas; não fabricam intenção correta ou valor de investimento. Limitar autoridade e testar a utilidade do sinal são tarefas complementares.

Onde um modelo de linguagem justifica seu lugar no sistema

Se a estratégia é inteiramente especificada por limites numéricos, calcule-os diretamente. Um bot Python ou uma estratégia Pine Script pode avaliar uma regra fixa sem chamar um LLM a cada barra. A IA ainda pode ajudar a implementar a estratégia, revisar os registros ou diagnosticar um erro. É um papel diferente de escolher operações online.

Para quem aprende a construir um algoritmo de trading, comece pelo mandato de negociação e por condições de aceitação mensuráveis. Codex ou Claude Code podem ajudar a implementar o construtor do pacote, dimensionamento decimal, testes e adaptadores. Versione esses componentes com o mesmo cuidado do sinal. Uma ponte para bot de TradingView precisa preservar o horário do alerta, a política de ordens e a conciliação, em vez de tratar um alerta como execução.

Um papel online para o LLM é mais plausível quando a tarefa exige interpretação que uma regra numérica simples não oferece, como classificar um documento regulatório sob uma taxonomia definida. Registre a afirmação extraída, sua origem e a ação resultante. Depois teste se essa interpretação acrescenta valor após sua latência, custos de dados e de inferência. A análise prática aqui não demonstra esse benefício incremental.

Um briefing útil de proposta pede referências de evidência, justificativa concisa e HOLD quando falta uma premissa necessária. É um requisito de interface, não um prompt comprovado para gerar operações lucrativas. Um primeiro marco sensato é um fluxo simulado capaz de explicar, a partir dos registros, cada solicitação aceita, bloqueada, ignorada ou não resolvida.

Separe correção do controlador, comportamento do modelo e vantagem de trading

Avalie três camadas separadamente. Para o controlador, use identidades numéricas independentes, entradas inválidas controladas, controles positivos e conciliação de estado. Para o modelo, faça solicitações reais com pacotes congelados e registre versões exatas de provedor/modelo, prompts, resultados de ferramentas, parâmetros de amostragem, recusas, novas tentativas e custos. Para a estratégia, sele as decisões antes dos resultados de mercado e avalie seu valor incremental após custos contra alternativas razoáveis.

A orientação da Anthropic para avaliar agentes distingue históricos e resultados finais. Isso importa aqui: o modelo dizer ‘ordem executada’ é uma afirmação; o registro de execução e a posição resultante estabelecem o estado do ambiente. Em uma comparação real de provedores, meça taxa de propostas utilizáveis, precisão das evidências, estabilidade das ações, latência e custo sob o mesmo ambiente de execução. Chamadas repetidas com um pacote são tentativas repetidas daquele pacote, não oportunidades de mercado independentes. [8]

Para evitar sobreajuste de estratégias, guarde todos os modelos, prompts e variantes de limites testados. Escolher o prompt que por acaso se ajusta a um período histórico também é otimização de estratégia. Testes fora da amostra e análises walk-forward precisam respeitar o que estava disponível em cada decisão e quais resultados anteriores foram usados para escolher a próxima versão. Eventos históricos reconhecíveis podem introduzir conhecimento retrospectivo dos dados de treinamento mesmo com horários corretos na aplicação.

Mantenha a mesma estrutura de risco e execução para o LLM e para uma referência sem LLM. Caso contrário, diferenças de custos ou dimensionamento podem parecer raciocínio superior. Uma simulação de Monte Carlo pode examinar consequências condicionadas às entradas, mas não fornece uma vantagem preditiva ausente nem calibra um rótulo informal de confiança. Nosso backtest executado de machine learning e o estudo de construção de algoritmos investigam a evidência separada necessária para desempenho de estratégia.

O que a investigação estabelece

Uma decisão de trading é distribuída entre a interface do modelo, o mandato da aplicação, o controlador de risco e o registro de execução. Nos casos examinados, o mesmo BUY mantém o tamanho quando a linguagem fica mais confiante, diminui sob limite menor, é ignorado quando o caixa autorizado não comporta uma ordem válida e é bloqueado quando o estado anterior é desconhecido.

A ordem admitida depois perde US$ 60.38976622 na trajetória construída com gap, apesar de passar na verificação de orçamento planejado de US$ 50. O registro preserva esse resultado, em vez de reescrever a explicação de entrada. O cálculo explica a perda; os resultados dos casos de controle não demonstram que ChatGPT ou Claude preveja o mercado.

Ao avaliar um sistema de trading com IA, peça o pacote, a proposta estruturada, a autoridade exata que a admitiu, os registros de ordem e execução e o resultado conciliado da conta. Esses registros explicam o que o sistema realmente fez. Um parágrafo convincente de BUY oferece apenas uma parte dessa cadeia.