TL;DR
Когда LLM выполняет длинную, многошаговую задачу — будь то веб-навигация, анализ или создание сложного документа — качество финального результата почти целиком определяется качеством планирования, а не точностью выполнения отдельных шагов. Это не интуиция — это эмпирический факт, установленный в ходе контролируемых экспериментов: масштабирование роли планировщика даёт такой же прирост, что и масштабирование всей системы целиком.
Типичная проблема: когда просишь LLM сделать что-то сложное одним запросом, она пытается одновременно держать в голове стратегию, выполнять конкретные действия и отслеживать прогресс. Это создаёт конфликт целей внутри одного ответа — модель либо теряет общую цель (делает правильные шаги, но не туда), либо теряет точность шагов (понимает куда идти, но ошибается в деталях).
Решение — явно разделить три роли в работе с LLM: планировщик (стратегия и подзадачи), актор (выполнение конкретного шага), менеджер памяти (отслеживание прогресса). Самый важный вывод исследования: роль планировщика заслуживает абсолютного большинства ваших усилий при составлении промпта — актор и память справляются даже при минимальных инструкциях.
Схема метода
Один цикл выполняется в одном или нескольких запросах:
ШАГ 1: ПЛАНИРОВЩИК
Получает: задача + текущий контекст + накопленная память
Делает: decompose задачи на подзадачи, выдаёт текущий фокус-шаг
Выводит: ПЛАН + ТЕКУЩИЙ ПОДЗАДАЧА
ШАГ 2: АКТОР
Получает: текущую подзадачу от планировщика
Делает: выполняет один конкретный шаг
Выводит: РЕЗУЛЬТАТ + обновлённое состояние
ШАГ 3: МЕНЕДЖЕР ПАМЯТИ
Получает: историю шагов + новый результат
Делает: фиксирует что сделано, что изменилось в понимании задачи
Выводит: ОБНОВЛЁННЫЙ КОНТЕКСТ → возвращается к планировщику
↺ Цикл повторяется до завершения задачи
Все три шага можно выполнять в одном чате, инструктируя модель явно переключаться между ролями. Или разбить на три отдельных запроса — особенно полезно для задач, где нужны реальные паузы и проверка результата.
Пример применения
Задача: Максим хочет написать экспертную колонку для VC.ru о том, почему большинство российских стартапов проваливают выход на B2B-рынок. У него есть 5 разрозненных наблюдений из опыта, нет структуры, нет понимания с чего начать.
Промпт:
Буду работать с тобой в три роли. Переключайся между ними явно,
не смешивай в одном блоке.
═══ РОЛЬ 1: ПЛАНИРОВЩИК ═══
Проанализируй задачу и составь детальный план статьи.
Раздели на конкретные смысловые блоки с логикой переходов.
Объясни, какую главную мысль должен унести читатель после каждого блока.
Заверши раздел словами: "ПЛАН ГОТОВ. Подзадача для Актора: [что делать первым]"
═══ РОЛЬ 2: АКТОР ═══
Получив подзадачу — выполни только её. Один блок, полностью.
Не планируй вперёд, не отвлекайся на другие разделы.
Заверши словами: "ШАГ ВЫПОЛНЕН. Передаю в Память."
═══ РОЛЬ 3: МЕНЕДЖЕР ПАМЯТИ ═══
Зафикисируй: что написано, что ещё осталось по плану,
изменилось ли понимание задачи после написания этого блока.
Заверши словами: "ПАМЯТЬ ОБНОВЛЕНА. Возвращаю Планировщику."
Затем Планировщик уточняет план (если нужно) → Актор делает следующий шаг.
Задача: написать экспертную колонку для VC.ru "Почему российские B2B-стартапы
не выходят на корпоративный рынок". Мои наблюдения:
1. Основатели боятся длинных циклов сделок и кончают деньги
2. Продукт делается под SMB, а продаётся как enterprise
3. Нет пилотных программ — сразу хотят годовой контракт
4. Игнорируют внутренних чемпионов (людей внутри клиента)
5. Ценообразование скопировано с SaaS-метрик, а не с ценности для бизнеса
Результат:
Модель покажет работу тремя явными блоками на каждом цикле. Планировщик разберёт 5 наблюдений, найдёт между ними логику и предложит структуру с тезисом и нарративом. Актор напишет первый раздел сфокусированно, не размазываясь. Менеджер памяти зафиксирует что сделано и обновит фокус для следующего шага. На выходе — последовательно написанная, логически связная статья, где каждый раздел знает своё место.
Почему это работает
Слабость LLM: модель генерирует текст последовательно, слева направо. Когда ей нужно одновременно держать стратегию и выполнять детали — она начинает «усреднять» между двумя целями. Результат: ни рыба, ни мясо. Это не баг, это архитектурная особенность — у модели нет отдельного «стратегического центра».
Сильная сторона LLM: модель отлично следует чётким инструкциям, когда у неё одна конкретная задача в фокусе. Попросить «напиши только этот абзац, про это, вот так» — намного эффективнее, чем «напиши всю статью хорошо».
Как метод использует это: разделение ролей убирает конфликт целей. Планировщик думает только про стратегию. Актор выполняет только один шаг. Менеджер памяти только фиксирует. Каждая роль получает узкую, однозначную задачу — и выполняет её хорошо.
Главный рычаг управления: вкладывайте 90% усилий в инструкцию для планировщика. Насколько детально он разбивает задачу, насколько ясно формулирует подзадачи — это определяет качество всего остального. Актора достаточно инструктировать минимально («выполни только эту подзадачу»). Память вообще работает почти без специальных инструкций.
Дополнительные рычаги:
- Количество циклов → для простых задач один цикл; для сложных — позвольте планировщику перепланировать после каждого шага
- Детализация планировщика → чем конкретнее формулировки подзадач, тем точнее работает актор
- Явные маркеры переключения ("ПЛАН ГОТОВ", "ШАГ ВЫПОЛНЕН") → убирают размытость, модель чётче переключается между режимами
- Память через резюме → попросите менеджер памяти писать в формате «сделано / осталось / изменения в понимании» — это даёт планировщику нужный контекст без лишнего шума
Шаблон промпта
Работай в трёх ролях по очереди. Каждую роль — отдельным блоком с заголовком.
═══ ПЛАНИРОВЩИК ═══
Задача: {задача}
Контекст и ограничения: {что важно учесть}
Текущая память: {что уже сделано / пусто, если начало}
Составь или обнови план. Выдели конкретную подзадачу для следующего шага.
Заверши: "ПОДЗАДАЧА: [формулировка]"
═══ АКТОР ═══
Выполни только подзадачу от Планировщика. Не выходи за её рамки.
Заверши: "РЕЗУЛЬТАТ: [что сделано]"
═══ МЕНЕДЖЕР ПАМЯТИ ═══
Зафиксируй:
— Что выполнено
— Что осталось по плану
— Что изменилось в понимании задачи
Заверши: "ОБНОВЛЁННЫЙ КОНТЕКСТ: [краткое резюме для Планировщика]"
Затем снова — Планировщик, с обновлённым контекстом.
Повторяй до завершения задачи.
Что подставлять:
- {задача} — конкретная задача целиком, со всеми деталями
- {что важно учесть} — ограничения, формат, аудитория, тон
- {что уже сделано} — при первом запуске пишите «начинаем с нуля»
🚀 Быстрый старт — вставь в чат:
Вот шаблон трёхролевого подхода к сложным задачам (Planner-Actor-Memory).
Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про задачу, ограничения и желаемый формат результата — потому что без этого планировщик не сможет правильно декомпозировать задачу. Она возьмёт паттерн из шаблона и адаптирует под твой контекст.
Ограничения
⚠️ Для простых задач не нужен: Если задача выполняется за 1-2 шага — три роли только перегрузят ответ. Метод раскрывается на задачах с 5+ этапами и нелинейной логикой.
⚠️ Память деградирует при длинных чатах: Менеджер памяти ограничен контекстным окном. При очень длинных сессиях накопленный контекст вытесняет начальные инструкции. Решение — периодически просить модель сжать память до ключевых тезисов.
⚠️ Планировщик может ошибиться в декомпозиции: Если задача плохо описана, планировщик разобьёт её неверно — и актор будет чётко выполнять неправильный план. Инвестируйте в описание задачи для планировщика, не жалейте деталей.
⚠️ Полная система требует кода: В исследовании описана архитектура с оркестрацией через API, RL-дообучением планировщика и векторной памятью. В чате вы симулируете принцип, не воспроизводите систему — и это уже даёт значительный прирост качества.
Ресурсы
Planner Matters! An Efficient and Unbalanced Multi-agent Collaboration Framework for Long-horizon Planning Wenyi Wu, Sibo Zhu, Kun Zhou, Biwei Huang — University of California, San Diego GitHub · Project page