Чат-бот и агент: разница, которая стоит денег

Чат-бот отвечает, агент выполняет: обращается к системам, совершает действия, обрабатывает ошибки.

Что произошло

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

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

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

Как устроены оба класса

Чат-бот: модель плюс база знаний

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

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

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

Агент: четыре компонента

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

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

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

Инструменты доступа к системам — интеграции с CRM, ERP, 1С, хранилищами документов, почтой. Каждый инструмент — это описанная функция: что она делает, какие параметры принимает, что возвращает, какие права нужны. Стандартные протоколы, такие как MCP (Model Context Protocol), позволяют описывать инструменты единообразно, так что одна интеграция с 1С используется разными агентами, а добавление нового инструмента не требует переделки всей системы. Это снижает стоимость интеграций, но не отменяет их: у каждого инструмента должны быть права доступа, ограничения и журнал вызовов.

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

Шесть признаков различия

Признак	Чат-бот	Агент
Связь с процессом	Отдельное окно, вне процесса	Встроен в процесс, запускается его событиями
Доступ к системам	Нет; только заранее загруженная база знаний	CRM, ERP, 1С, хранилища документов через инструменты
Что делает	Отвечает текстом	Выполняет действие и проверяет результат
Ошибки	Галлюцинирует молча; ошибку замечает пользователь	Эскалирует по правилу: порог уверенности, лимит, недоступность
Данные	Часто внешнее облако	Закрытый контур; модели и журнал внутри периметра
Измеримость	Практически нет; косвенные метрики	Метрики качества операции и доля эскалаций

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

Критерий «дёшево проверить»

Ключевой вопрос при выборе задач для агента — не «может ли модель это сделать», а «сколько стоит проверить, что она сделала правильно». Стоимость проверки определяет экономику.

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

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

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

Эскалация как механизм, а не как исключение

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

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

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

Как это выглядит на практике

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

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

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

Что это значит для российской компании

Закрытый контур. Агент имеет доступ к учётным системам и обрабатывает данные, которые не должны покидать периметр: персональные данные по 152-ФЗ, коммерческую тайну, данные объектов КИИ. Это исключает внешние облачные модели для агентных задач в большинстве отраслей. Модель разворачивается внутри — открытые модели через сервер инференса вроде vLLM на собственных GPU — и её стоимость входит в экономику проекта с самого начала. Для чат-бота с публичной информацией внешняя модель иногда допустима; для агента — почти никогда.

Интеграции с отечественным стеком. Большинство агентных задач упираются в 1С, отечественные CRM и СЭД. Стандартные протоколы описания инструментов позволяют один раз построить слой доступа к этим системам и использовать его для всех агентов. Это инвестиция в инфраструктуру, которая окупается со второго-третьего сценария, а не с первого.

Регуляторика. Агент совершает действия, и для регулятора это автоматизированное принятие решений. Требования Банка России к операционной надёжности, 152-ФЗ в части автоматизированных решений, требования к КИИ по управлению изменениями — всё это применяется к агенту в полной мере. Правило эскалации, журнал действий и ответственный за процесс — не рекомендации, а условия прохождения внутреннего комплаенса.

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

Что делать: пошагово

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

Типичные ошибки

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

Как понять, что вы на верном пути

Для каждой автоматизируемой операции вы можете назвать, как проверяется результат и сколько это стоит.
Экономика посчитана на плановом объёме с учётом эскалаций и ошибок, и она сходится.
Агент имеет доступ только к перечисленным функциям, и вы можете показать это на уровне прав, а не промпта.
Правило эскалации написано и проверено, доля эскалаций измеряется и обсуждается на регулярной основе.
Все действия агента за любой период восстанавливаются по журналу.
Модель и журнал находятся внутри контура; безопасность и комплаенс согласовали архитектуру.

Вопросы, которые нам задают

Можно ли превратить существующего чат-бота в агента? Модель и базу знаний переиспользовать можно. Всё остальное — инструменты, оркестрацию, правила эскалации, журнал — придётся строить. По объёму работы это новый проект, и планировать его стоит как новый, а не как доработку.

Какой порог уверенности выставить на старте? Консервативный: такой, при котором в режиме подтверждения расхождений с человеком практически не было. Затем снижать по статистике. Порог, выбранный «на глаз» до накопления данных, почти всегда либо слишком низок — и ошибки уходят в системы, — либо слишком высок, и агент не экономит.

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

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

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