Construire un Agent pour Slay the Spire 2 avec des LLM Locaux : Leçons et Problèmes Ouverts

Un développeur a créé un agent qui joue à Slay the Spire 2 en utilisant des LLM locaux via KoboldCPP/Ollama. Le jeu est exposé comme une API REST via un mod communautaire, et l'agent se situe au milieu : il lit l'état du jeu → appelle le LLM avec des outils → exécute l'action → répète.

Configuration et Performances

La configuration utilise Qwen3.5-27B (Q4_K_M) sur RTX 4090 via KoboldCPP. Métriques de performance : environ 10 secondes par action, taux de réussite des actions d'environ 88 %. Meilleur résultat : vaincre le boss de l'Acte 1. Le projet est disponible sur GitHub à https://github.com/Alex5418/STS2-Agent.

Ce qui Fonctionne

• Routage d'outils basé sur l'état — Au lieu d'exposer 20+ outils à la fois, seuls 1 à 3 outils pertinents pour l'état actuel du jeu sont fournis. Le combat obtient play_card, end_turn, use_potion. L'écran de carte obtient choose_map_node. Cela a considérablement réduit les appels d'outils hallucinés.
• Mode outil unique — Les petits modèles ne peuvent pas prédire comment l'état du jeu change après une action (par exemple, les indices des cartes changent après avoir joué une carte). Ainsi, seul le premier appel d'outil par réponse est exécuté, puis l'état du jeu est récupéré et le modèle est interrogé à nouveau. Plus lent mais beaucoup plus fiable.
• Analyseur d'appels d'outils basé sur du texte (solution de secours) — KoboldCPP produit souvent des appels d'outils sous forme de texte plutôt que de JSON structuré. Une solution de secours à motifs multiples capture des formats comme : json [{"name": "play_card", "arguments": {...}}], Made a function call ... to play_card with arguments = {...}, play_card({"card_index": 1, "target": "NIBBIT_0"}), et des mentions simples d'outils sans arguments comme end_turn. Cela récupère peut-être 15 à 20 % des actions qui seraient autrement perdues.
• Garde d'énergie — Suivi côté client de l'énergie restante. Si le modèle essaie de jouer une carte qu'il ne peut pas se permettre, l'appel API est bloqué et le tour est automatiquement terminé. Cela empêche la boucle d'erreur la plus courante (le modèle réessaie la même carte inabordable 3 fois ou plus).
• Attente intelligente pour les tours ennemis — Pendant le tour de l'ennemi, l'état du jeu indique "Play Phase: False." Au lieu de gaspiller un appel LLM sur cela, l'agent interroge toutes les 1 seconde jusqu'à ce que ce soit de nouveau le tour du joueur.

Problèmes Ouverts

• Le modèle ne suit pas systématiquement les règles du prompt système — Le prompt système dit des choses comme "si l'intention de l'ennemi est Attack, jouez d'abord les cartes Defend." Le modèle suit cela peut-être 30 % du temps. Les 70 % restants, il joue simplement des attaques quoi qu'il arrive. Solutions tentées : formulation plus forte ("Vous DEVEZ bloquer d'abord"), exemples few-shot dans le prompt, injection d'indices calculés ("ATTENTION : 15 dégâts entrants"). Aucune n'est fiable. Question : Existe-t-il une meilleure stratégie de prompting pour amener les petits modèles à suivre des règles conditionnelles ? Ou s'agit-il d'une limitation fondamentale à 27B ?
• Fiabilité des appels d'outils avec KoboldCPP — Même avec l'analyseur de secours textuel, environ 12 % des réponses ne produisent aucun appel d'outil utilisable. Le modèle produit parfois des blocs <think></think> vides suivis de JSON mal formé. La couche de compatibilité OpenAI d'Ollama renvoie aussi occasionnellement arguments comme une chaîne au lieu d'un dictionnaire. Question : Quelqu'un a-t-il trouvé un modèle particulièrement fiable pour les appels d'outils dans la plage 14-30B ? Le développeur a essayé Phi-4 (14B) brièvement mais n'a pas fait de comparaison approfondie. Il envisage Mistral-Small ou Command-R.
• Gestion de la fenêtre de contexte — Chaque état de jeu représente environ 800 à 1500 tokens en markdown. Avec le prompt système (~500 tokens) et l'historique de conversation, le contexte se remplit rapidement. Actuellement, il ne conserve que les 5 derniers échanges et réinitialise l'historique lors des transitions d'état (combat → carte, etc.). Mais le modèle n'a pas de mémoire entre les combats — il ne peut pas apprendre de ses erreurs. Question : Une approche de résumé glissant fonctionnerait-elle ? Comme condenser le dernier combat en "Vous avez combattu Jaw Worm. Vous avez subi 15 dégâts parce que vous n'avez pas bloqué au tour 2. Victoire en 4 tours."
• Meilleure sortie structurée des modèles locaux — Le problème central est que le modèle doit produire un appel d'outil JSON, mais ce qu'il veut vraiment faire, c'est d'abord réfléchir en langage naturel. Qwen3.5 utilise des blocs <think> qui sont supprimés, mais parfois la réflexion et l'appel d'outil s'entremêlent. Question : Une approche en deux étapes fonctionnerait-elle mieux ? Étape 1 : "Analysez l'état du jeu et décidez quoi faire" (texte libre). Étape 2 : "Maintenant, produisez exactement un appel d'outil" (contraint). Cela double la latence mais pourrait améliorer la fiabilité. Quelqu'un a-t-il essayé ce modèle ?
• Tests A/B entre modèles — Le développeur dispose d'un système de journalisation JSONL qui enregistre les actions pour comparaison.