События чатов и жизненный цикл диалога

Скопировать ссылку на статью

Скопировано

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

Чат, диалог и канал

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

Канал — это источник переписки: WhatsApp, Telegram, онлайн-консультант на сайте, Instagram и другие. Агент настраивается на работу в конкретных каналах, и именно по каналу система решает, какой агент должен обрабатывать переписку.

Чат — это переписка с конкретным клиентом в конкретном канале. Один и тот же человек, написавший вам в WhatsApp и в Telegram, в системе представлен двумя разными чатами.

Диалог — это отдельное обращение внутри чата. У диалога есть статус (открыт или закрыт) и ответственный — тот, кто сейчас ведёт переписку: менеджер или бот. Один чат за свою историю может содержать много диалогов: клиент обратился, вопрос решили, диалог закрыли; позже клиент написал снова — открылся новый диалог.

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

Как агент «слышит» чат

Работа агента в чате осуществляется через бота, подключённого к чатам через MG Bot API по постоянному соединению (WebSocket). Через это соединение бот получает поток событий обо всём, что происходит в чатах аккаунта.

Сервис реагирует не на весь поток, а только на ограниченный набор событий, которые действительно влияют на работу агента: новые сообщения в чате, назначения и закрытия диалогов. Всё остальное игнорируется.

Внешний формат событий описан в документации MG Bot API.

События, на которые реагирует агент

Самое частое событие — «новое сообщение» в чате. Но сообщения бывают разные, поэтому система сначала разбирает, от кого и какого типа пришло сообщение, и только потом решает, как с ним поступить. Так одно техническое событие превращается в одно из нескольких осмысленных:

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

Ответственный за диалог: кто сейчас ведёт переписку

Это ключевая идея всего раздела. У каждого диалога в любой момент есть ответственный, и от него зависит, может ли агент отвечать клиенту. Возможны три состояния:

• диалог на боте — ответственный это наш бот; агент имеет право отвечать клиенту;
• диалог на менеджере — ответственный это сотрудник (или другой бот); агент в переписку не вмешивается;
• диалог ни на ком — ответственный не назначен.

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

Это поведение по умолчанию, и его можно настроить: сценарий вправе запустить агента и на чужом диалоге — для фоновой работы или чтобы перехватить диалог себе (см. «Запуск агента, когда диалог не на боте»).

Если в чат приходит событие, а агент в этот момент уже работает по этому же треду, новый запуск прерывает предыдущий. Так система не допускает, чтобы один агент параллельно вёл одну и ту же переписку дважды.

Когда запускается агент

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

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

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

Здесь важное отличие между двумя видами шагов. Шаг, с которым работает агент, после выполнения по умолчанию может снова передать работу агенту. А шаг, запускаемый по событию, сам агента не будит: он лишь выполняет заданные в нём действия и завершается. Чтобы по событию агент действительно включился — например, написал клиенту, — внутри такого шага нужно явно добавить действие «Вызвать AI‑агента» (или «Перейти к другому шагу» с переходом на шаг, которым управляет агент).

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

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

Что происходит при ключевых событиях

Сообщение клиента. Сообщение сохраняется в истории треда. Ранее запланированные напоминания об ожидании ответа отменяются — клиент ответил, напоминать больше не нужно. Если диалог на боте – запускается агент.

Назначение диалога. Если диалог назначили на бота — агент принимает разговор и начинает работу: обычно именно здесь происходит приветствие клиента и вход в сценарий. Если диалог назначили на кого-то другого (например, на менеджера) — агент, наоборот, останавливается и больше не вмешивается в переписку. А если назначение произошло из-за действия самого агента по сценарию, событие игнорируется, чтобы не запускать работу повторно (см. «Защита от петель»).

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

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

Отложенное действие. Внутренний запуск конкретного шага сценария по таймеру через заданное время. Подробно механизм описан в разделе «Отложенные действия».

Как отменить автоматический запуск агента

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

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

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

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

Чтобы полностью отключить автозапуск агента на канале, нужны два таких шага:

• шаг на событие сообщения от клиента — без действия «Вызвать AI‑агента»;
• шаг на событие назначения диалога — без действия «Вызвать AI‑агента».

Вместе они перехватывают оба события, которые иначе запустили бы агента.

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

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

1. отправляет клиенту короткую отбивку, что сейчас нерабочее время;
2. ставит отложенное действие на начало рабочего времени — но уже для другого агента, настроенного на рабочее время.

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

Запуск агента, когда диалог не на боте

Правило «агент отвечает, только когда диалог на боте» — поведение по умолчанию, но его можно осознанно переопределить. У действия «Вызвать AI‑агента» есть настройка режима запуска, которая определяет, что произойдёт, если в момент срабатывания шага диалог ведёт не бот, а менеджер или другой бот.

Режимов три — от пассивного к активному:

• Назначенный ответственный (по умолчанию). Агент работает, только когда он ответственный за диалог. Если диалог ведёт менеджер или другой бот, агент не запускается — шаг просто не будит его. Остальные действия шага при этом всё равно отрабатывают (обновить состояние, снять напоминания, проставить тег). Это сохраняет прежнее поведение: на чужом диалоге агент молчит.
• Фоновая работа. Агент запускается, даже если он не ответственный за диалог. Забрать диалог себе он не может — ответственным остаётся менеджер или другой бот, — но написать клиенту и выполнить действия способен. Подходит для подготовки: классифицировать обращение, проставить теги, найти материалы в базе знаний, обновить состояние. Агент отрабатывает только один запуск: последующие события сами его не разбудят, пока их не обработает шаг с принудительным вызовом агента.
• Перехват диалога. Агент забирает диалог себе (переназначает на бота) и дальше работает как обычно — в том числе отвечает клиенту. Это видимое для менеджера действие и решение бизнес-уровня: его берут для явного перехвата — эскалация по триггеру, передача диалога боту, когда менеджер недоступен, или участок сценария, который обязан вести именно агент. Если забрать диалог не удалось, агент не запускается, а шаг отмечается ошибочным.

Режим выбирается прямо в действии «Вызвать AI‑агента», поэтому в одном шаге через условия можно сочетать разные режимы — например, при незакрытой претензии перехватывать диалог, а в остальных случаях ограничиваться фоновым разбором.

Команда менеджера для запуска агента

Менеджер может вручную подключить агента к разговору прямо из чата — служебной командой /agent. Она отправляется как приватное сообщение и не видна клиенту.

Это важная возможность, потому что через интерфейс системы вручную назначить диалог на агента сейчас нельзя. Команда /agent — единственный способ для менеджера передать конкретный диалог боту: она назначает диалог на агента, настроенного на канал этого чата, и запускает его. Это удобно, когда менеджер хочет, чтобы агент подхватил разговор, который до этого вёл человек. Если диалог при этом был на менеджере, бот сначала назначает его на себя, а затем запускается.

У команды есть два режима:

• Просто передать диалог агенту — /agent без параметров. Агент принимает разговор и сам решает, что делать дальше, исходя из переписки и доступных шагов сценария.
• Передать диалог и сразу дать задачу — /agent НазваниеШага, опционально с дополнительной инструкцией: /agent НазваниеШага текст инструкции. Тогда агент запускается сразу с выполнения указанного шага сценария, а инструкция добавляется как уточнение к задаче. Целевой шаг при этом должен быть настроен на событие «Команда от менеджера». Точное название шага для команды можно скопировать из карточки этого шага в интерфейсе.

Защита от петель

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

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

Выбор агента под событие

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

1. определяется канал, из которого пришла переписка;
2. среди запущенных агентов аккаунта ищется тот, что настроен на этот канал;
3. проверяется текущее рабочее время CRM и режим работы агента (всегда, только в рабочее время или только вне его);
4. берётся первый подходящий агент.

Если диалог назначен на бота, но подходящего агента сейчас нет (например, никто не настроен на это время), сервис снимает бота с диалога, чтобы переписка не «зависла» без ответственного и её мог подхватить менеджер.