AI-агент для мессенджеров чаще всего буксует не на первом запуске, а на втором сценарии: квалификация лидов заработала, компания просит добавить запись на встречу, и выясняется, что проще переписать всё заново. Причина — в устройстве: агент собран как один сценарий, а не как набор независимых навыков. Библиотека навыков — это способ собирать агента из отдельных модулей, каждый из которых отвечает за одну задачу, и так устроен Дирижёр в 404ai: полусотня готовых навыков вместо одного жёстко зашитого дерева. Я разберу, что это меняет для бизнеса, как выбрать навыки под свой поток обращений, где модульность ломается и когда агент из навыков избыточен.
Один сценарий на всё ломается на второй задаче
Классический чат-бот пишется как один сценарий: дерево «если клиент сказал А — ответить Б». Пока задача одна, это работает. Расширить его новой задачей — значит переписывать логику, потому что новая ветка задевает существующие: вопрос о цене посреди записи на встречу уводит клиента не туда, а правка одной ветки ломает соседнюю. Для бизнеса это выглядит как «каждое изменение бота стоит как новый бот».
Библиотека навыков устроена иначе: каждая задача — квалификация лида, запись на встречу, реактивация базы, ответ на типовой вопрос — это отдельный навык, который подключается или отключается, не трогая остальные. Аналогия, которая здесь работает лучше всего, — приложения на телефоне: сломанное не обрушивает остальные, а новое устанавливается, а не встраивается хирургически в старое.
Навык — это условие включения, логика диалога и результат на выходе
Навык — не текст ответа, а связка из трёх частей: условие, при котором он включается, логика диалога внутри него и то, что он записывает на выходе. Навык «Квалификация лида» включается на входящем обращении без контекста, ведёт BANT-диалог (бюджет, полномочия, потребность, сроки) и на выходе создаёт карточку сделки с заполненными полями. Навык «Запись на встречу» включается, когда клиент уже квалифицирован, показывает свободные слоты и на выходе ставит событие в календарь.
Третья часть — результат на выходе — самая недооценённая. Навык, который хорошо поговорил с клиентом, но ничего не записал в CRM, для отдела продаж бесполезен: менеджер получит лида без контекста и начнёт квалификацию заново. Проверяя любого агента, я бы смотрел не на диалог, а на карточку, которая после него осталась.
Квалификация лида, персональные рассылки, апселл и кросселл, возврат ушедших клиентов, база знаний и FAQ, эскалация на оператора, запись на встречу, конверсионная аналитика, интеграция с CRM, агент партнёрской программы.
Навык выбирает оркестратор по смыслу сообщения, а не клиент по кнопкам
Маршрутизацию между навыками делает не клиент через кнопки меню, а оркестратор, который считывает намерение входящего сообщения. Клиент написал «сколько стоит» — включается навык ответов из базы знаний. Следующим сообщением спросил «а когда можно приехать посмотреть» — управление переходит к навыку записи на встречу, без того чтобы клиент выбирал раздел. Для клиента это один непрерывный разговор, хотя внутри работают разные навыки.
Где это ломается: оркестратор выбирает только среди известных ему навыков. Если сообщение не похоже ни на одну тему, правильное поведение — передать разговор человеку, а не подобрать «самый похожий» навык. Как устроена такая передача и почему её надо проектировать отдельно, разобрано в статье про эскалацию на оператора.
Новый сценарий добавляется без пересборки работающих
Когда нужно закрыть новую задачу — например, отвечать партнёрам об условиях и выплатах, для чего у Дирижёра есть отдельный навык, — не нужно переписывать уже работающие квалификацию, запись и ответы из базы знаний. Новый навык добавляется в библиотеку и получает доступ к тому же оркестратору.
Практическое следствие для бюджета: стоимость следующего сценария определяется содержанием нового навыка, а не объёмом переделок старых. Оговорка честная: изоляция навыков не отменяет проверки маршрутизации — об этом ниже.
Нужные навыки выводятся из пятисот своих обращений, а не из каталога
Выбирать навыки из каталога по названиям — способ получить работающий набор, который закрывает не ваш поток. Нужный список выводится из самих обращений.
Возьмите пятьсот последних входящих сообщений и разложите по темам вручную или полуавтоматически. Как правило, получается неравномерное распределение: несколько тем дают основную массу потока, а длинный хвост редких тем — остальное. Первые и есть кандидаты в навыки на старте.
Второй срез — по стоимости. Тема может быть редкой, но каждое обращение по ней отнимает у менеджера двадцать минут. Такие темы иногда выгоднее закрывать раньше массовых. Сопоставление частоты и трудоёмкости даёт порядок внедрения и одновременно метрику: сколько обращений и минут менеджеров должен забрать каждый навык.
Что происходит, когда два навыка претендуют на обращение
Ситуация возникает чаще, чем ожидают: клиент в одном сообщении спрашивает про статус заказа и про условия возврата. Формально подходят два навыка, и от того, как разрешается это столкновение, зависит впечатление от всего диалога.
Плохое решение — выбрать один и проигнорировать вторую часть. Клиент получает ответ на половину вопроса и вынужден спрашивать снова, что воспринимается как невнимательность. Второе плохое решение — попросить уточнить, что именно интересует: человек уже написал, что именно.
Работающее поведение — ответить на обе части последовательно, явно обозначив переход. Практически это означает, что маршрутизация должна уметь возвращать не один навык, а список, и держать очередь внутри одного диалога. Проверить это на демонстрации просто: задайте составной вопрос и посмотрите, что произойдёт.
Правка одного навыка без проверочного набора всё равно задевает соседние
Главное обещание модульности — правка одного навыка не задевает остальные. Выполняется оно, только если есть чем это проверить: сама по себе изоляция не гарантирует, что после правки маршрутизации обращения не начнут уходить не туда.
Минимальная защита — набор проверочных обращений по каждому навыку, который прогоняется после любого изменения. Двадцати-тридцати типичных сообщений на навык достаточно, чтобы поймать основные поломки. Прогон занимает минуты и делается перед выкладкой, а не после жалоб клиентов.
Отдельно стоит следить за условиями включения. Расширив условие одного навыка, легко забрать у соседнего часть обращений: формально всё работает, а клиенты по одной из тем начинают получать не тот ответ. Такие сдвиги видны в распределении обращений по навыкам — его полезно смотреть после каждой правки и сравнивать с тем, что было до неё.
На старте хватит трёх-четырёх навыков
Соблазн включить сразу всё понятен: библиотека готова, навыки есть, почему бы не закрыть весь поток. Это самый надёжный способ растянуть запуск на месяцы.
Каждый навык требует своей базы знаний, своих формулировок и своей проверки. Пятьдесят навыков — это пятьдесят наборов материалов, которые кто-то на стороне компании должен собрать и подтвердить. Работа не техническая, а содержательная: цены, условия, правила записи знает бизнес, а не подрядчик. Что и как класть в базу знаний, разобрано в статье о базе знаний для AI-агента.
Мой совет — стартовать с трёх-четырёх навыков, закрывающих основную массу обращений. Через месяц работы станет видно, какие темы чаще всего уходят человеку, и следующие навыки выбираются по этому списку, а не по предположениям. Такой порядок нередко приводит к другому набору, чем тот, что казался очевидным на старте. По срокам на странице продукта ориентир такой: базовый сценарий из квалификации, записи и ответов на частые вопросы запускается за 3–5 рабочих дней, сложные конфигурации с несколькими каналами и своими навыками — от 2 недель.
Чего библиотека навыков не умеет
Библиотека навыков — не конструктор без ограничений. Каждый навык опирается на конкретную базу знаний и сценарий, которые нужно один раз загрузить и подтвердить; без этого навык не появляется из воздуха. Оркестратор маршрутизирует по намерению внутри уже известных навыков — принципиально новую задачу, для которой навыка нет, он не выдумает сам, такой навык собирается явно. И модульность не спасает от плохих исходных данных: если в базе знаний противоречивые цены, аккуратно изолированный навык будет аккуратно называть разные цены.
Когда агент из навыков избыточен
Есть случаи, где я бы не собирал агента из библиотеки навыков вовсе.
Одна задача, которая не будет расти. Если нужен только приём заявок с сайта с тремя вопросами, простая форма или короткий сценарий обойдутся дешевле и надёжнее. Модульность окупается, когда задач несколько или они будут добавляться.
Обращений мало. Если в мессенджеры приходит несколько сообщений в день и менеджер отвечает на них за минуты, агент не сэкономит ничего, кроме ночных часов. При тарифе 2 ₽ за диалог сам агент недорог, но настройка навыков и поддержка базы знаний потребуют времени людей, и оно окупится не везде.
Каждый разговор уникален. Сложные продажи, где вопрос клиента требует расчёта инженера или решения юриста, навыками не закрываются. Агент здесь может принять обращение и собрать контекст, но не ответить.
Метрика навыка — доля обращений, закрытых без человека
Что это меняет в решении: выбирать агента для мессенджеров стоит не по списку того, что он «умеет», а по тому, насколько дёшево в нём добавить и изменить следующую задачу. Проверить это на демонстрации просто: задайте составной вопрос, попросите добавить новый сценарий и спросите, что придётся перепроверять после правки. Один из навыков библиотеки разобран отдельно — AI-агент партнёрской программы; каталог навыков и условия пилота — на странице Дирижёра.
На своих данных проверка выглядит так: разложите пятьсот последних обращений по темам, выберите три-четыре навыка на старт и для каждого запишите метрику до запуска — долю обращений по теме, закрытых без участия менеджера, и долю переданных человеку с полным контекстом. Если через месяц эти цифры не сдвинулись, дело не в количестве навыков, и добавлять новые рано: сначала нужно чинить базу знаний и маршрутизацию тех, что уже работают.
