Мультиагентные системы в поддержке: кто заменит оператора

Классический чат-бот на сайте магазина отвечает по скрипту и на шаге «а если товар уже вскрыт» упирается в стену. Мультиагентная архитектура решает это иначе: вместо одной модели, которая пытается сделать всё сразу, задачу дробят между несколькими специализированными агентами. Один разбирает, чего хочет клиент. Второй лезет в базу знаний. Третий вызывает API и оформляет возврат. Четвёртый решает, пора ли звать живого человека. Крупные вендоры — от Salesforce с Agentforce до платформ на базе LangGraph и Microsoft Copilot Studio — уже продают такие связки под ключ, и это не демо, а рабочие внедрения.

Чем мультиагент отличается от обычного бота

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

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

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

Типовые роли в связке поддержки

• Роутер (классификатор) — определяет тип обращения: возврат, доставка, оплата, жалоба — и направляет дальше.
• Ретривер по базе знаний — ищет релевантные фрагменты в документации и регламентах, работает через RAG².
• Агент действий — вызывает внешние API: CRM, склад, платёжный шлюз. Именно он реально что-то меняет в системах компании.
• Проверяющий (гвардрейл) — сверяет ответ с политиками, ловит попытки выдать несуществующую скидку или пообещать невозможное.
• Эскалатор — оценивает уверенность и настроение клиента и решает, звать ли оператора.

Где это реально работает, а где ломается

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

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

Три типичных сбоя

1. Петля между агентами. Роутер отдаёт задачу ретриверу, тот не находит ответ и возвращает роутеру, и так по кругу. Лечится жёстким лимитом шагов и фолбэком на оператора.
2. Потеря контекста при передаче. Клиент назвал номер заказа в начале, а агент действий его не получил, потому что оркестратор не прокинул. Симптом — бот переспрашивает то, что уже сказали.
3. Галлюцинация в действии. Модель уверенно вызывает API возврата с выдуманным ID. Отсюда обязательность проверяющего агента и валидации на стороне бэкенда.

Сравнение подходов

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

С чего начать внедрение

Не пытайтесь сразу отдать агентам всё. Разумный порядок:

• Соберите статистику обращений первой линии и найдите два-три самых частых типовых сценария.
• Автоматизируйте сначала ответы без действий — на базе знаний. Здесь цена ошибки минимальна.
• Добавьте агента действий только на одну безопасную операцию (например, проверка статуса заказа) и обвесьте её логами.
• Введите жёсткий порог эскалации: если уверенность низкая или клиент раздражён — оператор.
• Меряйте долю решённых без человека обращений и долю повторных обращений после ответа бота — второй показатель важнее.

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

¹ Оркестратор — компонент, который управляет порядком вызова агентов и передачей данных между ними. Может быть отдельной моделью-«диспетчером» или заданным заранее графом переходов.

² RAG (Retrieval-Augmented Generation) — подход, при котором модель перед ответом подтягивает релевантные фрагменты из внешней базы, а не полагается только на знания, зашитые при обучении. Снижает выдумывание фактов.