Entwicklung eines Slay the Spire 2-Agenten mit lokalen LLMs: Erkenntnisse und offene Probleme

Ein Entwickler hat einen Agenten erstellt, der Slay the Spire 2 mithilfe lokaler LLMs über KoboldCPP/Ollama spielt. Das Spiel wird über einen Community-Mod als REST-API bereitgestellt, und der Agent sitzt dazwischen: liest Spielzustand → ruft LLM mit Tools auf → führt Aktion aus → wiederholt.

Einrichtung und Leistung

Die Einrichtung verwendet Qwen3.5-27B (Q4_K_M) auf einer RTX 4090 über KoboldCPP. Leistungsmetriken: etwa 10 Sekunden pro Aktion, etwa 88 % Erfolgsquote bei Aktionen. Bestes Ergebnis: Besiegen des Akt-1-Bosses. Das Projekt ist auf GitHub verfügbar unter https://github.com/Alex5418/STS2-Agent.

Was funktioniert

• Zustandsbasiertes Tool-Routing – Anstatt 20+ Tools gleichzeitig bereitzustellen, werden nur 1–3 Tools angeboten, die für den aktuellen Spielzustand relevant sind. Im Kampf gibt es play_card, end_turn, use_potion. Auf der Kartenansicht gibt es choose_map_node. Dies reduziert halluzinierte Tool-Aufrufe drastisch.
• Single-Tool-Modus – Kleine Modelle können nicht vorhersagen, wie sich der Spielzustand nach einer Aktion ändert (z. B. verschieben sich Kartenindizes nach dem Ausspielen einer Karte). Daher wird nur der erste Tool-Aufruf pro Antwort ausgeführt, dann wird der Spielzustand neu abgerufen und das Modell erneut gefragt. Langsamer, aber viel zuverlässiger.
• Textbasierter Tool-Aufrufparser (Fallback) – KoboldCPP gibt Tool-Aufrufe oft als Text statt strukturiertem JSON aus. Ein Multi-Pattern-Regex-Fallback erfasst Formate wie: json [{"name": "play_card", "arguments": {...}}], Made a function call ... to play_card with arguments = {...}, play_card({"card_index": 1, "target": "NIBBIT_0"}) und bloße Erwähnungen von Tools ohne Argumente wie end_turn. Dies rettet etwa 15–20 % der Aktionen, die sonst verloren wären.
• Energie-Wächter – Clientseitige Verfolgung der verbleibenden Energie. Wenn das Modell versucht, eine Karte zu spielen, die es sich nicht leisten kann, wird der API-Aufruf blockiert und der Zug automatisch beendet. Dies verhindert die häufigste Fehlerschleife (Modell versucht dieselbe unbezahlbare Karte 3+ Mal).
• Intelligentes Warten auf Gegnerzüge – Während des Zuges des Gegners zeigt der Spielzustand "Play Phase: False" an. Statt einen LLM-Aufruf dafür zu verschwenden, fragt der Agent jede Sekunde ab, bis der Spieler wieder am Zug ist.

Offene Probleme

• Modell folgt Systemprompt-Regeln nicht konsistent – Der Systemprompt sagt Dinge wie "wenn die Absicht des Gegners Angriff ist, spiele zuerst Verteidigungskarten". Das Modell folgt dem vielleicht in 30 % der Fälle. In den anderen 70 % spielt es einfach Angriffe, egal was passiert. Versuchte Lösungen: stärkere Formulierungen ("Du MUSST zuerst blockieren"), Few-Shot-Beispiele im Prompt, Einfügen berechneter Hinweise ("WARNUNG: 15 ankommender Schaden"). Keine davon ist zuverlässig. Frage: Gibt es eine bessere Prompting-Strategie, um kleine Modelle dazu zu bringen, bedingten Regeln zu folgen? Oder ist das eine grundlegende Einschränkung bei 27B?
• Tool-Aufrufzuverlässigkeit mit KoboldCPP – Selbst mit dem Text-Fallback-Parser produzieren etwa 12 % der Antworten keinen brauchbaren Tool-Aufruf. Das Modell gibt manchmal leere <think></think>-Blöcke gefolgt von fehlerhaftem JSON aus. Die Ollama-OpenAI-Kompatibilitätsschicht gibt gelegentlich auch arguments als String statt als Dict zurück. Frage: Hat jemand ein Modell gefunden, das besonders zuverlässig Tool-Aufrufe im Bereich 14–30B durchführt? Der Entwickler hat Phi-4 (14B) kurz ausprobiert, aber keinen ordentlichen Vergleich durchgeführt. Erwägt Mistral-Small oder Command-R.
• Kontextfensterverwaltung – Jeder Spielzustand ist etwa 800–1500 Token als Markdown. Mit Systemprompt (~500 Token) und Konversationsverlauf füllt sich der Kontext schnell. Derzeit werden nur die letzten 5 Austausche behalten und der Verlauf bei Zustandsübergängen (Kampf → Karte usw.) zurückgesetzt. Aber das Modell hat kein Gedächtnis über Kämpfe hinweg – es kann nicht aus Fehlern lernen. Frage: Würde ein rollierender Zusammenfassungsansatz funktionieren? Wie etwa den letzten Kampf zu "Du hast gegen Jaw Worm gekämpft. Hast 15 Schaden erlitten, weil du in Runde 2 nicht geblockt hast. In 4 Runden gewonnen" verdichten.
• Bessere strukturierte Ausgabe von lokalen Modellen – Das Kernproblem ist, dass das Modell einen JSON-Tool-Aufruf ausgeben muss, aber es eigentlich zuerst in natürlicher Sprache denken möchte. Qwen3.5 verwendet <think>-Blöcke, die entfernt werden, aber manchmal vermischen sich das Denken und der Tool-Aufruf. Frage: Würde ein zweistufiger Ansatz besser funktionieren? Stufe 1: "Analysiere den Spielzustand und entscheide, was zu tun ist" (Freitext). Stufe 2: "Gib jetzt genau einen Tool-Aufruf aus" (eingeschränkt). Dies verdoppelt die Latenz, könnte aber die Zuverlässigkeit verbessern. Hat jemand dieses Muster ausprobiert?
• A/B-Tests über Modelle hinweg – Der Entwickler hat ein JSONL-Protokollierungssystem, das Aktionen für Vergleiche aufzeichnet.