Что это? Метод **MazeRunner** (Zhenyuan Li et al., 2026) разделяет работу LLM на * **Стратег** – разбивает цель в задачи, ведёт граф задач и зависимостей; * **Исполнитель** – берёт одну задачу из очереди, выполняет её и фиксирует результат + новые «зацепки» (детали, которые могут пригодиться позже); * **Ревьюер** – активируется только при провале задачи. Он не пытается продолжить работу, а разбирает *почему* задача провалена, выделяет полезные зацепки и даёт рекомендацию: «повторить иначе», «переключиться на другую ветку» или «закрыть гипотезу». Ключевая идея – **разделение функций**. LLM не смешивает попытки продолжения с диагностикой, что устраняет зацикливание в глубокой яме (depth‑first trap) и сохраняет важные находки в отдельной таблице состояния.

Как это работает

1. **Стратег** * Получает конечную цель + известные данные. * Формирует таблицу задач: ``` [Задача] — [статус: не начата/в работе/провалена/подтверждена] — [зависит от] ``` 2. **Исполнитель** * Берёт задачу из очереди, описывает шаги проверки и необходимые данные. * После выполнения обновляет таблицу: ставит статус «выполнено» или «провалено», добавляет новые зацепки. 3. **Ревьюер** (только при провале) * Анализирует причину провала, выделяет полезные детали и формулирует рекомендацию. * Таблица остаётся неизменной до следующего шага Стратега/Исполнителя. 4. Цикл повторяется: Стратег может добавить новые задачи, Исполнитель – продолжать работу, Ревьюер – уточнять причины провалов.

Пример применения

**Сценарий:** > *Интернет‑магазин упал в продажах. Пять гипотез: реклама не работает, цена неконкурентна, сайт тормозит, конкурент демпингует, сезонный спад.* ```text Шаг 1 – Стратег: Таблица задач (статус «не начата»): - Проверить эффективность рекламы - Сравнить цены с конкурентами - Оценить скорость сайта - Анализ цен конкурентов - Проанализировать сезонные тренды Шаг 2 – Исполнитель (реклама): Провёл анализ CTR и конверсии → результат: трафик стабилен, но конверсия упала на странице оплаты. Записал зацепку: «плохая UX на оплате». Шаг 3 – Ревьюер (провал рекламы? Нет – подтверждена частичная причина): Рекомендация: проверить гипотезу о сайте. Шаг 4 – Исполнитель (сайт): Тестировал скорость → время загрузки >5 s, выявил медленный JS‑bundle. Записал зацепку: «JS‑bundle слишком большой». И так далее… ```

Шаблон промпта для чата

```text Ты работаешь в трёх ролях по очереди: Стратег, Исполнитель, Ревьюер. ЦЕЛЬ: {опиши конечную цель} СТРАТЕГ: разбей цель на задачи/гипотезы. Веди таблицу: [Задача] — [статус] — [зависит от] ИСПОЛНИТЕЛЬ: возьми задачу из очереди, выполни её. Зафиксируй результат и любые побочные «зацепки». РЕВЬЮЕР (только при провале): разберись: 1) Почему не получилось 2) Какие зацепки использовать 3) Рекомендация: повторить иначе / переключиться на другую ветку / отложить Данные: {вставь то, что уже известно} ```

Границы применимости

| Когда полезно | Когда избыточно |

| Сложные задачи с множеством веток и возможными провалами. | Прямолинейные задачи без альтернативных путей. | | Необходимость сохранять важные находки в долгосрочной памяти. | Ограниченные токены, где каждый запрос ценен. | | Нужно систематически анализировать причины ошибок. | Когда модель уже имеет хорошую память контекста (модели 4‑5 B). |

Ограничения

* **Память чата** – таблица задач и зацепок должна храниться вне диалога (в отдельном сообщении или внешней базе), иначе она «забудет» важные детали. * **Инфраструктура** – оригинальная система использует реальные инструменты (сканирование, команды). В чате можно только симулировать логику. * **Токены** – три роли и таблица увеличивают расход токенов; для простых задач лучше использовать 2‑ролевую схему.

Ключевые выводы

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