Что выбрать бизнесу: сценарный бот, RAG-помощник, AI-воркфлоу или автономный агент

Редакция «Текстерры»

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

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

Сценарный бот ведет пользователя по заранее описанному пути

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

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

Главное преимущество сценарного бота — предсказуемость. Команда может проверить каждую ветку, заранее определить текст ответов и условия передачи диалога сотруднику.

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

Такая задача возникла у нас в проекте «Играем по-особому». Родителю или специалисту мало выбрать тему из готового списка: нужно учесть роль взрослого, состояние ребенка, возможности восприятия и текущую ситуацию. Для проекта мы собрали библиотеку из 150+ авторских мини-игр. Помощник уточняет контекст, составляет профиль ребенка и предлагает подходящий сценарий.

Этот пример показывает, почему для части диалогов длинного дерева веток недостаточно. В 2025 году решение запустили совместно с Крымским Детским Хосписом; оно работает в Telegram, VK и MAX.

RAG-помощник отвечает с опорой на корпоративные данные

RAG расшифровывается как Retrieval-Augmented Generation. Перед генерацией ответа система находит релевантные фрагменты в подключенных источниках и передает их языковой модели как контекст, а она уже формирует ответ с учетом этих данных.

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

В проекте FDM наш AI-ассистент отвечает на вопросы по данным финансовой платформы: реестру операций, счетам, проектам, контрагентам и аналитике. Платформа учитывает роли сотрудников, поэтому доступ к информации зависит от должности.

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

Качество ответа зависит от качества источников и настройки поиска: важно определить, какие документы считаются актуальными, как обрабатываются разные версии, какие данные доступны конкретному пользователю и как система показывает первоисточник. О том, как собрать такую базу, мы подробно рассказали в статье «Корпоративная база знаний для AI-помощника: как собрать RAG, которому можно доверять».

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

AI-воркфлоу автоматизирует заданную последовательность действий

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

Путь выполнения в воркфлоу задает код приложения, а в агентском сценарии модель сама управляет процессом и использованием инструментов.

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

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

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

Мы собрали единую платформу с планировщиком и зависимостями задач, интеграциями с PostgreSQL и MS SQL, визуальным конструктором пайплайнов, дашбордами и ролевым доступом. AI-агент принимает запросы на естественном языке и автоматизирует рутинные операции, а сама платформа задает правила обмена данными и последовательность процессов.

Любой новый маршрут потребуется спроектировать, настроить и протестировать.

Автономный агент выбирает следующий шаг по ситуации

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

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

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

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

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

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

Я думаю, что проектирование AI-помощника во многом продолжает ту работу, которую TexTerra много лет ведет в контент-маркетинге, поисковом продвижении и развитии клиентского опыта. Мы изучаем, как люди формулируют свои задачи, каких сведений им не хватает для выбора, в какой момент нужен ответ, уточняющий вопрос или помощь специалиста. Клиент обычно описывает желаемый результат и ограничения, а не внутреннее устройство продукта, поэтому мы и начинаем с клиентского сценария и реальных формулировок — а затем связываем их с данными компании, ее предложениями и процессами.

Дарья Завьялова,

главред в маркетинге TexTerra

Подходы по-разному участвуют в обработке запроса

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

На примерах маркетинговых задач разницу между заданной автоматизацией и агентским сценарием мы показывали в статье «Реклама, аналитика, CRM и отчеты: какие задачи можно поручить AI в отделе маркетинга».

Один запрос по-разному проходит через систему

Представим, что клиент пишет в чат: «Хочу изменить условия заказа». Вот как себя поведут разные системы.

Сценарный бот

Бот попросит номер заказа и предложит готовые варианты: изменить адрес, дату доставки, состав заказа. После выбора он проведет клиента по нужной ветке. Если для этой ситуации нет правила, обращение перейдет сотруднику.

RAG-помощник

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

AI-воркфлоу

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

Автономный агент

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

Выбор начинается с описания бизнес-процесса

Перед разработкой определите:

• Какой результат должен получить пользователь или сотрудник.

• Нужно ли системе только найти и объяснить информацию либо совершить действие.

• Какие данные и интеграции потребуются.

• Какие случаи можно описать правилами, а где следующий шаг зависит от ситуации.

• Каковы последствия ошибки, можно ли отменить действие и кто должен его подтверждать.

• Как команда будет проверять качество после запуска и при обновлении данных, модели или кода.

Для процесса с короткими и понятными ветками достаточно сценарного бота. Если главная задача — отвечать по внутренним документам, нужен RAG-компонент. Повторяющиеся процессы с известным маршрутом подходят для AI-воркфлоу. Агент стоит рассматривать там, где ценность создает выбор следующего шага на основе меняющегося контекста.

Во многих проектах итоговое решение объединяет несколько подходов. Мы начинаем работу с разбора процесса, данных, интеграций и рисков, а затем проектируем AI-помощника с нужным уровнем самостоятельности. Перед запуском мы проверяем систему на реальных и пограничных сценариях — подход к таким проверкам мы подробно описали в статье «Как тестировать AI-ассистента. Evals, эталонные наборы и регрессионные проверки».

Читайте также:

Как спроектировать диалог с AI-помощником: от запроса пользователя до результата

AI-агенты входят в клиентский путь: как подготовить данные, сайт и процессы

Как управлять ссылками в AI-сценариях: задаем маршрут от ответа до целевого действия