Когда выбрать жёсткий сценарий, а когда выпускать агента на базе LLM

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

Недавно я разбирала подробный материал, где сравнивают два способа проектирования: детерминированный сценарий (жёсткая последовательность шагов в коде) и агентский подход, когда LLM (большая языковая модель — модель, которая понимает и генерирует текст) сама планирует действия и пользуется инструментами. По моему опыту, бизнесу редко нужен крайний вариант. Чаще выигрывает гибрид с ограничениями, лимитами и эскалациями к человеку.

Два подхода: в чём суть и что это даёт бизнесу

Сценарий — это когда вы в коде задаёте цепочку шагов и точку, где подключается LLM. Пример из практики: берём ссылку на профиль в LinkedIn, тянем данные через API (интерфейс для обмена данными между системами), а затем просим модель сгенерировать персонализированное сообщение. Если где-то 404 или пустой ответ — процесс останавливается, вы ловите ошибку и либо делаете повтор, либо завершаете без результата. Такой подход предсказуем, дешевле по запросам и удобнее в тестировании.

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

Простой ориентир: если в процессе растёт количество if-веток, try/catch и ручных исключений, это сигнал посмотреть на агентский дизайн.

Когда сценарий выгоднее, а когда агент окупится

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

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

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

Гибрид: поручни, лимиты и эскалации

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

• Инструкции агента. Чётко описываем цель и правила. Самокоррекция допустима только в оговорённых рамках: что именно агент может менять, что проверять и какие инструменты использовать.
• Guardrails (поручни). Лимит попыток, потолок токенов (единиц текста, которыми считает модель), список разрешённых методов и эндпоинтов, стоп-слова и обязательные проверки входящих и выходящих данных.
• Журнал решений. Логи вызовов инструментов, промежуточные выводы и сырой ввод. Это база для аудита, уточнения инструкций и работы с безопасностью.
• Эскалации. Если попытки исчерпаны, данные противоречивы или риск высокий, агент передаёт задачу оператору. Эскалация — это заранее описанный переход к человеку с полем для контекста и черновиком решения.
• Тест-сценарии. Позитивные и «грязные» кейсы: пустые поля, опечатки, недоступность внешних сервисов, неожиданные форматы. Мы намеренно «ломаем» систему до продакшена.

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

Деньги: как считать TCO/ROI и запуститься без сюрпризов

TCO (совокупную стоимость владения) я считаю до старта. Включаю запросы к LLM, обращения к внешним API, хранение логов, разработку и поддержку. Плюс скрытые места: антиспам-защита, повторы запросов, мониторинг качества и время аналитика на разбор спорных случаев. В агентских схемах добавляю буфер на «исследовательские» шаги, потому что модель может сделать несколько попыток, прежде чем найдёт путь.

ROI (окупаемость) я считаю через выигрыш во времени и влиянии на воронку. Например, в аутрич-процессе (поиск и контактирование с потенциальными клиентами) агент чаще доводит задачу до финального сообщения, даже если входные данные кривые. Это даёт прирост доведённых контактных касаний. В сценарии этот прирост ниже, зато стоимость шага стабильнее. Баланс ищем тестом на репрезентативной выборке и сравниваем долю успешно завершённых задач, затраты на один успешный исход и время цикла.

Про запуск в российских реалиях. Заложите план Б для внешних сервисов и нестабильных каналов. В реестре рисков отмечаем квоты провайдеров, возможные 404, задержки и недоступность. Для каждого риска — резервный сценарий: альтернативный источник данных, управляемое ухудшение качества, отложенная обработка или ручная эскалация. И обязательно локальные логи с ограниченным сроком хранения и приватностью, чтобы разборы были возможны без доступа к внешним платформам.

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

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