ИИ-агент, который сначала думает, а потом делает: Plan-and-Execute на разборе тендерной документации

Есть задачи, на которых наш обычный ReAct-агент выглядел как человек, который пришёл в незнакомую библиотеку без каталога. Тендерный отдел даёт ему пачку документов на восемьсот страниц — техзадание, требования к участнику, проект договора, приложения со спецификациями — и просит собрать краткую справку: подходим ли мы, что критично, где риски. Агент читает раздел, зовёт инструмент поиска по нашему архиву прошлых проектов, потом лезет в наш реестр лицензий, потом снова возвращается к техзаданию, потом опять в архив с чуть другим запросом. Через пару десятков шагов у нас на руках длинный лог рассуждений и справка, в которой половина пунктов повторяет друг друга.

С этой задачи и начался наш эксперимент с Plan-and-Execute — паттерном, который LangChain на этой неделе довёл до отдельного executor, а мы у себя собрали руками ещё раньше и теперь понимаем, зачем в новом релизе всё это оформили в готовый инструмент. Заодно поговорим шире: что такое ИИ-агент, когда для бизнеса нужен именно он, и почему создание ИИ-агента для сложной задачи всё чаще упирается не в модель, а в архитектуру разговора модели с самой собой.

ИИ-агент — это что такое, если убрать маркетинговую оболочку

Обычно, когда клиент спрашивает «ИИ-агент — что это?», он ждёт услышать про «умного помощника». Мы отвечаем скучнее: это языковая модель, которой дали инструменты и разрешили в цикле решать, какой инструмент дёрнуть следующим. Всё. Магия — в том, кто именно решает и на основании чего.

Классический ReAct — самая простая форма. Модель на каждом шаге думает вслух: «мне нужно проверить лицензию, вызову инструмент X, получу ответ, подумаю снова». Это отлично работает, пока задача короткая. Три-четыре шага — и справка готова. Но как только задача длинная и многоплановая, ReAct начинает вести себя как человек с плохой памятью: забывает, что уже проверял, лезет за одним и тем же дважды, теряет общую нить.

На тендерной задаче мы это увидели в полный рост. Раньше на разбор одной пачки уходил рабочий день менеджера. Агент делал это в разы быстрее, но всё равно долго — потому что каждый его шаг стоил токенов, а шагов набегало много. И часть из них была честно лишняя.

Первый заход: попросили модель «подумать заранее»

Первое, что мы попробовали, — это самое очевидное. Добавили в системный промпт указание: перед тем как звать инструменты, распиши план на бумаге. Модель послушно писала план в начале ответа, а потом всё равно уходила в свой обычный ReAct-цикл и план благополучно забывала где-то к пятому вызову.

Это типичная ошибка на этапе создания ИИ-агента. Кажется, что достаточно попросить — а на деле длинный контекст и накопленные результаты инструментов вымывают из внимания модели даже её собственные обещания. План, который живёт в том же сообщении, что и последующие действия, работает как хорошее намерение в понедельник утром.

Стало понятно: план и исполнение надо разнести. Не по промпту — по архитектуре.

Как создать ИИ-агента, у которого планировщик и исполнитель — разные

Plan-and-Execute — это разделение агента на две роли. Планировщик получает задачу и всё, что он о ней знает, и выдаёт последовательность шагов: «шаг один — найти в архиве похожие тендеры за последние три года, шаг два — сверить их выигрышные заявки с текущим техзаданием, шаг три — проверить наличие нужных лицензий в реестре, шаг четыре — собрать итоговую справку». Исполнитель берёт этот план и идёт по нему пункт за пунктом, каждый пункт — свой маленький ReAct-цикл с доступом к инструментам.

Между шагами есть точка возврата к планировщику: если исполнитель наткнулся на что-то, чего в плане не было (например, техзадание внезапно ссылается на постановление, о котором никто не знал), он говорит «стоп» и просит пересобрать план с новой информацией. Это называется replanning, и это как раз то, что отличает рабочий Plan-and-Execute от красивой картинки в презентации.

У нас планировщик — модель побольше, GigaChat Pro. Он думает медленнее и дороже, но зато нужен один раз в начале и потом эпизодически при пересборке. Исполнитель — модель полегче, YandexGPT Lite. Она вызывается на каждом шаге, но задача у неё простая: взять пункт плана, выбрать один-два инструмента, обработать ответ, отдать промежуточный результат наверх.

Такое разделение — не наше изобретение. Оно ходит по индустрии с 2023 года, а на прошлой неделе LangChain выкатил свой Plan-and-Execute executor как часть основной сборки, а Microsoft показала Agent Lightning для обучения таких агентов через reinforcement learning. Признак того, что паттерн вышел из ранга «интересного эксперимента».

Где всё пошло не так с первой попытки

Первая версия провалилась ровно там, где мы её не ждали. План получался красивый — с чёткими пунктами, зависимостями, даже приоритетами. А потом исполнитель начинал каждый пункт трактовать буквально. «Проверь наличие лицензии на такие-то работы» превращалось в один запрос к нашему реестру по точной фразе из плана, не находилось (реестр хранит формулировки иначе), и агент честно писал «лицензии нет». Тендер уходил в отказ, хотя лицензия у нас была.

Проблема была в шве между двумя моделями. Планировщик мыслил категориями бизнеса, исполнитель — категориями инструментов. Они говорили на разных языках, и точный текст плана становился инструкцией, а не намерением.

Пришлось переделать интерфейс между ними. Теперь пункт плана — это не одна строка, а маленькая структура: цель шага, критерий успеха, подсказка о том, каким инструментом и как это разумно проверить, и главное — что делать, если результат неоднозначный. Исполнитель получает не приказ, а бриф. Ему всё ещё нельзя импровизировать за пределами шага, но внутри шага он свободен пробовать разные формулировки, пока критерий успеха не будет закрыт.

После этого исправления справки по тендерам стали заметно точнее. Ложных отказов почти не осталось. И, что важнее, сократилось количество вызовов инструментов на одну задачу — потому что план сразу отсекал ветки, куда ReAct-агент раньше уходил из любопытства.

Что это меняет в наших ИИ-агентах для бизнеса

Мы не переводим на Plan-and-Execute всё подряд. Для короткого диалога с клиентом в чате на сайте эта архитектура — стрельба из пушки по воробьям, там ReAct естественнее и быстрее. Но там, где задача — это длинный конвейер с ветвлениями и где цена ошибки высокая (тендерный отдел, юридический разбор договоров, аудит закупок), разделение планирования и исполнения окупается почти сразу.

Ещё один побочный эффект, о котором обычно не пишут: план — это то, что можно показать человеку до того, как агент начнёт действовать. Менеджер видит: «агент собирается сделать вот такие пять шагов». Может добавить шестой, вычеркнуть третий, поправить формулировку. Получается настоящее соавторство, а не «нажми кнопку и надейся». Для ИИ-агентов, которые работают в бизнесе с реальными деньгами и договорами, это оказалось важнее, чем ещё пара пунктов на бенчмарке.

А главный вывод для тех, кто сейчас думает, как создать ИИ-агента под свою задачу: сначала честно опишите, сколько шагов агенту предстоит сделать в среднем случае. Если ответ — «два-три», не усложняйте, берите ReAct. Если ответ — «десять и больше, причём с ветвлениями», планировщик и исполнитель окупят вложенное время в первую же неделю. Всё остальное — вопрос дисциплины и хорошего интерфейса между ролями.