Создание агента для Slay the Spire 2 с использованием локальных LLM: уроки и нерешённые задачи

Разработчик создал агента, который играет в Slay the Spire 2, используя локальные LLM через KoboldCPP/Ollama. Игра доступна как REST API через мод сообщества, а агент находится посередине: читает состояние игры → вызывает LLM с инструментами → выполняет действие → повторяет.

Настройка и производительность

Настройка использует Qwen3.5-27B (Q4_K_M) на RTX 4090 через KoboldCPP. Метрики производительности: ~10 секунд на действие, ~88% успешности действий. Лучший результат: победа над боссом Акта 1. Проект доступен на GitHub по адресу https://github.com/Alex5418/STS2-Agent.

Что работает

• Маршрутизация инструментов на основе состояния — Вместо предоставления 20+ инструментов одновременно, предоставляются только 1-3 инструмента, релевантных текущему состоянию игры. В бою используются play_card, end_turn, use_potion. На карте используется choose_map_node. Это значительно сократило количество галлюцинаций при вызове инструментов.
• Режим одного инструмента — Малые модели не могут предсказать, как изменится состояние игры после действия (например, индексы карт смещаются после разыгрывания карты). Поэтому выполняется только первый вызов инструмента в ответе, затем состояние игры обновляется, и модель запрашивается снова. Медленнее, но гораздо надежнее.
• Текстовый парсер вызова инструментов (резервный) — KoboldCPP часто выводит вызовы инструментов в виде текста вместо структурированного JSON. Резервный многопатерновый регулярный выражение ловит форматы вроде: json [{"name": "play_card", "arguments": {...}}], Made a function call ... to play_card with arguments = {...}, play_card({"card_index": 1, "target": "NIBBIT_0"}) и простые упоминания инструментов без аргументов, например end_turn. Это восстанавливает, возможно, 15-20% действий, которые иначе были бы потеряны.
• Защита энергии — Отслеживание оставшейся энергии на стороне клиента. Если модель пытается разыграть карту, которую не может позволить, вызов API блокируется, и ход автоматически завершается. Это предотвращает наиболее распространенный цикл ошибок (модель повторяет ту же недоступную карту 3+ раза).
• Умное ожидание хода врага — Во время хода врага состояние игры показывает "Play Phase: False". Вместо траты вызова LLM на это, агент опрашивает каждую 1 секунду, пока снова не наступит ход игрока.

Открытые проблемы

• Модель не следует правилам системного промпта последовательно — Системный промпт говорит такие вещи, как "если намерение врага — Атака, играйте карты Защиты ПЕРВЫМИ". Модель следует этому, возможно, в 30% случаев. В остальных 70% она просто играет атаки независимо. Попытки решений: более сильные формулировки ("Вы ДОЛЖНЫ блокировать сначала"), несколько примеров в промпте, введение вычисленных подсказок ("ПРЕДУПРЕЖДЕНИЕ: 15 входящего урона"). Ни один не надежен. Вопрос: Существует ли лучшая стратегия промптинга для заставления малых моделей следовать условным правилам? Или это фундаментальное ограничение на уровне 27B?
• Надежность вызова инструментов с KoboldCPP — Даже с резервным текстовым парсером около 12% ответов не производят пригодного вызова инструмента. Модель иногда выводит пустые блоки <think></think>, за которыми следует некорректный JSON. Слой совместимости Ollama OpenAI также иногда возвращает arguments как строку вместо словаря. Вопрос: Кто-нибудь нашел модель, которая особенно надежна в вызове инструментов в диапазоне 14-30B? Разработчик кратко пробовал Phi-4 (14B), но не проводил должного сравнения. Рассматривает Mistral-Small или Command-R.
• Управление контекстным окном — Каждое состояние игры составляет ~800-1500 токенов в виде markdown. С системным промптом (~500 токенов) и историей диалога контекст быстро заполняется. В настоящее время сохраняются только последние 5 обменов, и история сбрасывается при переходах состояний (бой → карта и т.д.). Но у модели нет памяти между боями — она не может учиться на ошибках. Вопрос: Сработает ли подход с скользящим резюме? Например, сжатие последнего боя в "Вы сражались с Jaw Worm. Получили 15 урона, потому что не блокировали на 2-м ходу. Победили за 4 хода."
• Лучший структурированный вывод от локальных моделей — Основная проблема заключается в необходимости, чтобы модель выводила вызов инструмента JSON, но на самом деле она хочет сначала думать на естественном языке. Qwen3.5 использует блоки <think>, которые удаляются, но иногда мышление и вызов инструмента переплетаются. Вопрос: Будет ли лучше работать двухэтапный подход? Этап 1: "Проанализируйте состояние игры и решите, что делать" (свободный текст). Этап 2: "Теперь выведите ровно один вызов инструмента" (ограниченный). Это удваивает задержку, но может улучшить надежность. Кто-нибудь пробовал эту схему?
• A/B тестирование между моделями — У разработчика есть система логирования JSONL, которая записывает действия для сравнения.