ИИ-агент и автоматизация: где проходит граница

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

Где справляется правило и агент не нужен

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

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

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

Где правило упирается в тупик и нужен агент

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

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

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

Правило или агент: как решить по конкретной задаче

Таблица не заменяет разбор по существу, но быстро отсекает половину сомнений.

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

Что при этом делают роботы CRM

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

Агент работает рядом, а не вместо робота. Он ведёт диалог, а изменения в саму CRM вносит через действия. В Битрикс24 создаёт и меняет контакты, сделки и лиды, задаёт воронку, статус и ответственного. В Kommo двигает сделку по воронке, заполняет поля и хештеги из данных разговора. В amoCRM создаёт и меняет контакты и сделки, пишет саммари в заметку. В RetailCRM создаёт, редактирует и отменяет заказы, меняет ответственного и теги. Робот срабатывает по факту в карточке, агент по смыслу переписки, и оба в итоге меняют одни и те же данные с разных сторон.

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

Сколько стоит эта граница

Опорный поток для расчёта: 600 обращений в месяц, типичный объём для компании среднего размера. Диалог с агентом стоит около 15 ₽ независимо от того, сколько правил внутри него сработало: тысяча токенов стоит 1 ₽, а разбор смысла и жёсткая проверка условия ложатся в одну и ту же сумму.

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

Разделите поток на предсказуемое и на всё остальное

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

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

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