Один агент в нескольких каналах: как развести поведение

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

Один агент, три разных ситуации

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

В Телеграме или на сайте агент ведёт разговор: задаёт уточняющие вопросы, ждёт ответ, может прислать кнопки. Под отзывом на Wildberries или Ozon это разовая публичная реплика: второго сообщения не будет, а читает его вместе с автором отзыва ещё и следующий покупатель. Инструкция «после ответа уточни у клиента дату доставки» в переписке работает, а под отзывом превращается в вопрос в пустоту. Разница в тоне тоже принципиальная: с раздражённым отзывом работают иначе, чем с вопросом в директе, и электронная почта требует более официального стиля, чем чат на сайте.

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

Как написать условие по техническому имени канала

Условие пишут прямо в тексте инструкции: «если {channel_name} равен wildberries_review — ограничься одним вежливым ответом без вопросов клиенту, если telegram_bot — можно уточнять детали и предлагать кнопки». Модель читает это правило вместе с остальной инструкцией и применяет его к каждому диалогу отдельно.

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

Канал	Значение channel_name
amoCRM / Kommo	amocrm, kommo
Битрикс24	bitrix
RetailCRM	retailcrm
GetCourse	getcourse
Telegram	telegram_bot
WhatsApp	whatsapp
MAX	max, max_bot
VK	vk
Instagram	instagram, instagram_comments
Facebook	facebook
Савви Виджет	widget
Jivo	jivo
Электронная почта	email, umnico_email
UseDesk	usedesk
HelpDeskEddy	helpdeskeddy
PlanFix	planfix
Omnidesk	omnidesk
Zoho	zoho_salesiq, zoho_teaminbox
Umnico	umnico
Wazzup	wazzup
Wildberries	wildberries_review, wildberries_question
OZON	ozon_review, ozon_question, ozon_chat
Яндекс.Маркет	yandexmarket_review, yandexmarket_chat
Авито	avito
ЦИАН	cian
Персональный канал (API)	custom
Голосовой агент	inbound_voice_call, outbound_voice_call
Тестовый чат и звонок в кабинете	test_chat, test_voice_call

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

1 Найдите живой диалог из нужного канала Раздел «История», фильтр по каналу: нужен диалог, где уже есть хотя бы одно сообщение от клиента.

2 Выгрузите экспорт диалога В шапке экспорта перечислены все параметры, которые канал передал агенту, вместе со значениями.

3 Возьмите точное значение channel_name Это и есть строка для условия в инструкции: переносите её буквально, без перевода на русский.

4 Проверьте пустые переменные Часть переменных приходит не из каждого канала: {email} есть в UseDesk и пуст в Telegram. На такой переменной нельзя строить обязательный шаг без запасного варианта.

Шаблоны: когда простого условия мало

Обычное условие в тексте инструкции — это фраза, которую модель читает вместе с остальными правилами и старается соблюдать. Шаблоны Liquid работают иначе: они собирают готовый текст инструкции ещё до того, как он попадёт модели, — с условием {% if %} и веткой выбора {% case %} / {% when %} по той же переменной channel_name.

Разница ощутима на объёме. Обычное условие оставляет в инструкции все ветки сразу: модели приходится читать варианты для чужих каналов на каждом ответе. Шаблон вырезает лишние ветки до отправки: агент из Ozon получает готовый текст с артикулами Ozon, без строк про Wildberries и Яндекс.Маркет. Короче итоговая инструкция: меньше токенов на каждый ответ, значит и дешевле диалог.

{% if channel_name == "ozon_question" %}
Отвечай коротко, без лишних вопросов: здесь нет диалога, только карточка товара.
{% elsif channel_name == "telegram_bot" %}
Можно уточнять детали заказа и предлагать кнопки с вариантами.
{% else %}
Отвечай нейтрально и без уточнений — канал не распознан.
{% endif %}

Функция шаблонов работает в режиме бета-тестирования, поэтому для двух-трёх каналов обычное текстовое условие остаётся проще и надёжнее. Разбираться со скобками {% %} и {{ }} стоит тогда, когда веток становится много и в текстовом условии инструкция раздувается сама на себя. О том, как вообще устроен текст инструкции и почему в него не кладут факты: в статье про написание промптов.

Почему инструкция для одной CRM не переносится в другую

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

В amoCRM сделка описывается переменной {lead_id}. В Битрикс24 сделки как единого объекта нет: есть пара {entity_type} и {entity_id}, тип и номер отдельно. {status_id} в Битрикс24 — строка вида C7:NEW, с указанием направления, в amoCRM — просто число. {chat_id} в Битрикс24 — число, в amoCRM — UUID.

	Битрикс24	amoCRM
Идентификатор сделки	{entity_type} + {entity_id}	{lead_id}
Формат {status_id}	строка C7:NEW	число
Формат {chat_id}	число	UUID
Источник обращения	{origin}, например telegrambot	{origin}, например com.wazzup.whatsapp

Условие вида «если {status_id} равен 80112233 — не предлагай скидку» написано под amoCRM и в агенте на Битрикс24 не сработает никогда: там в этой переменной строка, число там ни при чём. Разбор того, как CRM вообще передаёт данные в диалог и что можно вытащить в аргументы функций — в статье про чат-бота и CRM. Прежде чем переносить готовую инструкцию на другую систему, стоит выгрузить свежий экспорт диалога именно из неё: полагаться на совпадение переменных по аналогии не стоит.

Когда вместо условия заводить отдельного агента

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

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

Разделите инструкцию на общую часть и вставки по каналу

Разделите текст инструкции на то, что работает одинаково везде, и то, что зависит от канала: приветствие, длину ответа, допустимость кнопок и уточняющих вопросов.

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

Частые вопросы