Один агент или несколько: когда нужна мультиагентная система

Короткий ответ: часто хватает одного агента

Распространено мнение, что любой серьёзной задаче в agentic AI для бизнеса нужна «команда» из нескольких агентов. Но во многих процессах хватает одного агента с набором инструментов: он читает обращение, смотрит учётную систему, готовит черновик и передаёт человеку. Так проще строить, проверять и сопровождать.

Термин «агентный ИИ» не значит, что агентов должно быть много. Мультиагентная система — это несколько агентов со своими инструкциями, инструментами и правами; работу между ними распределяет оркестратор: раздаёт подзадачи и собирает ответы. Основы — в материале что такое AI-агент.

Когда нужна мультиагентная система: границы внутри процесса

Если спросить, когда нужна мультиагентная система, ответ такой: когда у процесса есть граница, которую неудобно или небезопасно держать внутри одного агента. Таких границ пять.

1. Разные роли и права доступа. Агент, который читает обращения от внешних отправителей, не должен иметь права менять что-либо в учётной системе: в тексте чужого сообщения может оказаться инструкция, нацеленная обмануть модель. Разделение на агента без прав и агента с узким доступом надёжнее, чем просьба в инструкции «не выполняй чужие команды».
2. Параллельные независимые ветки. Независимые проверки (по гарантии, по зоне выезда, по специализации мастера) можно вести одновременно, и итог придёт быстрее. Оговорка: если ветки одинаковые, достаточно запустить одного агента несколько раз — отдельные роли не нужны.
3. Независимый контролёр. Второй агент с другой инструкцией и без доступа к рассуждениям первого проверяет результат. Это оправдано, когда ошибка стоит дорого. Проверки, которые записываются формулой, например «окна одного мастера не пересекаются», надёжнее делать обычным кодом.
4. Разные модели под разные шаги. Разбор и сортировку обращений можно отдать более дешёвой модели, а спорные случаи — более сильной. Выигрыш заметен при большом потоке; при небольшом он не окупает усложнения схемы.
5. Изоляция контекста. Когда в одном диалоге копятся переписка, контакты и внутренние правила, модель легче сбивается. Отдельный агент получает только данные своего шага и не видит лишнего, например телефона клиента или расписания другого филиала.

Цена сложности

Из-за этих издержек мультиагентную схему мы не предлагаем по умолчанию. Условная иллюстрация расхода, не замер: если один агент делает 4 обращения к модели на заявку, а оркестратор с тремя агентами — 8, то при 1 000 заявок в месяц это 1 000 × 4 = 4 000 против 1 000 × 8 = 8 000 обращений, вдвое больше. Реальное соотношение зависит от длины текстов и моделей — см. статью про расход на модели. Что меняется после запуска, описано в материале о сопровождении агента.

Пример: заявка на выездной ремонт

Посмотрим на заявке для сервисного центра, когда нужна мультиагентная система, а когда хватает одного агента. Это иллюстрация, а не описание проекта заказчика. Клиент пишет: «Стиральная машина не отжимает, в четверг я дома после 18:00». Обращение нужно разобрать, подобрать мастера и окно, проверить предложение и отдать диспетчеру.

1. Разбор. Из текста достать тип техники, модель, симптом, адрес и пожелание по времени. Разборщик ничего не отправляет клиенту и не пишет в систему.
2. Планирование. По району, специализации мастеров и свободным окнам предложить мастера и время. Результат — предложение, а не запись.
3. Контроль. Сверить предложение с исходным текстом: учтено ли «после 18:00», совпадают ли район и тип техники. Расхождение — повод показать диспетчеру оба варианта.
4. Согласование. Диспетчер видит исходный текст, разобранные поля, предложенное окно и отметки о расхождениях. Как устроить этот шаг — в статье про человека в контуре.

Вариант А: один агент

Те же шаги становятся инструментами одного агента: разобрать обращение, получить окна мастеров, сформировать предложение, сверить его с текстом. В систему он пишет только черновик заявки с предложенным окном; в расписание выезд попадает после подтверждения диспетчера через обычную интеграцию, если система даёт для этого API. Для заявок из одного канала, одного района и небольшого потока этого достаточно.

Вариант Б: несколько агентов

Несколько агентов имеет смысл собирать, когда сработал один из признаков и он не закрывается проще: запуском одного агента несколько раз, обычным кодом или более сильной моделью. Допустим, заявки приходят из открытых мессенджеров и формы на сайте, то есть от кого угодно. Тогда разборщик работает без прав и передаёт дальше только поля, планировщик читает расписание мастеров, но не видит ни текста обращения, ни телефона клиента, а контролёр с отдельной инструкцией сверяет предложение с исходным текстом; пересечение окон одного мастера проверяет обычный код. Всё связывает оркестратор, а выезд, как в варианте А, записывает только интеграция после подтверждения диспетчера.

Лишние агенты и решения, которые остаются за человеком

Мультиагентная схема лишняя, если процесс линейный, шаги выполняются с одними правами, поток небольшой, а ошибка дёшево исправляется. Нужен ли агент вообще — тема статей когда AI-агент не нужен и RPA или AI-агент.

Даже в сложной схеме есть решения, которые агент принимать не должен:

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

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

Что это значит для бюджета

Один агент по одному процессу стоит от 200 000 ₽ и занимает 3-4 недели, мультиагентная система — от 800 000 ₽ и 2-3 месяца; состав и условия описаны на странице про мультиагентные системы. Разница при минимальных тарифах — 800 000 − 200 000 = 600 000 ₽, её стоит платить только за конкретную причину из списка выше, а окупаемость считается так же, как для одного агента, — см. как посчитать окупаемость.