TL;DR
MazeRunner — система из трёх ролей-агентов (Стратег, Исполнитель, Ревьюер), которые работают по кругу и делятся общей памятью задач и найденных зацепок. Стратег решает, что делать дальше, Исполнитель делает и приносит результат, а отдельный Ревьюер занимается только разбором неудач — не продолжает работу, а копается в причине провала.
Главная находка: когда LLM-агент долго работает над сложной задачей с множеством возможных путей, он застревает на одной неудачной ветке. После провала он не переключается на альтернативу, а повторяет попытки заново — авторы называют это "глубокой ямой" (depth-first trap). Хуже того, модель часто неправильно определяет причину провала — связывает её с далёким прошлым шагом, а не с реальной проблемой, и из-за этой ошибки бросает рабочий путь, который на самом деле был верным.
Метод решает это разделением функций: пока одна роль ("Исполнитель") продолжает пробовать, отдельная роль ("Ревьюер") специально анализирует, почему именно не получилось, не смешивая диагностику с попытками продолжить. А вся структура задач и найденных зацепок хранится отдельно от диалога — как внешняя таблица, а не в "голове" модели — чтобы важная находка с 50-го шага не потерялась к 90-му.
Схема метода
ШАГ 1 (Стратег): Разбивает общую цель на задачи → обновляет граф задач (что сделано, что в очереди, какие ветки открылись)
ШАГ 2 (Исполнитель): Берёт одну конкретную задачу, выполняет → записывает результат и новые зацепки в общую память
ШАГ 3 (Ревьюер) — включается ТОЛЬКО при провале: Анализирует именно причину неудачи (не продолжает работу) → выдаёт диагноз и рекомендацию: повторить иначе, откатиться, переключиться на другую ветку
Цикл повторяется. Задачи и зацепки хранятся в отдельной "таблице состояния", не растворяются в общем диалоге.
Все три роли — это один и тот же LLM, который последовательно играет разные функции. В реальной системе это отдельные запросы с разным контекстом; в чате это можно эмулировать одним длинным промптом с явным разделением ролей.
Пример применения
Задача: Вы предприниматель, продажи в интернет-магазине упали, и непонятно почему. Есть пять гипотез: реклама перестала работать, цена неконкурентна, сайт тормозит, конкурент демпингует, сезонный спад. Проверка каждой гипотезы требует нескольких шагов, и есть риск залипнуть на одной, пока остальные важнее.
Промпт:
Ты работаешь в трёх ролях по очереди: Стратег, Исполнитель, Ревьюер.
ЦЕЛЬ: найти реальную причину падения продаж в интернет-магазине {название}.
СТРАТЕГ: разбей цель на проверяемые гипотезы-задачи. Веди список:
[Задача] — [статус: не начата/в работе/провалена/подтверждена] — [зависит от]
ИСПОЛНИТЕЛЬ: возьми одну задачу из списка, распиши что нужно проверить и какие данные/шаги нужны. Зафиксируй результат и любые новые "зацепки" — детали, которые могут быть важны позже, даже если сейчас не относятся к текущей гипотезе.
РЕВЬЮЕР: если задача провалилась (гипотеза не подтвердилась) — не переходи сразу к следующей. Сначала разбери:
1) Почему конкретно не подтвердилось (данные? неверная методика проверки? гипотеза неверна?)
2) Есть ли зацепки из провала, которые указывают на другую гипотезу
3) Рекомендация: закрыть гипотезу / проверить иначе / переключиться на другую
Начни с составления списка задач у Стратега. Данные о магазине: {вставь метрики, что знаешь}.
Результат: Модель сначала выдаст таблицу из 5 гипотез со статусами. Затем начнёт проверять первую — например, рекламу. Если гипотеза не подтвердится, вместо того чтобы просто написать "гипотеза не верна, дальше", отдельным блоком разберёт: почему не подтвердилась, какие детали заметила по пути (например, "трафик стабилен, но конверсия упала именно на странице оплаты") — и это станет новой зацепкой для проверки гипотезы про сайт. Весь список гипотез и статусов останется видимым на протяжении всего разговора, вместо того чтобы забыться через 10 сообщений.
Почему это работает
LLM плохо держит длинную цепочку причинно-следственных связей в контексте — чем дальше назад находка, тем выше риск, что модель её "забудет" или свяжет провал с неправильным шагом. Это не потому что модель "глупая" — просто в потоке диалога всё сливается в общий текст, и важная деталь с 30-го сообщения теряется среди остального шума.
При этом LLM хорошо умеет играть отдельную, узкую роль, если её явно попросить сфокусироваться только на одной задаче — например, только на диагностике, без отвлечения на "что делать дальше". Разделение ролей заставляет модель не смешивать два разных типа мышления: "давай попробуем ещё раз" и "давай разберёмся, что пошло не так" — это разные режимы, и смешивание их в одном потоке ведёт к зацикливанию.
Рычаги для адаптации: - Количество ролей можно урезать до двух (Исполнитель + Ревьюер), если задача проще - Таблицу задач/зацепок можно вести вручную в отдельном сообщении и просить модель обновлять её каждый раунд — так она не потеряется в длинном диалоге - Критерий "провал" можно заменить под свою задачу — не только "не сработало", но и "результат неубедительный", "данных недостаточно"
Шаблон промпта
Ты работаешь в трёх ролях по очереди: Стратег, Исполнитель, Ревьюер.
ЦЕЛЬ: {опиши конечную цель}
СТРАТЕГ: разбей цель на задачи/гипотезы. Веди таблицу:
[Задача] — [статус] — [зависит от]
ИСПОЛНИТЕЛЬ: возьми задачу из очереди, выполни/проверь её. Зафиксируй результат и любые побочные "зацепки" — детали, которые могут быть полезны позже.
РЕВЬЮЕР (включается при провале задачи): не продолжай сразу дальше. Разбери:
1) Почему именно не получилось
2) Какие зацепки из этого провала стоит использовать
3) Рекомендация: повторить иначе / переключиться на другую ветку / отложить
Данные: {вставь то, что уже известно}
🚀 Быстрый старт — вставь в чат:
Вот шаблон MazeRunner (Стратег-Исполнитель-Ревьюер). Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про конечную цель и что уже известно — потому что без этого Стратег не сможет разбить задачу на проверяемые шаги. Она возьмёт паттерн трёх ролей и таблицы состояния и подстроит под вашу ситуацию.
Ограничения
⚠️ Нет настоящей персистентной памяти в чате: в исследовании таблица задач и улик хранится во внешней системе отдельно от диалога модели. В обычном чате это придётся эмулировать вручную — просить модель каждый раз выводить обновлённую таблицу, иначе она всё равно может "потерять" зацепку через много сообщений.
⚠️ Избыточно для простых задач: если у задачи один понятный путь без веток и провалов, три роли и таблица состояния только замедлят работу и растратят токены.
⚠️ Оригинальная система требует инфраструктуру: сама система MazeRunner работает с реальными инструментами (сканирование сети, выполнение команд) через код — это неприменимо напрямую в чате. Извлекать стоит только принцип оркестрации ролей, не саму систему.
Ресурсы
MazeRunner: Nonlinear Task and Clue Orchestration for LLM-driven Black-Box Automated Penetration Testing. Zhenyuan Li, Yi Jiang, Junjie Cheng, Yaokun Li, Jing Qiu, Shouling Ji — Zhejiang University, Guangzhou University. Sci China Inf Sci (на рецензии).