Конструктор AI-ботов

У нас работает парк AI-ассистентов: они отвечают клиентам во ВКонтакте, на сайте и в Telegram, помогают записаться на приём или тренировку, а сложные случаи передают живому менеджеру. Боты разные — клиника, медцентр, беговой клуб, спортшкола — но внутри у них одна и та же технология. В этой статье разберём, как она устроена и почему мы перестали писать каждого бота с нуля.

Проблема: пять ботов — пять рукописных копий

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

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

Стало понятно: нужно не «делать ботов», а построить то, что их собирает.

Идея: конструктор плюс универсальный переходник

Технология стоит на двух вещах.

Первая — конструктор ботов (мы зовём его bot-kit). Это общая библиотека, в которой лежит вся логика: как принять сообщение, как понять запрос, как замаскировать персональные данные, как передать диалог менеджеру. На вход конструктор получает короткую анкету настроек конкретного бота — и собирает из неё готовый рабочий воркфлоу. Логика одна на всех; различия живут в анкете.

Вторая — универсальный переходник (bot-gateway). Системы записи у клиентов разные: у одной клиники медицинская информационная система «Реновация», у бегового клуба — CRM «МойКласс», у кого-то «Архимед». Чтобы не учить каждого бота всем системам сразу, между ботом и CRM стоит переходник. Боты говорят с ним на одном языке, а он уже знает, как разговаривать с конкретной системой — как розетка с набором адаптеров.

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

Главная идея: три независимые оси

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

Ось 1 — каналы. Где бот общается: ВКонтакте, виджет на сайте, Telegram, мессенджер MAX, почта. Любое сообщение из любого канала приводится к единому виду — внутреннему «конверту» с полями channel, user_id, text и контекстом ответа. Ядро бота не знает, пришло сообщение из VK или из веб-виджета: оно работает с конвертом. Поэтому добавить боту новый канал — это включить строчку в конфиге, а не переписать бота.

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

Ось 3 — уведомления. Как в дело включается менеджер. Карточка с кнопками «подтвердить / отменить» в Telegram, дублирование той же карточки в MAX, или просто уведомление о новом лиде без кнопок.

«Независимые» здесь — это главное слово. Меняешь одну ось — остальные не трогаются. Бот для бегового клуба и бот для клиники отличаются комбинацией значений по трём осям, а не разным кодом. Любая комбинация сразу даёт работающего бота.

Как выглядит один бот внутри

Под капотом у каждого бота — один и тот же понятный поток. Воркфлоу собирается в n8n; конструктор раскладывает его на 60–80 узлов, и для всех ботов их топология одинакова:

N каналов → нормализатор → конверт {channel, user_id, text, ...}
   ↓
проверка: оператор уже в диалоге? → согласие на обработку ПДн (опц.)
   ↓
антифлуд (rate-limit) → маскирование персональных данных
   ↓
AI-агент (LLM + системный промпт + память окна диалога)
   ↓
разбор маркера эскалации → карточка менеджеру (если нужна запись)
   ↓
ответ обратно в канал клиента → логирование

Две детали в этом потоке делают парк пригодным для медицины и спорта, где есть персональные данные:

Персональные данные — ФИО, телефон, дата рождения и даже имя из профиля ВКонтакте — прячутся перед отправкой в нейросеть. Модель видит токены вида {ФИО} и {ТЕЛ}, а оригиналы подставляются обратно только в ответ клиенту. В журналах всё хранится без персональных данных. Это требование 152-ФЗ, и оно встроено в технологию по умолчанию — про это у нас есть отдельный разбор.

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

Почему сборка детерминированная

Конструктор собирает воркфлоу детерминированно: один и тот же конфиг даёт байт-в-байт один и тот же JSON. Идентификаторы узлов и их координаты на холсте n8n считаются от имени бота и названия узла, а не генерируются случайно.

Звучит как мелочь, но это меняет работу. Когда мы правим конфиг и пересобираем бота, в git diff видно ровно то, что изменили, — а не шумную перетасовку случайных идентификаторов. Деплой идёт по принципу «прочитать с сервера → слить → записать»: он не трогает активный воркфлоу, сохраняет привязанные доступы к каналам и состояние диалогов. Сам конструктор написан на голом Node.js без единой внешней зависимости — нечему ломаться при обновлении окружения.

Логику правим в одном месте — в конструкторе. В папке конкретного бота лежат только его анкета, системный промпт и база знаний. Никакого кода. Поэтому правило простое: поведение всех ботов — в bot-kit, особенности одного бота — в его конфиге.

Что это дало на практике

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

Главное, что изменилось:

• Скорость. Новый бот — это часы на заполнение анкеты и подключение, а не недели разработки с нуля.
• Единое качество. Улучшили конструктор — пересобрали — улучшение появилось сразу у всех ботов. Один баг чинится один раз.
• Изоляция. Каждый бот — отдельный независимый воркфлоу. Если один остановится, остальные продолжают работать. Мы намеренно не складываем все яйца в одну корзину.
• Гибкость. Новый канал или новая CRM у клиента — точечная настройка, а не переписывание.

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

Если вам нужен чат-бот, который записывает клиентов и не теряет заявки, — напишите нам. Мы соберём его на той же технологии.