A melhor arquitetura de prompt para FX Bots em 2026

Autor: Equipa FXMacroData
Publicação: 21 de Maio de 2026

A maioria dos bots FX não falha porque eles usam o modelo errado. Eles falham porque eles utilizam uma arquitetura de prompt fraca. Na negociação ao vivo, um prompt não é um parágrafo. É uma superfície de controle que decide como seu sistema interpreta o contexto, aplica a política de risco e forma decisões.

Se o teu robô monitorizar ... USD/JPY, lida com lançamentos como PNFPEste guia dá-lhe uma arquitetura prática que faz exatamente isso.

Por que os sinais de bloco único entram em mercados reais

Um único prompt longo geralmente mistura contexto, política e formato desejado em uma mancha. Isso torna o comportamento instável quando o tamanho da entrada muda ou as condições do mercado aumentam.

Sintomas comuns:

• JSON limpo em sessões calmas, saída malformada em sessão volátil.
• Narrativa confiante com níveis de invalidação ausentes.
• Suposições de risco implícitas que se deslocam ao longo do tempo.

A solução é a arquitetura, não mais adjetivos.

Camada 1: Informações de estado (apenas fatos)

A camada de estado deve conter apenas contexto objetivo extraído de APIs.

{
  "asof_utc": "2026-05-21T20:00:00Z",
  "pairs": {
    "EUR/USD": { "last": 1.0872, "change_24h_pct": 0.42 },
    "USD/JPY": { "last": 156.81, "change_24h_pct": -0.35 }
  },
  "events": [
    { "currency": "USD", "indicator": "core_pce", "time_utc": "2026-05-22T12:30:00Z" },
    { "currency": "GBP", "indicator": "unemployment", "time_utc": "2026-05-22T06:00:00Z" }
  ]
}

Construir isso a partir de pontos finais estáveis, por exemplo:

curl "https://fxmacrodata.com/api/v1/announcements/usd/core_pce?api_key=YOUR_API_KEY"
curl "https://fxmacrodata.com/api/v1/announcements/gbp/unemployment?api_key=YOUR_API_KEY"
curl "https://fxmacrodata.com/api/v1/forex?base=EUR&quote=USD&api_key=YOUR_API_KEY"

Camada 2: Regras Promptas (Limitas de Raciocínio)

A camada de regras define como o modelo pode pensar e o que não pode fazer.

You are an FX research assistant.

Allowed:
- Infer directional bias from supplied macro + price context.
- Mention uncertainty explicitly.

Not allowed:
- Invent missing data.
- Give broker execution instructions.
- Output fields outside contract.

Behavior:
- If data is insufficient, return action=flat with reason="insufficient_context".
- Prefer concise causal chains over broad narratives.

Isso separa a política de inferência dos dados brutos, o que torna a depuração muito mais fácil.

Nível 3: Risco imediato (condições difíceis)

Trate-o como um contrato imutável.

Risk policy v1:
- max_size_pct = 0.50
- min_confidence = 0.60
- invalidation is mandatory
- no new risk inside +/- 15 minutes of high-impact calendar events
- if any rule fails, return action=flat and policy_status=reject

Quando a comunicação do banco central da Reserva Federal Ou ... Banco do Japão A inflação de confiança é reduzida a uma taxa de inflação que é próxima, esta camada impede que a inflação se transforme em transações de grande porte.

Camada 4: Contrato de saída (Interface determinística)

O contrato de saída é o que o seu porteiro ou motor de execução realmente consome.

{
  "action": "long|short|flat",
  "pair": "string",
  "confidence": 0.0,
  "thesis": "string",
  "invalidation": "string",
  "size_pct": 0.0,
  "policy_status": "approve|reject",
  "next_data_to_watch": ["string"]
}

Rejeitar qualquer resposta que falhe na validação do esquema. Nunca tente a análise de melhor esforço na produção.

Montar a pilha completa

Na implementação, mantenha cada camada versão independente e combinar no tempo de execução:

PROMPT = {
    "state": state_payload,            # dynamic JSON
    "rules": rules_block_v3,           # static text
    "risk": risk_policy_v1,            # static text
    "output_contract": contract_json,  # static schema
}

final_prompt = f"""
STATE:\n{PROMPT['state']}

RULES:\n{PROMPT['rules']}

RISK:\n{PROMPT['risk']}

OUTPUT CONTRACT:\n{PROMPT['output_contract']}

Return JSON only.
"""

Esta estrutura torna post-mortems claro. Se o comportamento muda, você pode identificar se os dados do estado mudaram, regras mudaram , risco mudou, ou a aplicação do contrato mudou.

Um modelo de produção rápida que você pode reutilizar

Se você quiser um comportamento previsível, mude de edições de prompt ad-hoc para modelos explícitos.

{
  "prompt_id": "fx_agent_v6",
  "state_version": "state_schema_v2",
  "rules_version": "rules_v3",
  "risk_version": "risk_v1_2",
  "contract_version": "decision_contract_v4",
  "fallback_mode": "flat_on_error"
}

Conecte isso ao seu tempo de execução para que cada registro de decisão armazene as quatro versões, o que lhe dá comparabilidade instantânea quando executar testes de repetição ou investigar a deriva após uma semana de alto impacto.

Ordem de blocos sugerida nos pedidos finais:

1. Identidade e âmbito do sistema (curtos, estáveis).
2. Estado da carga útil (apenas dados JSON).
3. Bloqueio de regras (comportamento permitido/não permitido).
4. Bloco de risco (constrações não negociáveis).
5. Contrato de saída (esquema JSON + instrução de retorno exclusivo).
6. Instrução de recuperação de erro (flat A Comissão não pode, por conseguinte,

Não coloque orientações narrativas longas antes das instruções do contrato.

Roteamento rápido com conhecimento de regime

Uma única arquitetura de prompt ainda precisa de roteamento de regime. Suas regras de "sessão calma" não devem ser idênticas às regras de choque de evento. Use um roteador leve antes da inferência:

def select_prompt_profile(next_event_minutes: int, realized_vol_pct: float) -> str:
    if abs(next_event_minutes) <= 20:
        return "event_profile"
    if realized_vol_pct >= 1.1:
        return "high_vol_profile"
    return "normal_profile"

Cada perfil pode compartilhar o mesmo contrato, alterando os limiares de risco e as restrições de estilo de raciocínio.

Gestão de falhas e design de recuperação

A qualidade da arquitetura de prompt é visível quando as coisas dão errado, não quando elas dão certo.

• Falha no esquema: A saída é rejeitada, o roteador tenta novamente uma vez com contexto compacto.
• Conflito de políticas: A acção é forçada a flat Com policy_status=reject- Não .
• Insuficiência de dados: Não se produz nenhum candidato comercial e é emitida uma alerta.

Bloco de política de reserva mínimo:

Fallback policy:
- If contract parse fails -> return flat candidate from deterministic fallback template.
- If policy_status != approve -> do not call execution adapter.
- If data freshness check fails -> skip inference and publish "no-decision" note.

É isto que separa um robusto assistente FX de um frágil robô demo.

Lista de verificação de validação antes da utilização em tempo real

1. Taxa de aprovação do esquema acima do limiar-alvo nos testes de repetição.
2. A conformidade com as políticas está próxima de 100% em janelas com grandes eventos desde o início do ano passado. Calendário de lançamento- Não .
3. Sem campos alucinados em conteúdos de conteúdo misto.
4. Comportamento estável em todas as sessões monitorizadas por Sessões de câmbio- Não .
5. As versões do prompt e do gatekeeper estão bloqueadas e auditáveis.

Resumo

A arquitetura de prompt é a camada de engenharia que falta em muitas pilhas de negociação de IA. Divida seu prompt em camadas de estado, regras, risco e contrato, e depois aplique cada uma com validação determinista. É assim que você transforma a inteligência do modelo em comportamento repetível.

O próximo passo: executar os benchmarks de repetição mensal e rastrear a deriva por camada.