Агент с планированием или по сценарию: как выбрать

Почему один подход не подходит всем задачам

Один и тот же LLM-агент редко одинаково хорошо справляется с поддержкой, поиском и внутренними процессами. Задачи слишком разные. Где-то нужен предсказуемый ответ по правилам, а где-то запрос приходит сырым, и путь к ответу нельзя прописать заранее.

Выбор между агентом с планированием и сценарием лучше начинать не с модели и не с модного фреймворка. Сначала смотрят на тип задачи. Если шаги известны, а ошибка дорого стоит, свободу лучше ограничить. Если запросы расплывчатые и каждый раз отличаются, без собственного плана агент быстро упрется в тупик.

Сценарий хорош там, где ответ должен держаться в рамках. В поддержке это особенно заметно: возврат, смена тарифа, статус заявки, сброс доступа. Когда агент идет по фиксированным шагам, команде проще проверить логику, согласовать формулировки и не выпускать в ответ лишнее.

Но сценарий плохо переносит новые случаи. Человек пишет не по шаблону, смешивает две проблемы в одном сообщении или просит исключение, которого нет в правилах. Тогда агент либо зацикливается на ветках, либо дает формально правильный, но бесполезный ответ.

Планирование помогает там, где сам путь к ответу неясен. Например, сотрудник просит найти причину расхождения между CRM, ERP и договором в базе знаний. Тут агенту нужно разбить задачу на шаги, выбрать источники, сравнить версии и, если надо, задать уточняющий вопрос. Поиск по документам с LLM часто выигрывает именно в таких ситуациях.

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

Цена ошибки тоже разная. В поддержке один неверный ответ уходит клиенту. Во внутренней автоматизации ошибка может поменять запись, отправить письмо или запустить процесс не туда. А в поиске промах чаще выглядит мягче: человек просто перепроверяет результат вручную.

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

Поддержка: когда сценарий лучше

В поддержке свобода часто дает больше ошибок, чем пользы. Клиент пишет, чтобы быстро узнать статус, возврат или тариф, а не смотреть, как бот сам выбирает ход разговора. Если ответ типовой, лучше задать четкий путь: что спросить, что проверить, что можно сказать, а где нужно остановиться.

Для поддержки сценарий чаще надежнее. У службы поддержки мало права на догадки. Один лишний ответ про возврат денег или срок подключения легко превращается в жалобу, перерасчет или конфликт с оператором.

Жесткий сценарий для агента хорошо работает там, где правила уже известны. Клиент спрашивает: "Где мой заказ?" Бот просит номер, идет в систему статусов, возвращает только один из разрешенных ответов и, если данных нет, передает диалог человеку. Такой путь скучный, но в поддержке это плюс.

Жесткие переходы особенно полезны в темах, где ответ влияет на деньги или сроки. Боту не стоит обещать "сегодня доставим" или "вернем всю сумму", если система не подтвердила это прямо. Короткий точный ответ здесь лучше красивого, но рискованного.

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

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

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

Поиск: когда агенту нужен свой план

Поиск по базе знаний почти никогда не начинается с идеального вопроса. Люди пишут коротко, путают термины, забывают название документа и часто смешивают несколько тем в одной фразе. Из-за этого простой сценарий нередко ищет не то, что имели в виду.

Когда вы решаете, нужен ли агент с планированием или по сценарию, смотрите на форму запросов. Если сотрудник спрашивает: "покажи шаблон акта за март" или "найди договор №154", жесткий сценарий обычно справляется. Запрос короткий, структура ясна, путь к ответу почти один.

Другая картина возникает, когда вопрос звучит так: "можно ли отправлять клиентские данные во внешнюю LLM для пилота?" Тут мало одного поиска по словам. Агенту нужно разбить вопрос на части: какие данные имеются в виду, есть ли внутренние правила по PII, что сказано в политике безопасности, есть ли ограничения по хранению данных внутри страны. Для команд в Казахстане и Центральной Азии это частый пример: нужно проверить не только базу знаний, но и внутренние требования к data residency, логам и маскированию данных.

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

Когда сценария хватает

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

Что проверять в ответе

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

Внутренние процессы: где нужна середина

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

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

Смешанный вариант обычно дает лучший результат. Обязательные этапы лучше закрепить жестко, а все, что связано с поиском, чтением и черновой сборкой ответа, можно отдать планированию. Тогда агент не ломает процесс, но и не застревает в слишком узком шаблоне.

Правило здесь простое: заранее фиксируйте источники, в которые агенту можно смотреть, задавайте обязательные проверки перед финальным действием, разрешайте самому выбирать порядок поиска и анализа и требуйте отдельное подтверждение перед записью в систему.

Это хорошо видно на примере ежемесячного отчета. Агент может сам найти письма, взять цифры из таблицы, сверить их с CRM и собрать черновик. Но отправку отчета руководителю, изменение статуса заявки или запись новых данных в учетную систему лучше оставить человеку. Иначе одна неверно понятая строка превращается в лишнюю работу для всей команды.

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

Если команда использует единый LLM-шлюз вроде AI Router, такую схему проще собрать на практике. Одной модели можно отдать поиск и планирование, другой - подготовку итогового текста, а право менять записи оставить за отдельным подтверждением. Это не мешает скорости и помогает лучше видеть, где агент делает лишние шаги.

Как выбрать подход по шагам

Выбор редко решают на уровне идей. Чтобы понять, нужен вам агент с планированием или по сценарию, возьмите один живой процесс и разберите его до простых действий. Не "обработка обращений" или "поиск знаний", а что-то вроде: "сотрудник отвечает на вопрос о возврате, проверяет заказ, сверяет правила и пишет итог клиенту".

Дальше полезно пройтись по этому процессу вручную и отметить, где все идет по одним и тем же правилам, а где человек каждый раз думает заново. Сначала опишите шаги без общих слов: кто получает запрос, что проверяет первым, откуда берет данные, когда отвечает сам, а когда передает дальше. Затем отделите стабильные места. Если правило не меняется месяцами, лучше задать его сценарием. Проверка статуса заказа или лимита по заявке обычно не требует свободы действий.

После этого выпишите шаги, где сотрудник ищет информацию, сверяет несколько источников или задает уточняющий вопрос. Именно здесь планирование часто дает пользу. Потом прогоните процесс на 20-30 реальных запросах, а не на красивых примерах. Смотрите, где сценарий ломается, где агент путается и сколько раз человек вмешивается. И только после этого добавляйте планирование в узкие места, где заранее нельзя прописать один верный маршрут.

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

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

Хороший признак зрелого решения простой: команда может показать, на каких шагах нужен контроль, а на каких нужна свобода. Если этого разделения нет, запуск почти всегда выходит дороже и шумнее, чем ожидали.

Один запрос, два варианта работы

Один и тот же вопрос клиента может пойти по двум разным путям. Сообщение "Где мой возврат и почему сумма другая?" хорошо это показывает, потому что в нем сразу две задачи: найти статус и объяснить расхождение в деньгах.

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

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

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

Это удобнее, когда правда разбросана по нескольким системам. В поддержке так бывает часто: статус лежит в CRM, сумма - в биллинге, а причина - в документе с правилами возврата. Поиск по фиксированному сценарию в такой ситуации быстро упирается в исключения.

Разница простая. Сценарий быстрее, дешевле и проще контролировать. Агент с планированием лучше справляется с неполными и запутанными случаями. Но оба подхода ломаются, если источники данных спорят друг с другом.

Именно на расхождении данных нужен жесткий стоп. Если платежная система показывает одну сумму, а правило возврата дает другую, системе не стоит додумывать причину. Лучше сразу передать диалог человеку и приложить найденные факты: заказ, статус возврата, расчет суммы и источник правила.

На практике агент с планированием или по сценарию редко выбирается раз и навсегда. Типовые запросы обычно пускают по сценарию, а все, что не прошло проверку уверенности, отправляют агенту с планированием или оператору. Это дает более спокойный запуск: быстрые ответы на простые вопросы и меньше странных объяснений там, где цена ошибки выше пары сэкономленных секунд.

Где команды чаще ошибаются

Ошибка обычно не в модели, а в том, сколько свободы ей дали. Команды часто разрешают импровизацию там, где порядок шагов давно известен и менять его нельзя.

Если бот поддержки оформляет возврат, меняет тариф или открывает доступ, лишняя свобода мешает. Агент с планом может сделать лишний вызов, выбрать не тот инструмент или задать вопрос, который оператор никогда бы не задал. Там, где есть строгая политика, лимиты и обязательные проверки, сценарий почти всегда надежнее.

Обратная крайность тоже дорого обходится. Команда строит сценарий на сотни веток, а потом жизнь уходит в обход: меняется форма заявки, поле в CRM, текст регламента, и дерево правил быстро стареет. Через месяц такой сценарий уже лучше знает прошлую версию процесса, чем текущую.

Еще одна частая ошибка - агенту открывают слишком много инструментов. Он видит базу знаний, CRM, почту, поиск по файлам и внутренние API сразу, хотя для задачи нужны два шага. Тогда он тратит время и токены на лишние действия.

Границы лучше задать заранее: какие инструменты доступны для этого типа запроса, сколько шагов агент может сделать, какие действия требуют подтверждения человека и когда агент должен остановиться и передать задачу дальше.

Многие смотрят только на итоговый ответ. Это ловушка. Один и тот же ответ можно получить за 2 шага или за 7, и разница в цене станет заметной уже на реальной нагрузке. Если команда работает через единый LLM-шлюз, ей проще увидеть, сколько стоит каждый вызов модели и где агент расходует бюджет без пользы.

Тесты тоже часто обманывают. На чистых примерах все работает: запрос короткий, документ лежит в нужной папке, пользователь формулирует мысль ясно. В продакшене люди пишут с опечатками, смешивают русский и английские названия полей, присылают лишний контекст и ждут ответ за несколько секунд.

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

Короткая проверка перед запуском

Перед первым релизом прогоните агента на 10-20 живых запросах. Берите не красивые примеры, а обычные: путаные формулировки, неполные данные, срочные просьбы, раздраженные сообщения. На таком наборе быстро видно, где система держится уверенно, а где ей нужен человек.

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

До запуска полезно проверить пять вещей. Агент не должен гадать, когда можно отвечать самому, а когда пора передать диалог сотруднику. Команда заранее задает список разрешенных данных и действий. По каждому запросу должен оставаться понятный след: какие шаги агент сделал, к каким источникам обратился и какой ответ показал пользователю. Ошибка не должна портить данные, поэтому любые изменения в CRM, карточке клиента или статусе заявки лучше подтверждать вручную. И еще до запуска стоит посчитать цену одного типового запроса, включая поиск по базе, повторные вызовы, длинный контекст и ретраи.

Даже один короткий тест часто дает неприятный, но честный вывод. Например, бот поддержки уверенно отвечает на частые вопросы, но на фразе "исправьте мой адрес и перевыпустите документ" уже должен остановиться и позвать оператора. Это нормальная граница, а не провал.

Если вы работаете через AI Router, полезно смотреть не только на итоговый ответ, но и на аудит-лог по запросу. По нему проще понять маршрут, выбор модели, вызовы инструментов и стоимость. Иногда один такой лог экономит больше времени, чем неделя споров в чате.

Если хотя бы один из этих пунктов пока не закрыт, не выпускайте агента на реальные данные. Сначала уберите право на запись, включите логирование и посчитайте цену запроса на трех частых сценариях.

Что делать дальше

Не пытайтесь сразу решить все задачи одним способом. Возьмите один поток, где ошибка видна быстро: ответы поддержки, поиск по базе знаний или одну внутреннюю рутину вроде разбора заявок. Так вы поймете, где агент с планированием или по сценарию дает больше пользы, а где только добавляет лишние шаги.

Дальше соберите не придуманные примеры, а живые запросы хотя бы за одну неделю. Нужны обычные случаи, спорные случаи и несколько неприятных запросов, на которых команда уже ошибалась. Если в выборке только простые вопросы, тест почти ничего не покажет.

Удобнее всего проверить оба подхода на одной и той же выборке:

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

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

Если команде нужно быстро прогнать несколько моделей без переделки текущей интеграции, удобен один OpenAI-совместимый эндпоинт. В случае с AI Router это позволяет сравнивать подходы на одном и том же процессе, не меняя SDK, код и промпты. На этапе тестов это особенно удобно: легче отделить влияние самой модели от влияния сценария и планирования.

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