> For the complete documentation index, see [llms.txt](https://docs.suvvy.ai/ru/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.suvvy.ai/ru/deistviya/multiagentnost/pereklyuchenie-aktivnogo-bota.md).

# Переключение активного агента

## Описание работы

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

### Организация работы с разными типами клиентов

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

1. Мы могли бы сделать это все на одном агенте, описав ему в инструкции, что он сначала должен определить статус клиента, далее в зависимости от статуса давать соответствующие ответы, но в этом случае у нас инструкция для агента была бы сильно перегружена, а это приведет к следующим последствиям:
   * Повышение вероятности, что агент будет путаться, и давать информацию не соответствующую статусу клиента;
   * Ответы будут более дорогие, так как инструкция у агента имеет описание всех бизнес-процессов, а еще и указаний на необходимость определения статуса клиента;
   * Сложная поддержка такой большой инструкции;
2. Мы разделяем задачу на 3 подзадачи:

   * Определить статус клиента;
   * Работа с клиентами;
   * Работа с будущими клиентами;

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

   * Агент "Секретарь", у него одна задача: определить статус клиента и далее переключить диалог на соответствующего агента;
   * Агент "Работа с клиентами", имеет описание бизнес-процесса только по работе с действующими клиентами и ничего не знает о задачах секретаря или менеджера работы с будущими клиентами;
   * Агент "Работа с будущими клиентами". Аналогично, имеет описание только своих задач.

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

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

## Организация работы компании с несколькими филиалами

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

Но есть компании, которым в принципе не обойтись без реализации схемы с несколькими агентами. Это компании, которые используют интеграцию с УС, имеют несколько филиалов и один входящий канал связи, поскольку интеграция построена на уникальном идентификаторе филиала и для каждого филиала создается свой агент, связанный с филиалом в УС. А если у компании один входящий номер, то требуется кто-то, кто будет определять, на какой филиал надо переключить клиента. То есть обязательно нужен дополнительный агент "Администратор". Ниже на примере рассмотрим создание такого агента "Администратор" для компании, использующей интеграцию с УС.

### Создание агентов

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

<figure><img src="/files/GsD7HxZ1WumGpp4wXbUA" alt=""><figcaption></figcaption></figure>

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

<figure><img src="/files/29bkBVhF8xmdCvdo1wGM" alt=""><figcaption></figcaption></figure>

### Создание действий для реализации переключения активного агента диалога

В агенте "Администратор" переходим на закладку "Действие" и для **каждого филиала** создаем свое действие для переключения активного агента:

<figure><img src="/files/UsXzpcx9Fb1YRMugH8Fb" alt=""><figcaption></figcaption></figure>

### Добавление шага

Внутри **Действия** можно вызывать последовательность действий, используя разные типы вызовов, поэтому это называется шагами.

Нам необходимо добавить шаг и выбрать тип шага "**Переключение действующего агента**":

<figure><img src="/files/H4Jk1iJB1G3kDYjpIjFi" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/iE33DoxmXkFYmr09N0qo" alt=""><figcaption></figcaption></figure>

**Название функции** - это название функции, которое будет видеть агент. Данное название указывается на английском без пробелов. Название должно отображать общий смысл действия.

**Описание функции** - более подробное описание смысла действия. По данному описанию Савви будет понимать, когда ее нужно вызывать.

При заполнении формы шага ваша задача выбрать агента, на которого будет переключен диалог, и выбрать агента для ответов:

<figure><img src="/files/Tph8w0aJCmG2Y4RC45Mj" alt=""><figcaption></figcaption></figure>

### Выполнение переключения активного агента

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

<figure><img src="/files/wvFRSJ7wPlThHuwBWVvw" alt=""><figcaption></figcaption></figure>

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

<figure><img src="/files/WkOBQWfiyzovXZ5Ich5L" alt=""><figcaption></figcaption></figure>

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

В описание действия добавляем информацию, что передать в аргумент и добавляем аргумент.

<figure><img src="/files/SiO1i4F0VmYjDShRHDq3" alt=""><figcaption></figcaption></figure>

Назначаем аргумент в разделе **Переменные действия**:

<figure><img src="/files/5kJjtCn9Q9jcfvEH72I8" alt=""><figcaption></figcaption></figure>

### Анализ работы агента

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

<figure><img src="/files/2eSQGyeqJIn5gydQLPYw" alt=""><figcaption></figcaption></figure>

На представленном примере видно, что диалог ведется с агентом-администратором. После выбора филиала произошло переключение на агента "Филиал 1". При переключении диалога было передано краткое содержание диалога агента "Администратор" в переменной `user_message`, и дальше уже отвечает агент "Филиал 1".

## Порядок подключения CRM-каналов

*Правильное подключение выглядит следующим образом:*

* **Агент-администратор** — подключён канал, включены ответы, выключены дополнительные функции, например заполнение сделки
* **Агент, на который переключаем** — подключён канал, выключены ответы, включены дополнительные функции

{% hint style="success" %}
Данная схема подключения актуальна для CRM-систем [Битрикс24](/ru/kanaly/crm-sistemy/bitriks24.md), [amoCRM](/ru/kanaly/crm-sistemy/amocrm.md), [Kommo](/ru/kanaly/crm-sistemy/kommo.md).
{% endhint %}

## Порядок подключения остальных каналов

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

*Общее правило такое:*

* на агенте-администраторе подключён канал общения
* на агенте-сотруднике подключены функции

> ***Например**:*
>
> * 1 агент подключен только к WhatsApp — отвечает на сообщения клиента
> * 2 агент подключён только к Yclients — записывает клиента на сеанс


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.suvvy.ai/ru/deistviya/multiagentnost/pereklyuchenie-aktivnogo-bota.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
