От нейронного токена к символическому разуму: эволюция автономных агентов в игровых средах

Обзорная статья | Апрель 2026 | Скачать как документ

Аннотация

Настоящая статья рассматривает эволюцию автономных агентов, обучающихся в игровых средах, — от первых систем на основе крупных языковых моделей (LLM) до гибридных реактивно-делиберативных архитектур с живым символическим рефакторингом. Мы анализируем фундаментальные ограничения чисто нейросетевых подходов, исследуем вклад Voyager как первого прототипа агента с самописным кодом, а затем прослеживаем два ключевых направления его развития: автономное обучение domain-independent абстракций (TheoryCoder-2) и живой онлайн-рефакторинг программных библиотек навыков (Evolving Programmatic Skill Networks). На основе синтеза этих работ предлагается архитектура, сочетающая реактивный слой быстрого реагирования с делиберативным слоем стратегического планирования, что открывает путь к универсальным агентам, переносимым между произвольными игровыми средами без переобучения модели.

Ключевые слова: автономные агенты, lifelong learning, программный синтез, символическое планирование, PDDL, рефакторинг навыков, реактивно-делиберативная архитектура, игровые среды, обобщение знаний.

1. Введение: фундаментальные проблемы обучения агентов

Создание агентов, способных автономно действовать в сложных динамических средах, остаётся одной из центральных задач современного искусственного интеллекта. Игровые среды — в особенности Minecraft, Crafter, BabyAI и им подобные — стали стандартным полигоном для проверки этих идей: они достаточно сложны, чтобы выявлять реальные ограничения архитектур, и достаточно управляемы, чтобы допускать воспроизводимые эксперименты.

Прежде чем рассматривать конкретные системы, необходимо чётко обозначить фундаментальные ограничения, с которыми сталкиваются два доминирующих класса подходов: нейросетевые LLM-агенты и классические детерминированные алгоритмы. Именно понимание этих ограничений объясняет, почему потребовалась архитектурная эволюция, описываемая в данной статье.

1.1. Ограничения нейросетевых подходов

1.1.1. Отсутствие понимания и опора на статистические корреляции

Современные большие языковые модели, при всей своей впечатляющей способности генерировать связные тексты и код, не формируют каузальных моделей мира. Они работают с условными вероятностями токенов, накопленными в процессе обучения на огромных корпусах текстов. Когда такой агент решает задачу «добудь железную руду», он не рассуждает о механике горного дела — он воспроизводит статистически вероятный паттерн, встречавшийся в обучающих данных.

Это порождает характерный класс ошибок: агент уверенно предлагает действия, правдоподобные в тексте, но физически невозможные в среде. В экспериментах с Voyager наблюдалось явление так называемых «галлюцинированных API-вызовов» — генерация вызовов функций Mineflayer, не существующих в данной версии библиотеки. Модель не осознаёт, что её знание устарело или было экстраполировано из неверного контекста.

1.1.2. Медлительность инференса и проблема реального времени

Генерация одного ответа современными LLM занимает от долей секунды до нескольких десятков секунд в зависимости от размера модели и длины контекста. Для пошаговых игр вроде Sokoban или BabyAI это приемлемо. Для динамичных сред — MMORPG, шутеров от первого лица, экшен-RPG — это принципиальный барьер.

Когда противник атакует за 200 миллисекунд, у агента нет возможности отправить запрос к LLM, дождаться ответа и только затем начать уклонение. Это ограничение носит не инженерный, а архитектурный характер: трансформерная архитектура с вниманием (attention) масштабируется квадратично по длине контекста и в принципе не может достичь рефлекторных скоростей реакции при сложных рассуждениях.

1.1.3. Отсутствие последовательности: каждый промпт — изолированный эпизод

LLM не имеет встроенной памяти между вызовами. Каждый запрос начинается заново: всё, что агент «помнит», должно быть явно включено в контекстное окно. При длительном обучении в игре это создаёт несколько проблем одновременно.

Во-первых, контекст неизбежно растёт: история действий, ошибок, извлечённые навыки, критика — всё это накапливается в промпте. После 50–100 итераций объём контекста выходит за пределы окна или приводит к так называемому «recency bias» — тенденции модели игнорировать информацию в начале длинного контекста в пользу недавних токенов. Во-вторых, два последовательных шага стратегии оказываются связаны только через текстовое описание в промпте, а не через подлинное представление о состоянии мира. Если промежуточное описание неточно, агент теряет нить.

Это принципиально отличает LLM-агента от человека-игрока: человек поддерживает непрерывную рабочую память, накапливает эпизодическую память и обновляет семантические убеждения о мире в фоновом режиме — без необходимости явно «ввозить» весь контекст в каждое решение.

1.1.4. Отсутствие истинного планирования на горизонте

Следствием предыдущих проблем является неспособность LLM-агентов к надёжному многошаговому планированию. Модель может сгенерировать разумно выглядящий план из 10 шагов, но уже на шаге 3, столкнувшись с неожиданным событием (смерть, потеря ресурсов, изменение среды), она не пересматривает план глобально — она просто генерирует следующий токен, наиболее вероятный при текущем контексте, который теперь содержит аномалию.

Подлинное планирование требует формального представления состояний, операторов и целей, позволяющего поиску по пространству состояний находить оптимальные траектории с учётом ограничений. LLM имитирует планирование, но не осуществляет его.

1.2. Ограничения детерминированных алгоритмических подходов

Классические алгоритмические агенты — конечные автоматы (FSM), деревья поведения (Behavior Trees), системы правил (rule-based expert systems) — лишены описанных выше проблем. Они детерминированы, быстры, воспроизводимы и поддаются формальному анализу. Однако у них есть симметричный набор ограничений.

Такие системы требуют, чтобы все знания о мире и все стратегии поведения были явно запрограммированы заранее. Это порождает комбинаторный взрыв: даже в относительно простой игровой среде число возможных состояний и ситуаций, требующих отдельного правила, быстро делает ручное программирование непрактичным. Более серьёзно то, что такие системы не обобщают: правило «если враг в радиусе 5 блоков, убегай» не трансформируется автоматически в «если враг в радиусе 5 блоков и у стены, атакуй» — это требует отдельного правила, написанного человеком.

Наконец, детерминированные агенты не способны к творческому решению нестандартных задач. Если ситуация не предусмотрена правилами, агент замирает или ведёт себя хаотично. Именно этот пробел пытаются заполнить LLM-агенты — за счёт гибкости, но ценой вышеописанных проблем.

Таким образом, перед исследователями стоит задача синтеза: создать агента, сочетающего гибкость и обобщающую способность языковых моделей с детерминированностью, скоростью и формальной строгостью алгоритмических систем. Именно этот синтез является лейтмотивом эволюции, описываемой в данной статье.

2. Voyager: первый шаг к самопрограммирующемуся агенту

Voyager, представленный командой MineDojo в 2023 году, стал первой системой, продемонстрировавшей принципиальную возможность lifelong learning в сложной открытой среде с опорой на генерацию исполняемого кода.^[1] Его ключевая идея проста и элегантна: вместо того чтобы LLM непосредственно управлял каждым действием агента, он генерирует JavaScript-функции для API Mineflayer, которые затем исполняются в игровой среде. Успешные функции сохраняются в векторной базе данных ChromaDB и впоследствии извлекаются как контекст для новых задач.

2.1. Архитектура Voyager

Система состоит из трёх взаимодействующих агентов, каждый из которых реализован как отдельный LLM-промпт в цикле LangGraph.

Агент учебного плана (Curriculum Agent) анализирует текущее состояние игрока — инвентарь, координаты, здоровье, выполненные задачи — и предлагает следующую достижимую цель в формате, пригодном для исполнения (например, «Mine 5 iron_ore»). Агент действий (Action Agent) получает эту цель, извлекает из ChromaDB наиболее семантически близкие навыки и генерирует новую JavaScript-функцию, реализующую поставленную задачу. Агент критики (Critic Agent) оценивает результат выполнения, сравнивая состояние до и после, и выносит вердикт об успехе.

Иерархия навыков нарастает снизу вверх: двенадцать примитивов (mineBlock, craftItem, placeItem и другие) образуют нулевой уровень; на первом уровне появляются базовые комбинации типа obtain_wood_log; на втором — конвейеры, оркестрирующие несколько навыков первого уровня; на третьем — стратегические цепочки для достижения отдалённых целей.

2.2. Достижения Voyager

Voyager убедительно доказал несколько важных принципов. Во-первых, LLM способен генерировать корректный исполняемый код в контексте конкретного игрового API — это само по себе нетривиально. Во-вторых, библиотека навыков действительно растёт и переиспользуется: успешно написанный код для добычи дерева впоследствии вызывается при крафте верстака и производстве инструментов. В-третьих, цикл «предложи — сгенерируй — выполни — оцени» оказался достаточно надёжным для устойчивого прогресса по технологическому дереву Minecraft.

В сравнении с другими агентами 2023 года, включая ReAct и AutoGPT-подобные системы, Voyager демонстрировал значительно лучшую долгосрочную динамику: через 1600 итераций агент достигал уровней, недоступных для конкурентов даже с неограниченным числом попыток.

2.3. Критические ограничения Voyager

Вместе с тем Voyager обнажил класс проблем, характерных для систем lifelong learning без механизма рефакторинга. Эти проблемы носят не случайный, а системный характер — они вытекают из архитектурных решений системы.

2.3.1. Prompt bloat и деградация качества

По мере роста библиотеки навыков растёт сложность каждого нового промпта. Извлечённые из ChromaDB навыки-аналоги, история ошибок, логи выполнения и критика предыдущих попыток складываются в контекст, который после 50–100 итераций превышает 5000–6000 токенов. На этом уровне наблюдается устойчивое снижение качества генерации: модель начинает игнорировать инструкции, расположенные в ранних частях промпта, что ведёт к учащению синтаксических ошибок и неправильному использованию API.

2.3.2. Library bloat и семантический дрейф

Поскольку Voyager сохраняет в ChromaDB все успешные навыки без какой-либо политики удаления или дедупликации, библиотека неизбежно засоряется. Одна и та же функциональность оказывается представлена несколькими несовместимыми версиями: obtain_wood_log_v1, obtain_wood_log_v2, obtain_wood_log_v3 — каждая с отдельным эмбеддингом. Механизм семантического поиска не имеет способа определить, какая версия актуальна, и может вернуть устаревшую реализацию, написанную для предыдущей версии Minecraft API.

Со временем это ведёт к феномену семантического дрейфа: retrieval возвращает навыки, формально близкие к запросу по смыслу, но фактически несовместимые с текущим состоянием среды. Качество генерации деградирует даже при неизменном качестве самой LLM.

2.3.3. Каскадные отказы и отсутствие rollback

Voyager не отслеживает промежуточные состояния выполнения сложных стратегий. Если задача разбита на подзадачи A → B → C, и подзадача C завершилась неудачей (например, агент погиб в лаве), система регистрирует провал всей стратегии. Частичный успех (A и B были выполнены корректно) теряется. При трёх повторных попытках весь пайплайн запускается с нуля — вычислительные ресурсы и игровой прогресс растрачиваются впустую. Эта проблема принципиально усугубляется по мере роста сложности стратегий: при цепочке из десяти подзадач достаточно одного отказа на последнем шаге, чтобы обнулить 90% выполненной работы.

2.3.4. Парадокс lifelong learning

Совокупное действие описанных проблем порождает явление, которое можно назвать парадоксом lifelong learning: чем дольше работает система, тем медленнее и ненадёжнее она становится. В то время как человеческий мозг справляется с аналогичной проблемой через синаптический прунинг и консолидацию памяти во сне, Voyager обладает только пластичностью без механизма стабилизации. Библиотека навыков лишена аналога синаптического прунинга — она только растёт, никогда не чистясь.

В долгосрочных экспериментах наблюдался характерный паттерн: после 15–25 часов непрерывной работы показатель успешности задач падал с 60–80% до 25–35%, агент регрессировал к повторению примитивных задач, а агент учебного плана терял способность предлагать достижимые цели.

Эти ограничения не являются техническими дефектами реализации — они обнажают архитектурную пропасть: между накоплением кода и осмыслением знаний. Voyager умеет писать навыки, но не умеет о них думать.

3. TheoryCoder-2: автономное обучение domain-independent абстракций

Статья «Learning Abstractions for Hierarchical Planning in Program-Synthesis Agents» (Ahmed et al., 2026)^[2] предлагает решение, затрагивающее самую глубокую из проблем Voyager: отсутствие подлинных абстракций. Если Voyager хранит конкретный JavaScript-код для каждой задачи, TheoryCoder-2 учится выделять переносимые символические шаблоны — PDDL-операторы и предикаты, описывающие не конкретные действия в Minecraft, а универсальные структуры задач.

3.1. PDDL как язык абстракций

PDDL (Planning Domain Definition Language) — формальный язык для описания задач планирования, разработанный в области классического ИИ.^[3] Оператор PDDL описывает действие через его предусловия (что должно быть истинным, чтобы действие было применимо) и эффекты (что изменится после его применения). Примеры операторов, синтезируемых TheoryCoder-2:

• pickup(obj, loc): preconditions — агент в loc, obj в loc; effects — obj в инвентаре агента.
• moveontop(obj1, obj2): preconditions — obj1 и obj2 существуют; effects — obj1 поверх obj2.
• unlock(door, key): preconditions — агент держит key; effects — door открыта.
• acquire(resource, quantity): preconditions — ресурс доступен; effects — инвентарь содержит quantity единиц ресурса.

Критически важно: эти операторы не упоминают Minecraft, JavaScript или конкретный API. Они описывают структуру задачи в абстрактных терминах, применимых к любой среде с аналогичной механикой.

3.2. Механизм автономного синтеза абстракций

TheoryCoder-2 отличается от своего предшественника (оригинального TheoryCoder) тем, что отказывается от ручного задания абстракций экспертом. Вместо этого агент синтезирует PDDL-операторы самостоятельно через механизм in-context learning.

В ходе выполнения задач система собирает трассы: последовательности состояний до и после каждого действия, описанные на символическом языке. LLM анализирует эти трассы и предлагает операторы, объясняющие наблюдаемые переходы. Операторы проверяются на согласованность с трассами, уточняются через несколько итераций и добавляются в библиотеку абстракций.

Библиотека развивается через curriculum: агент начинает с простых задач, на которых синтезирует примитивные операторы, затем переходит к более сложным задачам, требующим композиции уже накопленных операторов. Новые операторы высокого уровня формируются как комбинации существующих — аналогично тому, как слова складываются в предложения.

3.3. Преимущества абстрактного слоя

3.3.1. Переносимость между средами

Главное и наиболее очевидное преимущество: PDDL-библиотека, накопленная в BabyAI, может быть применена в Minihack, Sokoban или Minecraft без переобучения. Достаточно написать тонкий слой «заземления» (grounding) — функции, сопоставляющие абстрактные операторы с конкретными вызовами API новой среды. Один «мозг» работает в любой игре с аналогичной структурой задач.

В экспериментах TheoryCoder-2 агент, накопивший библиотеку абстракций на одном наборе сред, показывал значительно более быстрое освоение новых сред по сравнению с базовыми агентами: снижение числа требуемых шагов в 3–8 раз на задачах, структурно схожих с ранее встречавшимися.

3.3.2. Ускоренное обучение в новых средах

Агент, вооружённый библиотекой абстракций, не открывает новый мир с нуля. Встречая незнакомую среду, он проводит этап «заземления»: проверяет, какие из известных операторов применимы, каким образом их прекондиции и эффекты соответствуют механике новой игры. Этот этап качественно короче, чем обучение с нуля.

Аналогия с человеческим познанием здесь очевидна: опытный игрок, впервые запускающий новую RPG, не изучает заново концепции «инвентаря», «экипировки», «урона» или «крафта» — он только уточняет конкретику их реализации в данной игре.

3.3.3. Решение задач, недоступных исполнительному слою

Это, пожалуй, наиболее глубокое из преимуществ абстракций. Исполнительный слой — код, непосредственно взаимодействующий с API игры — видит только локальную цель и текущий шаг. У него нет горизонта планирования: функция mine_diamond_ore не знает, что впоследствии добытый алмаз будет использован для крафта меча, который позволит победить конкретного босса, открывающего доступ к финальному уровню.

Абстрактный планировщик видит всю иерархию целей и строит многошаговые мосты: defeat_final_boss → acquire_diamond_sword → mine_diamonds → reach_deep_cave → craft_iron_pickaxe → … Без этого верхнего слоя агент физически не способен преследовать долгосрочные цели: исполнительные функции слепы к телеологии, они видят только непосредственную задачу.

3.3.4. Эффективность планирования

Планирование в пространстве PDDL-операторов несравнимо эффективнее, чем в пространстве низкоуровневых действий. Если в Minecraft каждый игровой тик предлагает сотни возможных действий, библиотека из тридцати высокоуровневых операторов сокращает пространство поиска на порядки. Классические планировщики типа Fast Downward работают в этом сжатом пространстве с гарантиями полноты и оптимальности, недостижимыми для LLM.

3.3.5. Интерпретируемость и отладка

PDDL-планы читаемы человеком. Инженер или исследователь может проследить, какая последовательность операторов была выбрана, на каком шаге она сломалась, какой оператор дал неверный эффект. Это качественно отличается от отладки нейросетевого агента, где объяснение конкретного решения принципиально затруднено.

3.3.6. Устойчивость к вариациям среды

Абстракции по определению игнорируют незначимые детали: конкретные координаты, случайные зёрна генерации мира, косметические вариации текстур, незначительные изменения API. Оператор pickup(obj, loc) остаётся работоспособным при обновлении Minecraft с версии 1.20 до 1.21, даже если внутренняя реализация подбора предмета изменилась — достаточно обновить grounding-функцию нижнего слоя.

3.4. Ограничения TheoryCoder-2

При всей мощи описанного подхода, TheoryCoder-2 имеет существенное ограничение, явно признаваемое авторами: система эффективна только в средах с дискретным пошаговым управлением или достаточно медленной динамикой. В реальном времени действие LLM, синтезирующей план, занимает секунды — неприемлемо для динамичных игровых жанров. Этот барьер становится отправной точкой для архитектурной эволюции, описываемой в разделе 5.

4. Evolving Programmatic Skill Networks: живой рефакторинг как тренировка

Статья «Evolving Programmatic Skill Networks» (Shi, Yuan, Liu, 2026)^[4] атакует другую фундаментальную проблему — деградацию библиотеки навыков. Авторы предлагают рассматривать набор программных навыков как аналог нейронной сети, где «веса» — это не числа, а функции, а «тренировка» — это символический рефакторинг, применяемый после каждого эпизода взаимодействия со средой.

4.1. Programmatic Skill Network как символическая нейросеть

Ключевая метафора работы: библиотека исполняемых навыков — это не просто база данных, это граф функций с зависимостями, весами зрелости и механизмом обновления, изоморфным механизмам обучения нейронных сетей. Вместо числовых весов у каждого узла-навыка есть: показатель успешности (success rate), показатель зрелости (maturity score), оценка сложности (complexity penalty) и оценка частоты переиспользования.

В экспериментах на Minecraft и Crafter авторы показывают, что агент, использующий PSN с онлайн-рефакторингом, сохраняет компактную и работоспособную библиотеку навыков неопределённо долго — в отличие от Voyager, библиотека которого деградирует через 15–25 часов.

4.2. Механизмы рефакторинга PSN

4.2.1. Trace-based Reflect: символический backpropagation

Когда задача завершается неудачей, PSN не просто регистрирует провал, как Voyager. Механизм Reflect анализирует трассу выполнения: последовательность вызовов навыков, промежуточные состояния, точку отказа. На основе этого анализа система локализует конкретный навык или операцию, ответственную за сбой, и предлагает целевое исправление.

Это аналог алгоритма обратного распространения ошибки (backpropagation) в нейронных сетях: градиент потерь передаётся назад по графу вычислений, указывая, какие именно параметры следует обновить. В PSN роль градиента играет трасса отказа, а роль параметров — функции навыков.

4.2.2. Maturity-aware gating: стабилизация зрелых навыков

Не все навыки должны меняться с одинаковой частотой. Навык с высоким maturity score (подтверждённый успехами во многих различных контекстах) изменяется редко и только при накоплении убедительных свидетельств необходимости изменения. Незрелый навык, напротив, может обновляться после каждого эпизода.

Этот механизм предотвращает катастрофическое забывание: стабильные, проверенные навыки не разрушаются случайными обновлениями, вызванными нетипичными сценариями. Аналог в нейросетях — механизмы Elastic Weight Consolidation (EWC) или Progressive Neural Networks, защищающие «важные» веса от переобучения.

4.2.3. Канонический структурный рефакторинг: пять правил

Центральная часть PSN — набор из пяти правил структурного рефакторинга, применяемых к библиотеке навыков на основе анализа паттернов использования:

• Параметрическая генерализация: если два навыка отличаются только константой (например, mine_3_iron и mine_5_iron), они заменяются одним параметрическим навыком mine(resource, quantity).
• Покрытие поведения: если тело навыка A содержит код, идентичный навыку B, A рефакторируется с вызовом B — устраняется дублирование кода.
• Извлечение общего подграфа: если несколько навыков содержат одинаковую подпоследовательность операций, она выносится в отдельный навык и вызывается из всех родительских.
• Сиблинговая специализация: если параметрический навык ведёт себя принципиально по-разному для разных аргументов, создаются специализированные версии для каждого существенно различного режима.
• Удаление дублирования: семантически эквивалентные навыки объединяются в один с лучшей реализацией; устаревшие версии помечаются как deprecated и удаляются из активной базы.

Каждое изменение проходит rollback-валидацию: система проверяет, что рефакторинг не ухудшил производительность на тестовом наборе задач, и откатывает изменение, если обнаружена регрессия.

4.3. Применение PSN к абстрактному слою

Критически важное наблюдение, которое обе статьи вместе подчёркивают, но не проговаривают явно: механизмы рефакторинга PSN необходимы не только для низкоуровневых навыков, но и для абстрактного слоя PDDL-операторов.

PDDL-библиотека TheoryCoder-2 страдает от тех же патологий, что и библиотека Voyager — только на уровень выше. Без рефакторинга она накапливает дублирующиеся операторы (acquire_iron и obtain_iron_ore, описывающие одно и то же), устаревшие операторы (написанные для более ранней версии понимания среды), параметрически необобщённые операторы (по одному для каждого типа ресурса вместо одного параметрического).

Рефакторинг абстрактного слоя отличается от рефакторинга исполнительного слоя по сложности, но не по природе: те же пять правил применяются к PDDL-операторам, только «кодом» здесь являются декларации прекондиций и эффектов, а не императивные функции. Maturity gating на абстрактном уровне особенно важен: зрелые операторы типа pickup или move_to должны стабилизироваться — их хаотическое изменение разрушило бы всё зависящее от них планирование.

4.4. Синтез: двухслойная архитектура с независимыми рефакторинг-движками

Объединение TheoryCoder-2 и PSN порождает архитектуру, в которой оба слоя поддерживаются в оптимальном состоянии через независимые, но координированные процессы рефакторинга.

Компонент	В PSN (низкий уровень)	В TheoryCoder-2 + рефакторинг (высокий уровень)
Кредитное назначение	Trace-based Reflect по трассе кода	Trace → blame конкретного PDDL-оператора
Эволюция	5 правил структурного рефакторинга	Те же 5 + правила для декларативных структур
Стабилизация	Maturity-aware gating	Maturity score per operator, выше порог изменения
Веса	success_rate + complexity + recency	success_rate + generality + composition_score
Версионирование	vN + rollback validation	Каждая абстракция имеет версию и diff-историю
Обучение	Онлайн, после каждого эпизода	Онлайн, после каждой задачи из curriculum

Исполнительный слой рефакторируется чаще и с более простыми правилами: его задача — обеспечивать стабильный интерфейс между абстрактными командами и конкретным API. Абстрактный слой рефакторируется реже, но глубже: здесь происходит настоящая «символическая нейроархитектурная эволюция».

5. Барьер реального времени и его архитектурные последствия

Описанная в предыдущих разделах архитектура — абстрактный мозг с PDDL-операторами поверх исполнительного слоя с живым рефакторингом — представляет собой значительный шаг вперёд относительно Voyager. Тем не менее она сохраняет фундаментальное ограничение: скорость реакции определяется скоростью инференса LLM, которая несовместима с требованиями динамичных игровых жанров.

5.1. Количественная оценка проблемы

Рассмотрим конкретные числа. Современный LLM среднего класса (7–13 миллиардов параметров) генерирует ответ за 1–5 секунд на типичном серверном оборудовании. Тяжёлые модели (70+ миллиардов параметров) — за 10–30 секунд. Voyager в экспериментах демонстрировал 30–60 секунд на полный цикл «задача — код — выполнение — оценка».

Для сравнения: в типичном MMORPG атака ближнего боя занимает 200–500 миллисекунд; паттерн атаки элитного врага, требующий специфической реакции (уклонение, блок, контратака), развёртывается за 300–800 миллисекунд; реакция на внезапную угрозу (появление группы врагов, критическое падение здоровья) должна быть произведена за 100–300 миллисекунд.

Разрыв составляет два-три порядка величины. Это не инженерная проблема, решаемая более быстрым железом: даже гипотетическое десятикратное ускорение инференса не закроет разрыв между секундами и миллисекундами при сложных рассуждениях.

5.2. Фундаментальный характер ограничения

Причина медлительности носит архитектурный характер. Трансформерная архитектура с механизмом внимания масштабируется квадратично по длине контекста. Чем сложнее задача рассуждения — чем длиннее необходимый контекст — тем медленнее работает модель. Простые рефлекторные реакции не требуют сложных рассуждений, но именно сложные рассуждения являются главной ценностью LLM в роли планировщика.

Таким образом, возникает дилемма: либо агент рассуждает (медленно, качественно), либо реагирует (быстро, примитивно). Эта дилемма прямо воспроизводит классическую проблему когнитивной науки, формализованную Дэниэлом Канеманом как противопоставление Системы 1 и Системы 2: быстрое интуитивное мышление против медленного аналитического.

6. Реактивно-делиберативная архитектура: синтез скорости и интеллекта

Решение, предлагаемое автором, состоит в явном архитектурном разделении быстрых реакций и медленных рассуждений — с механизмом координации между ними. Эта архитектура прямо воспроизводит двухсистемную модель Канемана на уровне программных компонентов.

6.1. Реактивный слой (Система 1)

Реактивный слой работает без LLM или с лёгкой дистиллированной моделью специального назначения. Его основу составляют заранее скомпилированные паттерны поведения, реализованные как конечные автоматы (FSM) или деревья поведения (Behavior Trees). Паттерны активируются по условным триггерам: низкий уровень здоровья, появление враждебного моба в радиусе N блоков, критическое исчерпание ресурса, обнаружение специфической механики атаки.

Ключевое свойство: реактивный слой не рассуждает. Он сопоставляет текущее состояние с набором предкомпилированных условий и мгновенно запускает соответствующий паттерн. Время реакции — миллисекунды, что соответствует требованиям динамичного боя.

Паттерны реактивного слоя не являются статичными: они создаются и обновляются делиберативным слоем по итогам анализа прошлых эпизодов. Реактивный слой также собирает детальные логи исполнения, которые впоследствии служат материалом для анализа и рефакторинга.

6.2. Делиберативный слой (Система 2)

Делиберативный слой включает полный стек: LLM + PDDL-планировщик + LangGraph + механизм рефакторинга PSN. Он активируется только в безопасные периоды: между боями, во время исследования, при подготовке к новой задаче, во время инвентаризации.

Задачи делиберативного слоя: анализ логов реактивного слоя и выявление паттернов ошибок; синтез новых или обновление существующих реактивных паттернов; высокоуровневое стратегическое планирование (что делать следующим, какие ресурсы нужны, какую цель преследовать); рефакторинг библиотеки навыков и абстракций.

Делиберативный слой является «директором» архитектуры: он ставит цели реактивному слою, анализирует его работу и постоянно его улучшает. Реактивный слой является «исполнителем»: он воплощает директивы делиберативного слоя в реальном времени.

6.3. Механизм координации

Координация между слоями осуществляется через несколько каналов. Во-первых, через разделяемое состояние: оба слоя читают из единого представления игрового состояния (инвентарь, позиция, здоровье, активные враги, текущие цели). Во-вторых, через очередь директив: делиберативный слой публикует высокоуровневые цели и скомпилированные паттерны; реактивный слой потребляет их по мере необходимости. В-третьих, через очередь логов: реактивный слой публикует детальные трассы выполнения; делиберативный слой потребляет их для анализа и обновления.

Важно, что взаимодействие асинхронно: делиберативный слой не блокирует реактивный. Агент может одновременно выполнять бой (реактивный слой) и, в фоновом режиме, анализировать прошлый бой и готовить обновлённую тактику (делиберативный слой).

6.4. Полная архитектурная схема

Рис. 1. Полная архитектура универсального реактивно-делиберативного агента

Abstract Brain (PDDL Library) ← Refactoring Engine (PSN)

↕

domain-independent operators Deliberative Layer (LLM + Fast Downward + LangGraph)

↕

compiled patterns + logs Reactive Layer (FSM / Behavior Trees, no LLM)

↕

raw API calls Game Environment / API

6.5. Как архитектура решает проблемы Voyager

Проблема Voyager	Решение в гибридной архитектуре
Prompt bloat	Абстракции сжимают контекст: 30 операторов вместо 300 навыков; рефакторинг удаляет дубли
Library bloat	PSN-рефакторинг: deduplication, versioning, deprecation на обоих слоях
Cascading failures	PDDL-план с явными прекондициями: сбой диагностируется на конкретном операторе; rollback-валидация
Semantic drift	Maturity gating + версионирование: устаревшие абстракции помечаются и заменяются
Catastrophic forgetting	Стабильные абстракции защищены maturity gating; PSN сохраняет компактность неопределённо долго
Медлительность реакции	Реактивный слой: FSM без LLM, миллисекунды реакции в динамичном бою
Привязка к домену	Domain-independent PDDL + тонкий grounding: один мозг для любой среды
Отсутствие стратегии	Делиберативный слой: PDDL-планировщик строит длинные мосты к отдалённым целям

7. Эволюция системы: от Voyager к универсальному агенту

Описанную эволюцию удобно представить как серию последовательных шагов, каждый из которых решает одну или несколько критических проблем предыдущего поколения.

Поколение	Ключевые возможности	Критическая проблема	Год
LLM-агенты (ReAct, AutoGPT)	Гибкость, генерация текста	Нет памяти, нет исполнения, нет персистентности	2022–2023
Voyager	Генерация кода, lifelong learning, библиотека навыков	Library bloat, prompt bloat, cascading failures, регресс	2023
Odyssey (MineMA)	Стабильность, curated library, fine-tuned LLM	Привязка к Minecraft, нет переноса, нет эволюции	2024
TheoryCoder-2	Domain-independent PDDL, перенос между средами, иерархическое планирование	Медлительность LLM, только пошаговые игры	2026
PSN (Evolving)	Живой рефакторинг, maturity gating, компактная библиотека	Нет абстрактного слоя, нет переноса	2026
Гибридная арх. (цель)	Реактивный + делиберативный слои, PDDL + PSN, real-time + стратегия	Требует сложной реализации	2026+

Каждый шаг этой эволюции является не просто инженерным улучшением, но концептуальным сдвигом в понимании того, что значит «учиться». Voyager учит хранить код. TheoryCoder-2 учит думать категориями. PSN учит не засорять собственный разум. Гибридная архитектура учит действовать в реальном времени, не теряя стратегического горизонта.

8. Открытые вопросы и направления будущих исследований

Предложенная архитектура, при всей её концептуальной полноте, оставляет ряд открытых исследовательских вопросов, каждый из которых представляет самостоятельный предмет будущих работ.

8.1. Критерий зрелости абстракции

Механизм maturity gating предполагает числовую оценку зрелости каждого оператора или навыка. Конкретные формулы зрелости, предлагаемые в PSN, были разработаны для низкоуровневых программных навыков в Minecraft. Остаётся открытым вопрос: как следует считать зрелость абстрактных PDDL-операторов? Показатель успешности (success rate) работает как для навыков, так и для операторов. Однако показатель обобщаемости (generality) — насколько оператор применим в разных контекстах — требует специфического определения для декларативных структур. Аналогично, оценка композиционности (composition score) — насколько часто оператор входит в планы для разнообразных задач — важна для абстракций, но не имела аналога в исходной PSN.

8.2. Проблема преждевременной стабилизации

Maturity gating защищает стабильные абстракции от разрушения. Однако он также создаёт риск преждевременной стабилизации: оператор, показавший высокий success rate на ограниченном наборе задач, может быть ошибочно признан зрелым и защищён от обновлений — тогда как он содержит систематическую ошибку, проявляющуюся только в специфических сценариях.

Решение этой проблемы требует механизма активного тестирования: периодического запуска зрелых абстракций на разнообразных challenge-задачах, специально подобранных для выявления граничных случаев. Это аналог практики adversarial testing в разработке программного обеспечения, применённой к системам lifelong learning.

8.3. Координация рефакторинга между слоями

В предложенной архитектуре абстрактный и исполнительный слои рефакторируются независимо. Однако они не изолированы: изменение абстрактного оператора может потребовать обновления всех grounding-функций, опирающихся на него; изменение низкоуровневого навыка может нарушить прекондиции абстракций, вызывающих его.

Необходим механизм пропагации изменений через граф зависимостей — аналог системы управления зависимостями в современной разработке программного обеспечения (dependency graph). Его разработка представляет нетривиальную инженерную и исследовательскую задачу.

8.4. Перенос на принципиально новые жанры

Эксперименты TheoryCoder-2 демонстрируют перенос между средами с аналогичной структурой задач: BabyAI, Minihack и Sokoban разделяют фундаментальные паттерны навигации и манипуляции объектами. Вопрос о переносе на принципиально иные жанры — стратегии реального времени, симуляторы вождения, процедурные рогалики с уникальными механиками — остаётся открытым.

Предположительно, перенос будет эффективным там, где новая среда разделяет структурные паттерны с уже знакомыми (например, крафт в любой survival-игре изоморфен крафту в Minecraft). Там, где структура принципиально нова (например, ресурсное микроуправление в RTS), потребуется синтез новых абстракций практически с нуля — хотя и с меньшими затратами, чем без существующей библиотеки.

9. Заключение

Данная статья проследила эволюцию автономных игровых агентов от фундаментальных ограничений чисто нейросетевых и чисто алгоритмических подходов до синтетической архитектуры, сочетающей символическое планирование, живой рефакторинг и реактивную скорость.

Voyager, при всех своих ограничениях, сыграл незаменимую роль: он доказал принципиальную возможность lifelong learning через генерацию кода и обнажил конкретные архитектурные пропасти, которые необходимо преодолеть. TheoryCoder-2 и Evolving Programmatic Skill Networks предлагают два взаимодополняющих моста через эти пропасти: первый — через обучение переносимым абстракциям, второй — через онлайн-рефакторинг библиотеки навыков.

Их синтез порождает архитектуру, в которой один абстрактный мозг — библиотека PDDL-операторов, поддерживаемая в актуальном состоянии символическим рефакторингом, — обеспечивает высокоуровневое планирование для любой игровой среды через тонкий слой заземления. Добавление реактивного слоя без LLM устраняет последнее ограничение — скоростное — и открывает применение системы в динамичных жанрах.

Если Voyager — это агент, умеющий писать код, то архитектура, описанная в данной работе, — это агент, умеющий думать категориями, чинить собственный разум и действовать быстрее мысли. Расстояние между этими двумя описаниями — и есть измеримый прогресс последних трёх лет в области автономных игровых агентов.

Список литературы

[1] Wang, G., Xie, Y., Jiang, Y., et al. Voyager: An Open-Ended Embodied Agent with Large Language Models. arXiv preprint arXiv:2305.16291, 2023. https://arxiv.org/abs/2305.16291

[2] Ahmed, Z., et al. Learning Abstractions for Hierarchical Planning in Program-Synthesis Agents (TheoryCoder-2). arXiv preprint arXiv:2602.00929, 2026. https://arxiv.org/abs/2602.00929

[3] McDermott, D., Ghallab, M., et al. PDDL — The Planning Domain Definition Language. Technical Report CVC TR-98-003/DCS TR-1165, Yale Center for Computational Vision and Control, 1998.

[4] Shi, H., Yuan, X., Liu, B. Evolving Programmatic Skill Networks. arXiv preprint arXiv:2601.03509, 2026. https://arxiv.org/abs/2601.03509

[5] Kahneman, D. Thinking, Fast and Slow. Farrar, Straus and Giroux, 2011.

[6] Zhu, X., et al. Odyssey: Empowering Minecraft Agents with Open-World Skills. arXiv preprint, 2024. https://github.com/zju-vipa/Odyssey

[7] Kirkpatrick, J., et al. Overcoming catastrophic forgetting in neural networks (Elastic Weight Consolidation). Proceedings of the National Academy of Sciences, 114(13), 2017.

[8] Dawson, J., et al. Awesome Minecraft Agent: A Survey of Autonomous Agents in Minecraft. GitHub repository, 2024. https://github.com/dawn0815/Awesome-Minecraft-Agent