Чем ИИ-агент отличается от чат-бота и что выбрать бизнесу

Чат-бот ведёт диалог по заранее прописанному сценарию, ИИ-агент сам выбирает действия и обращается к системам компании. Разница проявляется в задачах: бот отвечает на вопросы, агент закрывает процесс — от заявки до записи в CRM.

Сергей Езепенко · 10.11.2026 · время чтения 17 мин

Где проходит граница между ботом и агентом

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

Второе отличие — работа с внешними системами. Бот отвечает текстом в окне чата и на этом обычно заканчивается. Агент вызывает инструменты: обращается к CRM, чтобы найти клиента по номеру телефона или создать сделку, смотрит свободные слоты в календаре и ставит встречу, поднимает данные из базы знаний или из договора, формирует счёт, отправляет письмо. Каждый такой вызов — отдельное действие с реальными последствиями. Текст в чате становится отчётом о том, что агент сделал, а не единственным результатом работы.

Третье отличие — изменение состояния системы. Бот по определению ничего не меняет: он информирует, уточняет, направляет. После разговора с ботом в CRM не появляется запись, в календаре не возникает встреча, статус заявки остаётся прежним. Агент меняет состояние: переводит лид в следующую стадию, создаёт задачу менеджеру, бронирует время, обновляет карточку клиента. Это и есть практический критерий, по которому стоит различать одно от другого в рабочем проекте.

Проверить, с чем вы имеете дело, можно тремя вопросами к системе:

1. Что произойдёт, если клиент сформулирует запрос так, как его нет в сценарии? Бот уйдёт в заглушку или на оператора, агент попробует разобрать запрос и выбрать инструмент.
2. Есть ли у системы доступ на запись во внешние сервисы? Если только чтение и вывод текста — это бот, пусть и с языковой моделью внутри.
3. Кто отвечает за результат? У бота ответственность за прохождение ветки, у агента — за достижение цели: записан ли клиент, создана ли сделка, получен ли ответ на вопрос.

Пример из практики. Компания по установке окон поставила бота, который собирал заявки через кнопки: тип окна, размер, район. Клиент, который писал «нужно замерить в четверг после 18:00 на Ленина, 14», ломал сценарий — бот не понимал свободный текст и просил нажать кнопки заново. После переделки в агента с доступом к календарю и CRM система сама находила свободный слот, создавала заявку на замер с адресом и присылала монтажнику уведомление. Формально задача та же — принять обращение, но во втором случае менялось состояние систем, а не только текст в чате.

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

Как устроен чат-бот: сценарий, дерево, кнопки

Логика бота задаётся вручную. В конструкторе (ManyChat, BotHelp, Salebot, встроенные редакторы мессенджеров) или в коде рисуется дерево: приветствие, вопрос, варианты ответа, ветки на каждый вариант, переходы, тупики, точка передачи оператору. Каждый шаг описан явно. Разработчик заранее решил, что бот спросит, какие кнопки покажет и что ответит на каждую. Свободы выбора у бота нет: он исполняет то, что нарисовано.

Ответы берутся из заготовок. Тексты прописаны в блоках сценария, а на частые вопросы подключается база FAQ — список пар «вопрос-ответ» с ключевыми словами для поиска. Если клиент формулирует иначе, чем в базе, срабатывает либо нечёткое совпадение по словам, либо заглушка. Качество такого поиска зависит от того, насколько полно менеджер описал варианты формулировок. Языковая модель может стоять поверх FAQ и пересказывать найденный ответ своими словами, но источник остаётся тем же — заранее заготовленный текст.

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

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

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

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

Как устроен ИИ-агент: модель, инструменты, память

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

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

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

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

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

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

Сравнение по пяти параметрам для бизнеса

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

Стоимость запуска. Чат-бот на готовой платформе — это подписка и настройка сценариев силами одного сотрудника. Порядок цен — от нескольких тысяч рублей в месяц за конструктор до 150–300 тысяч рублей за кастомного бота с интеграцией в один-два сервиса. Агент дороже на порядок: разработка, описание схем инструментов, настройка памяти, тестовый контур, логирование. Реалистичный бюджет первого запуска — от 500 тысяч до 2–3 млн рублей, если речь о нескольких интеграциях и правах на запись. Разница не в «умности» модели, а в объёме инженерной работы вокруг неё: у бота её почти нет, у агента она составляет основную часть сметы. Подробная разбивка по статьям — в материале сколько стоит внедрить ИИ-агента в бизнес.

Срок внедрения. Простой бот на конструкторе поднимают за неделю: дерево сценариев, тексты, кнопки. Бот с интеграцией в CRM — три-четыре недели. Агент с одним-двумя инструментами и подтверждением действий — от шести до десяти недель. Агент с несколькими системами, правами на запись и мониторингом — от двух до трёх месяцев. Срок растягивают не модель и не код, а согласование доступов, описание бизнес-правил и проверка на реальных данных: нужно прогнать сотни диалогов, чтобы увидеть, где агент уходит не туда.

Точность. Бот предсказуем: на один и тот же вопрос он даёт один и тот же ответ, и это ответ, который в него заложили. Ошибка бота — это ошибка сценария, её находят и правят. Агент ошибается вероятностно: одна и та же цель может быть достигнута разными путями, и на части прогонов модель выберет неверный инструмент, перепутает параметр или сочтёт задачу выполненной раньше времени. На практике доля корректных выполнений на отлаженном сценарии — 85–95%, и её нельзя поднять до 100%. Отсюда правило: критичные действия — только с подтверждением человека, а метрику качества считают по логам, а не по ощущениям.

Поддержка. Бот правится вручную: изменился прайс — обновили ветку сценария, добавился вопрос — добавили кнопку. Работа предсказуемая, её делает один человек, знающий продукт. Агент требует мониторинга: нужно смотреть, какие инструменты вызываются, где модель зацикливается, какие запросы чаще всего приводят к отказу. Раз в месяц-два — ревизия схем и подсказок модели. Это отдельная роль, чаще всего — инженер или аналитик на part-time, 10–20 часов в месяц. Без мониторинга качество медленно падает: меняются данные, ломаются интеграции, модель начинает чаще ошибаться на краевых случаях.

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

Задачи, которые агент закрывает, а бот нет

Разница проявляется не в интерфейсе, а в том, что происходит после ответа. Чат-бот заканчивает работу репликой: выдал информацию, собрал контакт, предложил ссылку. Агент продолжает действовать — у него есть доступ к системам и право менять в них записи. Ниже четыре задачи, где это различие видно на практике.

Квалификация лида. Классический бот спрашивает «какая у вас задача?» и складывает ответ в таблицу. Агент ведёт диалог по скрипту квалификации: уточняет отрасль, размер команды, бюджет, сроки, текущий инструмент. По ходу сверяется с критериями ICP и сам решает, к какой категории отнести обращение. Дальше — действия: создаёт сделку в CRM, заполняет поля (источник, сумма ожидаемой сделки, ответственный менеджер), ставит задачу «позвонить в течение 2 часов» и прикладывает расшифровку диалога к карточке. Менеджер открывает CRM и видит готовую сделку, а не строчку «клиент что-то спрашивал». Если лид не проходит по критериям — агент помечает его как нецелевой с причиной, и отдел продаж не тратит на него время.

Подбор и бронирование слота. Бот может показать ссылку на календарь. Агент читает реальную занятость через API календаря, учитывает длительность встречи, буфер между звонками, часовой пояс клиента и правила (например, «не ставим демо после 18:00 по местному времени клиента»). Предлагает два-три варианта, подтверждает выбранный, создаёт событие, отправляет приглашение и напоминание, а при переносе — перебронирует и уведомляет участников. Цепочка из пяти шагов проходит без человека.

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

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

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

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

Риски и ограничения ИИ-агентов

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

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

Стоимость токенов. Каждый шаг агента — это запрос к модели, а контекст диалога накапливается. Длинная переписка с несколькими вызовами инструментов обходится в разы дороже одного ответа бота. Расход растёт нелинейно: чем больше шагов и чем длиннее история, тем выше счёт. Практические ограничения — лимит шагов на диалог, обрезка или суммаризация истории после N сообщений, кэширование повторяющихся запросов, дешёвая модель для простых шагов (классификация, извлечение полей) и дорогая только для сложных. Считать бюджет стоит по сценарию: среднее число шагов × цена токена × число обращений в месяц, с запасом на пики. Ориентиры по бюджету — в разборе Сколько стоит внедрить ИИ-агента в бизнес в 2026 году.

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

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

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

Сколько стоит внедрение и на чём экономят

Разница в цене между ботом и агентом появляется не на этапе «написать код», а на этапе «подключить к реальным системам». Бот на скриптах отвечает по заранее прописанному дереву и живёт внутри одного канала — сайта, мессенджера, телефонии. Агент обращается к CRM, базе заказов, складскому учёту, почте, внутренним API. Каждое подключение — это работа с доступом, схемой данных, обработкой ошибок и тестами. Отсюда и разброс в бюджетах.

Ориентиры по деньгам, которые видно по проектам малого и среднего бизнеса. Пилот на одном процессе — порядка 150–400 тыс. рублей. В эту сумму входят проектирование сценария, настройка модели, одна-две интеграции, тестовый прогон на исторических данных и запуск в ограниченном контуре: например, агент разбирает входящие заявки и раскладывает их по ответственным, но финальное решение подтверждает менеджер. Промышленный агент с полноценными интеграциями, разграничением прав, логированием и мониторингом — от 1 млн рублей, верхняя граница зависит от числа систем и требований к безопасности. Если процесс затрагивает персональные данные или платежи, добавляются расходы на согласование с юристами и ИБ.

Стоимость владения — отдельная строка, о которой забывают на этапе презентации. Она складывается из трёх частей:

1. Токены и вызовы модели. Агент делает несколько обращений на одну задачу: планирует шаг, вызывает инструмент, проверяет результат. Расход в 3–10 раз выше, чем у простого чат-бота с готовыми ответами, и зависит от длины контекста и модели.
2. Мониторинг и поддержка. Нужны логи диалогов, алерты на сбои интеграций, регулярный просмотр ошибочных сценариев. Это часы инженера или подрядчика каждый месяц, а не разовая настройка.
3. Обновление сценариев. Процессы меняются: появляются новые статусы заказов, меняются правила возврата. Скрипт бота правится вручную, агент чаще требует переобучения промптов и проверки инструментов.

Экономия, ради которой всё затевается, лежит в рутине. По процессам обработки заявок, первичной квалификации лидов и разбора обращений в поддержку высвобождается 20–40% времени операторов — вилка широкая, потому что зависит от доли типовых операций и качества исходных данных. Если оператор тратит на одну заявку 6 минут, а половина заявок уходит агенту, экономия считается в человеко-часах, а не в «процентах эффективности».

Пример из практики: компания с потоком около 400 входящих писем в день запустила агента на сортировку и черновики ответов. Пилот обошёлся примерно в 250 тыс. рублей, включил интеграцию с почтой и CRM. Через два месяца доля писем, где оператор только проверял черновик, дошла до 55%, среднее время ответа сократилось с 4 часов до 40 минут. Экономия на токенах и поддержке при этом съедала около 15% полученного выигрыша — цифра, которую стоит держать в голове до старта.

Как выбрать формат под свою задачу

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

Массовые типовые вопросы — хватит бота. Если 80% обращений сводятся к десятку формулировок (график работы, статус доставки, условия возврата, адрес пункта выдачи), дерево сценариев закрывает задачу дешевле и предсказуемее. Бот не «фантазирует», его ответы проверяемы, а поведение не зависит от настроения модели. Для поддержки на сайте с потоком однотипных вопросов это разумный выбор, и городить агента ради него не нужно.

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

Порядок действий, который снижает риск:

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

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

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

Автор: Сергей Езепенко, основатель «Системы Поток». Работаю с клиентами с 2018 года, 20 запущенных проектов: стройка, медицина, юруслуги, недвижимость, онлайн-школы.