«Составь план и следуй ему» звучит как очевидно правильная инструкция для агента. На практике это самый надёжный способ получить систему, которая уверенно выполняет неверную последовательность действий до самого конца.
Причина в том, что план строится на предположениях о мире, которых модель ещё не проверяла. Первое же обращение к реальным данным эти предположения опровергает — и дальше агент либо честно следует устаревшему плану, либо тихо от него отклоняется, и тогда план становится украшением в логе.
#Короткий ответ
Есть два подхода к декомпозиции.
Статический план. Модель один раз выдаёт список шагов, дальше исполнитель идёт по списку. Дёшево, предсказуемо, ломается при любом расхождении с реальностью.
Перепланирование. Модель держит короткий план, после каждого значимого наблюдения проверяет, жив ли он, и правит. Дороже, устойчивее, требует явного условия остановки.
Правильный выбор зависит не от сложности задачи, а от одного признака: известны ли результаты шагов заранее. Если известны — план не нужен вовсе, нужен скрипт. Если неизвестны — статический план не выживет.
#Один пример, два подхода
Задача: «собери мои расходы за прошлый месяц из выписок и сделай сводку по категориям».
#Статический план
Модель, ничего ещё не видев, выдаёт:
1. открыть папку с выписками
2. прочитать файл за прошлый месяц
3. разобрать строки на категории
4. посчитать суммы
5. записать сводку
Что происходит при исполнении:
шаг 1 list_dir(".")
→ statements/ содержит 3 файла: 07.csv, 08.csv, 08-2.csv
шаг 2 read_file("statements/08.csv")
→ 210 строк, но последняя дата — 12 августа
шаг 3 разобрать строки на категории
→ выполняется, хотя половины месяца нет
шаг 4 посчитать суммы
→ выполняется на неполных данных
шаг 5 записать сводку
→ сводка сделана и неверна
План не предусмотрел, что выписка разбита на два файла. Ни один шаг не «упал»: агент прошёл всю последовательность, отчитался об успехе и выдал число, которое человек примет за правду. Это худший класс отказа — тихий.
#Перепланирование
Тот же прогон, но после каждого наблюдения модель отвечает на вопрос «остаётся ли план верным».
шаг 1 list_dir(".")
→ statements/: 07.csv, 08.csv, 08-2.csv
ПЕРЕСМОТР файлов за август два, план правится:
читать оба и объединять
шаг 2 read_file("statements/08.csv")
→ 210 строк, до 12 августа
ПЕРЕСМОТР подтверждает: нужен второй файл
шаг 3 read_file("statements/08-2.csv")
→ 168 строк, с 13 по 31 августа
ПЕРЕСМОТР данные полные, дальше по плану
шаг 4 разбор и суммы
шаг 5 сводка + пометка: использованы два файла
Разница в стоимости: на один вызов инструмента больше и по одному короткому решению после каждого наблюдения. Разница в результате: правильная сумма вместо неправильной.
#Сравнение подходов
| Критерий | Статический план | Перепланирование |
|---|---|---|
| Вызовов модели | Меньше | Больше на 1 короткий за шаг |
| Устойчивость к сюрпризу | Низкая | Высокая |
| Предсказуемость стоимости | Высокая | Средняя |
| Риск тихой ошибки | Высокий | Ниже |
| Риск блуждания | Низкий | Выше |
Обратите внимание на последнюю строку: перепланирование покупает устойчивость ценой нового риска. Агент, которому разрешено менять план, может менять его бесконечно. Отсюда обязательное условие: у динамического планирования должен быть жёсткий счётчик пересмотров, иначе вы получите новый механизм зацикливания; разбор механизмов — в статье про зацикливание агента и предохранители.
#Что из этого следует на практике
План должен быть коротким. Три-пять пунктов. Длинный план — это признак того, что модель придумывает детали, которых не знает. Каждый лишний пункт — предположение, которое ещё не проверено.
План живёт в контексте и стоит места. На восьмом шаге вы платите за него в каждом вызове. Если план не пересматривается, его вообще стоит выкинуть из контекста после составления.
Пересмотр должен быть дешёвым. Отдельный длинный вызов «переосмысли всё» съедает выигрыш. Работает короткий вопрос с ответом из одного слова плюс правка, если она нужна.
Точки пересмотра лучше задавать явно. Пересматривать план после каждого наблюдения избыточно: чтение третьего файла подряд ничего не меняет. Разумная эвристика — пересматривать после наблюдений, которые дали новые сущности (новые файлы, новые записи, ошибку).
Декомпозиция сверху вниз опаснее, чем кажется. Модель охотно разбивает задачу на подзадачи, которые звучат разумно и не соответствуют структуре данных. Признак — подзадачи сформулированы в терминах общего языка, а не в терминах доступных инструментов.
Хорошая подзадача проверяема. Формулировка «разобраться с выписками» непроверяема. «Получить список файлов в statements» проверяема: есть список или нет. Если подзадачу нельзя проверить одним взглядом на наблюдение, она сформулирована плохо.
Механика самого цикла, внутри которого всё это происходит, — в разборе паттерна ReAct.
#Где интуиция подводит
«Хороший план — залог хорошего результата». Для человека — часто. Для агента план ценен ровно настолько, насколько он основан на проверенных фактах. План, составленный до первого обращения к данным, состоит из догадок, и его уверенный вид опаснее его отсутствия.
«Разбить задачу на десять подзадач лучше, чем на три». Каждая подзадача — это шаг, наблюдение и место в контексте. Десять мелких подзадач стоят дороже трёх крупных и дают больше точек, где можно свернуть не туда.
«Если задача сложная, нужно больше агентов». Обычно нет: больше агентов — это больше передач контекста и больше мест, где смысл теряется при пересказе. Скептический разбор — в обзоре мультиагентных систем.
«Маленькая модель просто хуже планирует». Она хуже не столько планирует, сколько удерживает план: на третьем-четвёртом шаге начинает возвращаться к первому пункту или терять формат вызова. Для компактных моделей план надо делать не лучше, а короче — подробности в разборе пределов агентов на маленькой локальной модели.
#Когда планирование не нужно
Когда шаги известны заранее. Это скрипт. Модель в нём нужна максимум для одного шага — разбора неструктурированного текста, — а остальное делает код: быстрее, дешевле и одинаково каждый раз.
Когда шагов два. Планировать две операции — накладные расходы больше самой работы.
Когда ошибка дешевле проверки плана. Если результат мгновенно виден и легко исправляется, честнее дать агенту попробовать, чем платить за планирование.
Общая рамка того, где вообще нужна агентность, — в базовой статье о том, что такое ИИ-агент.
#Частые вопросы
#Нужно ли просить агента показать план пользователю?
Если план влияет на необратимые действия — обязательно, и до их выполнения. Показанный план — это дешёвая точка контроля: человек за пять секунд видит, что агент собрался читать не ту папку, и это дешевле, чем разбирать последствия.
#Сколько шагов должно быть в плане?
Три-пять. Более длинный план почти всегда содержит выдуманные детали: модель дописывает шаги, о которых у неё нет данных. Если задача кажется длиннее — это признак, что её нужно разбить на несколько запусков с проверкой между ними.
#Как понять, что агент отклонился от плана?
По логу: сравните список запланированных шагов с фактической последовательностью вызовов. Расхождение само по себе не ошибка — при перепланировании оно нормально. Ошибка — когда план в контексте остался прежним, а действия ему не соответствуют: это значит, что план перестал влиять на поведение и только занимает место.
#Что делать, если план ломается каждый раз?
Посмотреть, на каком шаге он ломается. Стабильное место означает, что реальность устроена не так, как модель предполагает по умолчанию, и это чинится не планированием, а описанием инструмента или предварительным шагом, который эту реальность выясняет.
#Планирование увеличивает стоимость?
Да, на короткий дополнительный вызов после значимых наблюдений. Обычно это дешевле одного неверного прогона, но не всегда: на задачах в два-три шага с очевидной структурой планирование не окупается.
#Вывод
Статический план дёшев и ломается о первое расхождение с реальностью, причём ломается тихо: агент доходит до конца и выдаёт неверный результат с уверенным видом. Перепланирование дороже на один короткий вызов за шаг и покупает устойчивость ценой риска блуждания, который надо ограничивать счётчиком.
Если результаты шагов известны заранее — не планируйте, пишите скрипт. Если неизвестны — держите план коротким, пересматривайте его после наблюдений с новыми сущностями и ставьте предел на число пересмотров.