Construindo um Agente para Slay the Spire 2 com LLMs Locais: Lições e Problemas em Aberto

Um desenvolvedor criou um agente que joga Slay the Spire 2 usando LLMs locais via KoboldCPP/Ollama. O jogo é exposto como uma API REST através de um mod da comunidade, e o agente fica no meio: lê o estado do jogo → chama o LLM com ferramentas → executa a ação → repete.

Configuração e Desempenho

A configuração usa Qwen3.5-27B (Q4_K_M) em RTX 4090 via KoboldCPP. Métricas de desempenho: ~10 segundos por ação, ~88% de taxa de sucesso nas ações. Melhor resultado: derrotar o chefe do Ato 1. O projeto está disponível no GitHub em https://github.com/Alex5418/STS2-Agent.

O que Funciona

• Roteamento de ferramentas baseado em estado — Em vez de expor 20+ ferramentas de uma vez, apenas 1-3 ferramentas relevantes para o estado atual do jogo são fornecidas. Combate recebe play_card, end_turn, use_potion. Tela do mapa recebe choose_map_node. Isso reduziu drasticamente as chamadas de ferramentas alucinadas.
• Modo de ferramenta única — Modelos pequenos não conseguem prever como o estado do jogo muda após uma ação (por exemplo, índices de cartas mudam após jogar uma carta). Portanto, apenas a primeira chamada de ferramenta por resposta é executada, então o estado do jogo é recuperado novamente e o modelo é solicitado outra vez. Mais lento, mas muito mais confiável.
• Analisador de chamadas de ferramentas baseado em texto (fallback) — KoboldCPP frequentemente gera chamadas de ferramentas como texto em vez de JSON estruturado. Um fallback de regex com múltiplos padrões captura formatos como: json [{"name": "play_card", "arguments": {...}}], Made a function call ... to play_card with arguments = {...}, play_card({"card_index": 1, "target": "NIBBIT_0"}), e menções diretas de ferramentas sem argumentos como end_turn. Isso recupera talvez 15-20% das ações que seriam perdidas.
• Guardião de energia — Rastreamento no lado do cliente da energia restante. Se o modelo tentar jogar uma carta que não pode pagar, a chamada da API é bloqueada e o turno é automaticamente encerrado. Isso evita o loop de erro mais comum (o modelo tenta a mesma carta inacessível 3+ vezes).
• Espera inteligente para turnos inimigos — Durante o turno do inimigo, o estado do jogo diz "Play Phase: False." Em vez de desperdiçar uma chamada de LLM nisso, o agente verifica a cada 1s até que seja o turno do jogador novamente.

Problemas em Aberto

• Modelo não segue regras do prompt do sistema consistentemente — O prompt do sistema diz coisas como "se a intenção do inimigo for Ataque, jogue cartas de Defesa PRIMEIRO." O modelo segue isso talvez 30% das vezes. Os outros 70% ele apenas joga ataques independentemente. Soluções tentadas: redação mais forte ("Você DEVE bloquear primeiro"), exemplos few-shot no prompt, injeção de dicas calculadas ("AVISO: 15 de dano recebido"). Nenhuma é confiável. Pergunta: Existe uma estratégia de prompting melhor para fazer modelos pequenos seguirem regras condicionais? Ou isso é uma limitação fundamental em 27B?
• Confiabilidade na chamada de ferramentas com KoboldCPP — Mesmo com o analisador de fallback de texto, cerca de 12% das respostas não produzem uma chamada de ferramenta utilizável. O modelo às vezes gera blocos <think></think> vazios seguidos de JSON malformado. A camada de compatibilidade OpenAI do Ollama também ocasionalmente retorna arguments como uma string em vez de um dicionário. Pergunta: Alguém encontrou um modelo particularmente confiável em chamadas de ferramentas na faixa de 14-30B? O desenvolvedor testou Phi-4 (14B) brevemente, mas não fez uma comparação adequada. Considerando Mistral-Small ou Command-R.
• Gerenciamento da janela de contexto — Cada estado do jogo tem ~800-1500 tokens como markdown. Com o prompt do sistema (~500 tokens) e o histórico da conversa, o contexto enche rapidamente. Atualmente mantém apenas as últimas 5 trocas e redefine o histórico em transições de estado (combate → mapa, etc.). Mas o modelo não tem memória entre lutas — ele não pode aprender com os erros. Pergunta: Uma abordagem de resumo contínuo funcionaria? Como condensar o último combate em "Você lutou contra Jaw Worm. Recebeu 15 de dano porque não bloqueou no turno 2. Venceu em 4 turnos."
• Saída estruturada melhor de modelos locais — O problema central é precisar que o modelo gere uma chamada de ferramenta em JSON, mas o que ele realmente quer fazer é pensar em linguagem natural primeiro. Qwen3.5 usa blocos <think> que são removidos, mas às vezes o pensamento e a chamada de ferramenta se misturam. Pergunta: Uma abordagem em duas etapas funcionaria melhor? Etapa 1: "Analise o estado do jogo e decida o que fazer" (texto livre). Etapa 2: "Agora gere exatamente uma chamada de ferramenta" (restrito). Isso dobra a latência, mas pode melhorar a confiabilidade. Alguém já tentou esse padrão?
• Testes A/B entre modelos — O desenvolvedor tem um sistema de registro JSONL que grava ações para comparação.