Мультиагентная поддержка: как собрать и не переусложнить

Идея заменить один большой промпт на команду специализированных агентов перестала быть экзотикой: за 2024–2025 годы появились фреймворки, которые собирают такую систему из кубиков — LangGraph от LangChain, OpenAI Agents SDK, Microsoft AutoGen, CrewAI. Все они решают одну задачу: разбить обращение клиента на подзадачи, раздать их разным агентам и собрать ответ. Ниже — как это устроено, во что обходится и когда одного агента с инструментами хватит с запасом.

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

В классической схеме один LLM-агент* получает вопрос, вызывает нужные инструменты (поиск по базе знаний, API заказов, CRM) и отвечает. Проблема начинается, когда типов обращений много и они разные: возврат денег, технический сбой, вопрос по тарифу, жалоба. Один промпт, который умеет всё, раздувается, путается в инструкциях и хуже держит контекст.

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

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

Пошаговая сборка

Схема ниже нейтральна к фреймворку — принципы одинаковы что в LangGraph, что в Agents SDK.

1. Соберите типологию обращений. Выгрузите 200–500 реальных тикетов и разложите на категории. Если 80% приходится на 4–5 тем, именно они и станут вашими агентами. Остальное отправляйте человеку — не плодите агентов ради полноты.
2. Опишите роутер. Это самый дешёвый компонент: лёгкая модель, задача которой — вернуть категорию и уверенность. При низкой уверенности обращение идёт к человеку, а не угадывается.
3. Дайте каждому агенту инструменты, а не знания в промпте. Агент по заказам ходит в API заказов, агент по базе знаний использует RAG** поверх ваших документов. Заводить факты прямо в системный промпт — путь к устареванию и галлюцинациям.
4. Пропишите передачу управления (handoff). Агент должен уметь сказать «это не моё» и вернуть диалог оркестратору с кратким резюме, что уже выяснено. Без этого система застревает.
5. Встройте человека в контур. Определите триггеры эскалации: упоминание возврата денег выше порога, второй заход по той же проблеме, эмоциональные маркеры, юридические угрозы. Здесь автономность стоит осознанно ограничить.
6. Логируйте каждый шаг. Кто из агентов что вызвал, какой ответ вернул инструмент, где случился handoff. Без трассировки отладка мультиагентной системы превращается в гадание.
7. Тестируйте на реальных тикетах. Прогоните исторические обращения и сравните ответы агентов с тем, что отвечали операторы. Это ваш офлайн-бенчмарк до выката в прод.

Минимальный состав, с которого стоит начать

• роутер — классификация и порог уверенности;
• 2–3 агента-специалиста под самые частые темы;
• агент базы знаний с RAG для общих вопросов;
• оркестратор с правилами эскалации на человека.

Всё остальное — расширение, а не старт. Начинать сразу с десятка агентов означает отлаживать десяток источников ошибок одновременно.

Чем собирать: сравнение фреймворков

Возможности и условия меняются с релизами, поэтому детали и лицензии сверяйте в документации каждого проекта. На момент подготовки материала расклад выглядит так.

Единого «лучшего» здесь нет: LangGraph даёт максимум контроля ценой большего кода, CrewAI и Agents SDK — быстрее в прототипе. Выбор зависит от того, нужен ли вам явный граф переходов или достаточно свободной передачи между агентами.

Сколько это стоит

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

Способы удержать бюджет:

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

Кому это пригодится и кому нет

Пригодится, если у вас поток из тысяч обращений в месяц, они делятся на явно разные типы, у каждого типа своя система-источник (заказы, биллинг, тикет-система) и вам важно, чтобы каждый сценарий можно было менять отдельно, не ломая остальные. Пример: маркетплейс или SaaS, где вопросы по оплате, доставке и техподдержке требуют разных данных и разного тона.

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

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

* Агент — LLM, которая не просто отвечает текстом, а по ходу диалога сама решает, какие инструменты (API, поиск, функции) вызвать для выполнения задачи.

** RAG (retrieval-augmented generation) — подход, при котором модель перед ответом подтягивает релевантные фрагменты из вашей базы документов, вместо того чтобы полагаться на знания, зашитые при обучении.