Мультиагентная система vs один ИИ-бот: когда нужно что
Каждую неделю приходят запросы вида «нам нужен ИИ-агент для продаж». В половине случаев под этим подразумевается один чат-бот с подключённой базой знаний. В другой половине - система из 5-10 связанных компонентов, которая принимает заявку, квалифицирует лид, поднимает историю по CRM и формирует ответ менеджеру. Это два разных продукта с разной ценой, сроками и сложностью.
Разберём, в чём принципиальная разница и как понять, что нужно вам.
Что такое «один ИИ-бот»
Один агент - это одна LLM с одним системным промптом, одним инструментом (например, поиск по базе) и одним выходом (текст в чат). У него нет состояния между вызовами, нет ролей, нет внутренней координации.
Типичные задачи для такой архитектуры:
- Ответы на FAQ
- Первичная квалификация заявок по простым критериям
- Генерация контента по шаблону
- Извлечение данных из текста
Главное достоинство - простота. Один промпт, один деплой, один источник ошибок. Если что-то не работает - понятно, где смотреть.
Главное ограничение - потолок сложности. Как только задача требует разных «режимов мышления» (классификация, потом извлечение, потом генерация с проверкой), один промпт начинает тонуть. Модель путается в инструкциях, теряет фокус, выдаёт неоднородные результаты.
Что такое мультиагентная система
Мультиагент - это несколько специализированных агентов, каждый со своей ролью, инструментами и зоной ответственности. Между ними сидит оркестратор: он маршрутизирует задачи, собирает результаты, принимает решения о следующих шагах. Каждый такой агент работает внутри агентного харнесса - обвязки, которая даёт модели инструменты, память и права.
Простая аналогия - отдел из специалистов. Есть аналитик, есть копирайтер, есть проверяющий. Если посадить одного человека и сказать «делай всё» - он будет переключаться и совершать ошибки. Если разделить роли и поставить координатора - каждый делает своё хорошо.
В технике это выглядит так:
Orchestrator
├── Classifier agent (определить тип запроса)
├── Retrieval agent (поднять контекст из базы/CRM)
├── Generator agent (сформулировать ответ)
└── Validator agent (проверить факты и тон)Каждый агент - отдельный вызов модели со своим промптом, своим набором инструментов и своей температурой. Оркестратор решает, кого звать и в каком порядке.
Когда хватает одного агента
По моему опыту, один агент достаточен, если выполняется три условия:
- Задача однородная. Все запросы решаются одним способом - посмотрел контекст, ответил.
- Контекст помещается в окно. Вся нужная информация (FAQ, регламенты) умещается в RAG из одной коллекции.
- Нет проверок. Не нужно валидировать ответ, не нужно эскалировать сложные случаи, не нужно вызывать внешние действия.
Пример из практики - How2AI, антиспам-бот в каналах. Задача однородная: поступает сообщение, надо понять, спам это или нет, и удалить если да. Один агент с одним промптом, 100% точность на тестовом наборе из 50 сообщений, развёрнуто за неделю.
Если ваша задача укладывается в эти три критерия - не усложняйте. Мультиагент здесь будет медленнее, дороже и без выигрыша в качестве.
Когда без мультиагента не обойтись
Мультиагентная архитектура нужна, когда появляется хотя бы одно из:
- Разные типы запросов с разной логикой обработки. Например, в продажах: первичный лид, тёплый клиент с историей, технический вопрос, возврат. Это четыре разных пайплайна.
- Действия с внешними системами. Создать запись в CRM, обновить статус сделки, отправить уведомление в Slack. Каждое действие - отдельный инструмент, и решение «что вызвать» - отдельная задача.
- Проверки и валидация. Сгенерировали ответ - проверили на фактологию по базе. Сгенерировали черновик письма - проверили на соответствие tone of voice.
- Длинные цепочки рассуждений. Когда задача требует нескольких шагов, и каждый шаг зависит от результата предыдущего.
Пример - Olimpberry. ИИ-агент для младших менеджеров поддержки. Когда приходит вопрос от клиента, система:
- Классифицирует тип обращения (5 категорий)
- По нужной категории поднимает скрипт и базу знаний
- Смотрит историю клиента в CRM
- Формирует ответ для менеджера
- Проверяет ответ на соответствие политике компании
Это пять разных задач с разной логикой. Запихнуть их в один промпт - получить хаос. После разделения по агентам обращения младших менеджеров к старшим сократились на 90%.
«Главный признак, что пора в мультиагент - когда системный промпт одного агента переваливает за 500 строк, а качество ответов всё равно скачет от запроса к запросу. Это не лечится более длинным промптом. Это лечится разделением на роли.» Богдан Шишкин, основатель Articortex
Цена усложнения
Мультиагент стоит дороже в разработке и поддержке. Конкретные цифры по моему опыту:
| Параметр | Один агент | Мультиагент (5-7 ролей) |
|---|---|---|
| Срок разработки | 1-3 недели | 4-8 недель |
| Бюджет (от) | 200 000 ₽ | 600 000 ₽ |
| Инференс в проде | 1x | 3-5x |
| Время отклика | 2-5 сек | 8-20 сек |
| Сложность поддержки | низкая | средняя |
Цифры приблизительные и зависят от конкретного проекта. Но порядок такой: мультиагент стоит в 3 раза больше денег и в 3 раза больше времени отклика. За это вы получаете возможность решать задачи, которые одному агенту не по силам.
Если задача решается одним агентом - мультиагент это переплата.
Где обычно ошибаются
Ошибка 1: начинают с мультиагента «на вырост». Логика «давайте сразу заложим архитектуру под будущее» приводит к тому, что проект тонет в сложности на старте. Правильно - начать с одного агента, упереться в его границы, потом разделять.
Ошибка 2: оркестратор как «ещё один LLM». Часто оркестратор делают через ту же модель, что и агенты. Получается медленно и дорого. По моему опыту, оркестрация хорошо ложится на детерминированный код (n8n, TypeScript) - нет смысла платить за LLM-вызов, чтобы выбрать одну из пяти веток if-else.
Ошибка 3: нет общего состояния. Агенты дёргают друг друга, но не делятся контекстом. Каждый раз генерируют ответ с нуля. Решается общим объектом состояния, который оркестратор прокидывает через всю цепочку.
Ошибка 4: нет наблюдаемости. В мультиагенте без логов и трейсов невозможно понять, где сломалось. Минимальный must-have: лог каждого вызова с входом, выходом, моделью, временем. Идеально - отдельный UI для просмотра трейсов (я использую LangSmith или собственный дашборд на n8n).
Как принять решение
Короткий чеклист. Если на 4+ вопроса «да» - вам нужен мультиагент. Иначе - один агент.
- Запросы делятся на 3+ типа с разной логикой обработки
- Нужно вызывать действия в CRM/ERP/других системах
- Нужна проверка фактов или политики в ответе
- Контекст не помещается в одну коллекцию RAG
- Один агент уже пробовали и упёрлись в качество
- Готовы к бюджету от 600 000 ₽ и срокам 1.5+ месяца
Что дальше
Не уверены, какая архитектура подойдёт вашей задаче - приходите с описанием процесса. Часто после 30 минут разговора становится понятно, что хватит одного агента и бюджета от 200 000 ₽. Иногда наоборот - за «простой ботик» прячется система на 6 ролей.
Грубая оценка - на странице калькулятора. Предметный разговор - через /contacts.
Термины: RAG · MCP · n8n · Оркестрация · ИИ-агент
См. также: