AI-агент, бот или обычная автоматизация: как выбрать подход

Сначала найдите решение, которое уже описано правилом

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

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

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

Отделите интерфейс бота от способности рассуждать

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

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

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

Разделите предложение действия и само действие

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

В проектной работе MR·H обсуждение начинается с конечного маркетингового результата, согласованного объёма и критериев приёмки. Например, для CRM-связки важны сохранение обращения, нужные поля, ответственный и передача результата клиенту. Название технологии само по себе не определяет состав работ. Если предложению требуется разработка отдельного AI-продукта, эту компетенцию нельзя считать включённой в обычный маркетинговый проект без подтверждённого объёма и исполнителя.

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

Проектная работа MR·H

Дайте агенту ровно ту свободу, которая нужна задаче

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

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

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

Сравнивайте не только обычный путь, но и исключения

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

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

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

Зафиксируйте дерево выбора в рабочем задании

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

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