Шаги сценария

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

Скопировано

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

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

Из чего состоит шаг

У каждого шага одни и те же составные части:

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

Шаг бывает двух видов по тому, кто его запускает: шаг, с которым работает сам агент (агент выбирает его во время разговора), и шаг, запускаемый по событию (его дёргает система — на сообщение, на сигнал, по таймеру). Это разделение подробно описано в разделе «Когда запускается агент».

На какие события можно настроить шаг

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

• Сообщение от клиента — клиент написал в чат. Как только такой шаг создан, система вызывает его на каждое входящее сообщение клиента, поэтому почти всегда нужно через «Условия срабатывания шага» задать, когда именно он должен срабатывать: например, проверять вхождение определённого слова в текст сообщения или ограничивать шаг сообщениями только от определённых клиентов. По умолчанию сообщение клиента само будит агента (если диалог на боте), и шаг на это событие позволяет переопределить это поведение (как именно устроен этот порядок — в разделе «Как отменить автоматический запуск агента»).
• Назначение диалога — диалог переназначили на нового ответственного. Событие срабатывает на любое назначение — на агента, на другого бота или на менеджера. По умолчанию система запустит агента, только если диалог в итоге назначен на самого агента (диалог на боте), — это типичный «стартовый» запуск, когда агент приветствует клиента и входит в сценарий; если же диалог ушёл другому ответственному, агент в работу не вступает. Шаг с этим событием полезен именно тем, что ловит в чате все назначения подряд, — на нём можно выстроить более сложную схему распределения диалога.
• Закрытие диалога — диалог завершён. По умолчанию агент при этом очищает контекст переписки. Шаг на это событие нужен, чтобы доделать что-то напоследок: сбросить оставшиеся напоминания, проставить теги, зафиксировать итог. Важная тонкость: если диалог закрыл сам агент действием по сценарию, такие шаги не запускаются — это защита от петель (см. «Защита от петель»).
• Отложенное действие — запуск шага по таймеру через заданное время. Это не событие из чата, а внутренний механизм: он возвращает агента к работе спустя нужный интервал времени. Основное применение — напоминания и продолжение разговора, когда клиент молчит (подробно — в разделе «Отложенные действия»).
• Сообщение от менеджера — в чат написал сотрудник. Агент на это обычно не отвечает, но сообщение сохраняется в истории, чтобы он учитывал его как часть разговора. Шаг на это событие позволяет отслеживать определённые сообщения со стороны менеджера и запускать в ответ фоновые действия агента.
• Команда от менеджера — служебная команда /agent в чате. Это единственный способ вручную силами менеджера запустить агента или вернуть ему работу. Шаг на это событие выступает целевым шагом, который менеджер запускает командой /agent НазваниеШага (подробно — в разделе «Команда менеджера для запуска агента»).
• Отправка сообщения клиенту — отправлять сообщения агент умеет сам, для этого в сценарии ничего настраивать не нужно. Но если на каждую такую отправку нужно выполнять дополнительные действия, для этого и служит это событие: поля и действия вашего шага подмешиваются к самой отправке. Пока агент формулирует ответ, он заодно заполняет поля шага — отдаёт дополнительные данные прямо в момент отправки (например, какой тип сообщения он отправляет), — а сразу после отправки выполняются действия шага, причём без отдельного запуска агента, а значит и без дополнительной платы. На этом, например, строят гибкую систему напоминаний в чате (подробнее — в разделе «Отложенные действия»).
• Реакция на сигнал — срабатывает, когда значения сигналов совпали с заданными условиями. Сами эти условия задаются через «Условия срабатывания шага» — тот же механизм условий, что и у обычных шагов. Если в условиях кроме значений сигналов указаны и другие проверки, они тоже должны выполняться в момент срабатывания сигнала, — иначе шаг не запустится. Применяется для автоматических реакций на состояние переписки и перехвата поведения: например, при сигнале «клиент раздражён» подмешать агенту инструкцию предложить оператора (подробно — в разделе «Сигналы»).

Видимость и старт шага

Несколько переключателей определяют, когда шаг доступен агенту:

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

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

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

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

Повторный вызов и исправление данных

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

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

Типовые комбинации переключателей

Чаще всего встречаются несколько устойчивых сочетаний — их удобно держать как готовые рецепты:

Стартовый шаг (точка входа в сценарий) обычно совпадает с первой строкой таблицы: центральный шаг, доступный всегда и не скрывающийся, дополнительно помеченный как стартовый.

Условия срабатывания шага

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

Подробно про условия — в разделе «Условия шагов».

Описание шага

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

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

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

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

Данные шага

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

Поле данных добавляется в форме «Добавление данных» и задаётся такими настройками (в порядке формы):

• «Название поля» — короткое имя поля, понятное и очевидное для агента;
• «Тип поля» — строка, число, телефон и другие, в том числе специальные типы, связанные с данными CRM (способ оплаты, тип доставки и т. п.);
• варианты (кнопка «Добавить вариант») — если поле принимает одно из заранее заданных значений; у каждого варианта есть своя колонка «Описание»;
• «Инструкция для AI-агента» — главный текст поля: что это за данные и как их распознать (это и есть та инструкция, по которой агент решает, что класть в поле);
• «Примеры вопросов» — формулировки, которыми агент запрашивает данные у клиента. По сути это инструкция для агента с высоким приоритетом, но видит он её только в один момент: когда поле помечено обязательным и его ещё нет в данных, которые агент принёс при вызове шага;
• «Подсказка для валидации поля» — правила, как обработать и проверить введённое значение (формат данных);
• «Обязательное поле для заполнения AI-агентом» — переключатель: без обязательных данных шаг не доведёт работу до конца;
• «Множественный ответ» — переключатель: если в поле может попасть сразу несколько значений, а не одно.

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

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

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

Типы данных

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

Обычные — одно простое значение:

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

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

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

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

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

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

Сбор данных идёт порциями

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

Работает это так:

1. Агент видит шаг и понимает по описанию, что нужно сделать.
2. Вызывает шаг с теми данными, которые уже знает из переписки, — может и вовсе без данных.
3. Если обязательных данных не хватает, действия внутри шага не выполняются, а агент получает обратно информацию, чего именно недостаёт.
4. Агент спрашивает у клиента недостающее и вызывает шаг снова — уже с новой порцией данных.
5. Цикл повторяется, пока все обязательные данные не собраны. Тогда действия шага выполняются.

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

Отсюда практическое правило: чётко делите данные на обязательные и необязательные. Не стоит делать всё обязательным — это затягивает разговор и раздражает клиента.

Действия

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

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

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

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