TL;DR
Исследователи протестировали четыре способа сообщить AI-агенту, на каком этапе находится многошаговая задача — от простого упоминания в переписке до жёсткой блокировки неправильных действий — и обнаружили, что чем активнее передан статус, тем надёжнее агент себя ведёт. Просто «сказать» модели факт — слабо. «Приказать» модели, что делать прямо сейчас — сильно.
Главная боль: даже когда модели показывают точный, всегда актуальный чеклист статусов ("шаг 3: готово", "шаг 5: заблокирован"), она всё равно ошибается — повторно выполняет уже сделанный шаг, если пользователь просто снова упомянул его с новым номером заказа, без явного "переделай". Ещё более неожиданно: если попросить модель самой вести свой статус-леджер (без всякой проверки правильности) — она справляется лучше, чем когда ей показывают точный внешний чеклист.
Метод — "лестница" из четырёх уровней связи состояния с поведением: (1) статус только в переписке, (2) точный чеклист показан, (3) перед каждым действием — прямая команда типа "этот шаг ГОТОВ — не переделывай", (4) блокировка неправильных действий на уровне инструмента. Прыжок с уровня 2 на уровень 3 — с показа на приказ — даёт самый большой скачок надёжности, и это чистый приём промптинга, без кода.
Схема метода
УРОВЕНЬ 1 (слабый): Статус живёт только в истории чата → модель часто путает "упомянул" с "сделай заново"
УРОВЕНЬ 2: Точный чеклист статусов вставляется в каждое сообщение → лучше, но ошибки остаются
УРОВЕНЬ 3 (применим в чате): Перед действием — явная команда на основе статуса:
"шаг X: ГОТОВО — не переделывай" / "шаг Y: ЗАБЛОКИРОВАН — не делай, назови что нужно сначала" / "шаг Z: ДОСТУПЕН — делай сейчас"
→ ошибки резко падают
УРОВЕНЬ 4 (нужен код/инструмент): Жёсткая блокировка неправильного действия на уровне системы → почти без ошибок, но требует внешнего механизма
ДОПОЛНИТЕЛЬНО (чистый чат-приём): Самоучёт — просишь модель САМУ вести и выводить статус-леджер каждый ход, без проверки → обходит даже точный внешний чеклист
Пример применения
Задача: Ты ведёшь запуск товара на Wildberries через AI-ассистента как виртуального проектного менеджера. Этапы: заказать образцы у фабрики → согласовать договор → снять карточки товара → загрузить на маркетплейс → запустить рекламу. Переписка идёт несколько дней, вразнобой: ты то спрашиваешь про уже готовый этап, то отменяешь шаг, то просишь переделать.
Промпт:
Ты — мой проектный ассистент по запуску товара на Wildberries. Веди статус этапов:
1. Заказать образцы у фабрики [код завершения: О-101]
2. Согласовать договор с фабрикой [О-102] (требует: 1)
3. Снять карточки товара [О-103] (требует: 2)
4. Загрузить карточки на Wildberries [О-104] (требует: 3)
5. Запустить рекламу [О-105] (требует: 4)
Правила:
- Каждый этап выполняется ОДИН раз.
- Если я снова упоминаю уже сделанный этап без слова "переделай" — просто подтверди, что он готов, не выполняй заново.
- Если этап заблокирован (не готовы условия) — не выполняй, объясни что нужно сделать сначала.
- Если этап отменён — откажись выполнять, даже если я снова о нём заговорю.
Перед тем как выполнить или отклонить любое моё сообщение, сначала явно укажи одной строкой:
СТАТУС: {этап} — {ДОСТУПЕН, выполняю / УЖЕ ГОТОВО, не переделываю / ЗАБЛОКИРОВАН, жду {что} / ОТМЕНЁН, отказываюсь}
После статуса — выполни или откажи, и в конце всегда выводи свой леджер:
ЛЕДЖЕР:
1: ..., 2: ..., 3: ..., 4: ..., 5: ...
Моё сообщение: "Слушай, разберись с карточками товара, вот новый заказ №4521"
Результат: Модель сначала выдаст строку СТАТУС, где явно скажет — доступен этап или уже сделан. Если этап уже был выполнен раньше (даже с другим номером заказа), она подтвердит это и не будет выполнять заново — потому что команда явно требует сначала произнести статус, а не сразу действовать. В конце — обновлённый леджер всех пяти этапов, который сама модель ведёт и на который будет ориентироваться в следующих сообщениях.
Почему это работает
Слабость LLM: модель плохо связывает увиденную информацию с нужным поведением. Увидеть в чеклисте "шаг 3: готово" и отказаться от нового действия, когда пользователь снова просит про этот же шаг — это два разных когнитивных шага, и модель часто спотыкается между ними. Она читает статус, но не обязательно делает из него правильный вывод про то, что делать прямо сейчас.
Сильная сторона LLM: она отлично выполняет прямые команды. Когда вместо описания статуса ей говорят "не переделывай" или "делай сейчас" — это уже готовый вывод, а не задача сделать вывод самой. Меньше шансов на ошибку интерпретации.
Метод убирает промежуточный шаг рассуждения: вместо "вот факт, сделай правильный вывод" — сразу "вот вывод, действуй". А самоучёт работает похоже: когда модель сама генерирует и фиксирует статус, она как бы "берёт на себя обязательство" перед этим статусом — и в следующий раз с большей вероятностью его соблюдает, чем когда статус просто дают ей извне.
Рычаг управления: можно менять формулировку команды под задачу — "ДОСТУПЕН/ГОТОВО/ЗАБЛОКИРОВАН" замени на свои категории статуса (например, "требует согласования", "в работе", "просрочено"). Убери требование выводить леджер, если не хочешь загромождать ответ — но тогда точность просядет.
Шаблон промпта
Ты — мой ассистент по управлению проектом «{название проекта}». Веди статус этапов:
{список этапов с зависимостями и кодами завершения}
Правила:
- Каждый этап выполняется {сколько раз} раз.
- Если я снова упоминаю уже сделанный этап без явного "переделай" — подтверди готовность, не выполняй заново.
- Если этап заблокирован — не выполняй, объясни что нужно сделать сначала.
- Если этап отменён — откажись выполнять.
Перед действием сначала укажи одной строкой:
СТАТУС: {этап} — {ДОСТУПЕН / УЖЕ ГОТОВО / ЗАБЛОКИРОВАН / ОТМЕНЁН}
Затем выполни или откажи. В конце выведи свой леджер по всем этапам.
Моё сообщение: {запрос}
Плейсхолдеры: {название проекта} — суть задачи; {список этапов} — твои шаги с тем, что от чего зависит; {сколько раз} — обычно "один"; {запрос} — текущее сообщение пользователя.
🚀 Быстрый старт — вставь в чат:
Вот шаблон отслеживания статуса задачи. Адаптируй под мой проект: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про твои этапы и их зависимости — потому что без чёткого списка "что от чего зависит" директивы не сработают. Модель возьмёт структуру команд из шаблона и подставит твои реальные этапы.
Ограничения
⚠️ Не для задач с "оценкой на глаз": если правильное поведение зависит от интерпретации свободного текста (а не от чёткого статуса "готово/заблокировано"), жёсткие команды и блокировки могут навредить — если модель неверно поняла запрос, команда просто закрепляет эту ошибку.
⚠️ Включённый режим рассуждений частично лечит слабый уровень 1-2: у мощных моделей с "размышлением" перед ответом разница между простым чеклистом и явными командами сжимается — но полностью пассивный подход (только переписка) всё равно слабее.
⚠️ Жёсткая блокировка (уровень 4) требует внешнего механизма — кода или инструмента, который физически не даёт выполнить неправильное действие. В чистом чате без интеграций это нельзя воспроизвести буквально, только сымитировать через требование к модели самой себя перепроверять.
Как исследовали
Команда построила тестовый стенд из «проектов»: 5–18 шагов с зависимостями (закупка, согласование, поставка и т.п.), сгенерированных по сценарию — пользователь просит шаги вразнобой, отменяет один, просит переделать другой. Каждый эпизод содержал специальные "ловушки": повторное упоминание готового шага без слова "переделай", вопрос про заблокированный или отменённый шаг.
Проверяли три модели (включая мощную Qwen3-235B и слабую Qwen3.6-35B, а также закрытую DeepSeek V4 Pro), с включённым и выключенным режимом рассуждений. Оценивали не по мнению другой модели-судьи, а строгим сопоставлением кода выполнения — либо шаг выполнен правильно, либо нет.
Оказалось, что просто показ точного статуса поднимает успех совсем немного (с 0,38 до 0,55 у топовой модели), а явные команды-директивы — сильно (до 0,84–0,87), а жёсткая блокировка — почти до максимума (0,98). Но на внешнем бенчмарке про менеджмент проектов, где правильность зависит от интерпретации свободного текста, а не от чёткого статуса, всё наоборот: простой показ записи побеждает обе "командные" версии, а жёсткая блокировка неверного суждения модели только вредит. Отсюда вывод — сила навязывания статуса должна зависеть от того, насколько чётко определено "правильное поведение".
Адаптации и экстраполяции
🔧 Техника: замени пассивный чеклист на требование "сначала статус, потом действие" → эффект: модель не может случайно проскочить мимо статуса к действию, потому что вынуждена сначала произнести его явно.
Пример: в промпте для трекинга переговоров с клиентом попроси модель перед каждым ответом писать "СТАТУС ПЕРЕГОВОРОВ: {этап} — {что решено, что открыто}" — это перенос техники с проектных задач на любой длинный диалог с накопленным контекстом (например, ведение сделки, поддержка клиента, юридическое согласование документа).
🔧 Техника: самоучёт вместо внешнего трекера → если ты сам вручную ведёшь статус проекта и вставляешь его в промпт каждый раз — попробуй вместо этого попросить модель вести его самостоятельно и просто напоминать ей "продолжи с твоего последнего леджера". Экономит твоё время и, по данным исследования, работает даже лучше точного внешнего чеклиста.
Ресурсы
How Strongly Should Task State Influence an LLM Agent? — Chenyu Zhang (University of Waterloo), Wonbin Kweon (Sungkyunkwan University), Jiawei Han (University of Illinois Urbana-Champaign). Препринт. Упоминаются бенчмарки τ²-bench (авиакомпания) и PMBench (управление проектами) как внешняя проверка выводов.