Слово «мультиагентная система» звучит солидно, и подрядчики охотно его используют: несколько ИИ-агентов, каждый со своей ролью, общаются между собой и решают задачу сообща. В презентации это выглядит убедительно. На практике большинство задач малого бизнеса решается одним агентом с хорошими инструментами, а мультиагентная архитектура добавляет стоимость, задержки и новые точки отказа. Но есть ситуации, где без неё действительно не обойтись.
Эта статья — о том, как отличить одно от другого. Когда одного агента мало, как выглядит разумная мультиагентная схема и по каким признакам понять, что проект переусложнён.
Что такое мультиагентная система на понятном уровне
Один агент — это языковая модель плюс набор инструментов: доступ к CRM, почте, базе данных, калькулятору. Он получает задачу, планирует шаги, вызывает инструменты и выдаёт результат.
Мультиагентная система — это несколько таких агентов, у каждого из которых своя роль, своя инструкция и свой набор инструментов. Один разбирает входящие письма, другой проверяет остатки на складе, третий пишет ответ клиенту, четвёртый контролирует, что ответ не нарушает правила. Их работу координирует либо агент-диспетчер, либо заранее заданная схема передачи задач. Фреймворки для этого — LangGraph, CrewAI и подобные.
Аналогия с командой подходит, но с оговоркой: агенты не умнее своих инструкций, а каждая передача задачи между ними — дополнительный вызов модели, который стоит денег и времени и может внести ошибку.
Когда одного агента действительно мало
Признаки, что задача выросла из одноагентной схемы.
Инструкция стала противоречивой
Если один агент должен и продавать, и проверять соблюдение юридических ограничений, и писать коротко, и объяснять подробно, инструкция разрастается до десятка страниц, и модель начинает путаться. Разделение «один пишет, другой проверяет» снимает конфликт ролей.
Слишком много инструментов
Когда агенту доступны тридцать разных действий, он чаще ошибается с выбором. Ориентир из практики: больше 10–15 инструментов у одного агента — повод подумать о разделении по доменам, например «всё про склад» и «всё про клиентов».
Нужна независимая проверка
В задачах с деньгами, договорами и медицинскими данными нужен контролёр, который не участвовал в подготовке ответа. Агент-ревьюер с отдельной инструкцией «найди ошибки и нарушения» ловит то, что автор пропускает.
Части задачи можно делать параллельно
Если нужно одновременно обработать запрос к трём разным источникам — сайтам поставщиков, базе и почте — параллельные агенты экономят время ожидания.
Разные требования к модели
Классификацию писем можно делать дешёвой быстрой моделью, а составление сложного ответа — дорогой. Разные агенты — разные модели, что снижает счёт за API в несколько раз.
Типовые схемы, которые реально работают
В малом и среднем бизнесе хорошо приживаются три архитектуры.
Диспетчер и специалисты. Входящий запрос попадает к агенту-маршрутизатору, который определяет тип задачи и передаёт её одному из специалистов: по продажам, по поддержке, по бухгалтерским вопросам. Пример — единый Telegram-канал компании, куда пишут и клиенты, и сотрудники. Это самая частая и самая понятная схема.
Конвейер. Задача проходит последовательно через несколько агентов. Пример из документооборота: один агент распознаёт входящий счёт, второй сопоставляет с договором и заказом, третий формирует проводку и уведомление бухгалтеру. Каждый шаг проверяемый, и сбой локализуется легко.
Автор и критик. Один агент готовит результат — коммерческое предложение, ответ клиенту, черновик договора. Второй проверяет по списку требований и возвращает на доработку или пропускает. Два-три круга максимум, иначе получится бесконечный спор.
Схемы «общество агентов, которые свободно переговариваются и сами решают, кто что делает» выглядят впечатляюще в демонстрациях, но в бизнесе почти не используются: результат непредсказуем, а стоимость одной задачи может вырасти в десятки раз.
Пример: как это выглядит в реальном проекте
Возьмём агентство недвижимости, которое собирает объявления из множества Telegram-каналов и показывает клиентам подборки. Задача похожа на то, что мы в AiKrok делали в проекте Batumi Rent. Разложим процесс на роли.
- Сборщик читает каналы и отбирает сообщения, похожие на объявления. Простая задача — дешёвая модель или вообще правила без ИИ.
- Структуризатор превращает текст поста в карточку: район, цена, комнаты, этаж, контакт. Здесь нужна модель посильнее.
- Дедупликатор сравнивает новую карточку с существующими и решает, не повтор ли это. Часть работы — вектора и правила, часть — модель для спорных случаев.
- Уведомитель сопоставляет карточки с запросами клиентов и отправляет push.
Заметьте: из четырёх ролей только две требуют языковой модели, и ни одна не требует, чтобы агенты «обсуждали» что-либо между собой. Это конвейер с чёткими интерфейсами. Именно так и выглядит разумная мультиагентность. Подробнее о задаче — в статье про автоматизацию для агентства недвижимости.
Как не переусложнить: признаки и правила
Признаки, что проект уходит в избыточную сложность:
- в схеме больше пяти агентов, а задача — ответить клиенту на вопрос о доставке;
- агенты передают задачу друг другу по кругу, и никто не знает, сколько раундов будет;
- стоимость одной обработанной заявки выросла в несколько раз по сравнению с одноагентной версией;
- при ошибке невозможно понять, какой агент её допустил;
- подрядчик объясняет архитектуру дольше, чем бизнес-задачу.
Правила, которые помогают держать систему в рамках:
- Начинайте с одного агента. Разделяйте, только когда упёрлись в конкретное ограничение, а не заранее «на вырост».
- Фиксируйте схему передачи. Кто кому и что передаёт — записано заранее, а не решается моделью на ходу.
- Ограничивайте циклы. Любая петля «автор — критик» имеет максимум итераций.
- Выносите детерминированную логику из агентов. Если что-то решается правилом или запросом к базе, модели там быть не должно.
- Логируйте каждый шаг. Для каждой задачи должен быть понятный след: что увидел каждый агент и что решил.
Стоимость и скорость: о чём предупреждают редко
Каждый агент — это как минимум один вызов модели, а чаще несколько. Если одноагентная обработка заявки стоила условно одну единицу, конвейер из четырёх агентов будет стоить ориентировочно три-шесть единиц, а схема со свободным обсуждением — непредсказуемо. Задержка тоже складывается: четыре последовательных шага по пять секунд — это двадцать секунд ожидания для клиента в чате. Для фоновых процессов это неважно, для живого диалога — критично.
Поэтому в клиентских каналах стараются держать один агент на линии, а остальных — в фоне. О структуре затрат на агентов в целом — в статье о том, сколько стоит AI-агент.
Итог
Мультиагентная система — не признак зрелости проекта и не аргумент в пользу подрядчика. Это инструмент для конкретных ситуаций: конфликт ролей в инструкции, слишком много инструментов, потребность в независимой проверке, параллельная обработка или экономия на разных моделях. Если ни одна из этих ситуаций у вас не наступила, один агент справится лучше, дешевле и предсказуемее. А если наступила — выбирайте простую схему: диспетчер, конвейер или автор с критиком, с жёстко заданной передачей задач и логами на каждом шаге.
Если сомневаетесь, какая архитектура нужна вашей задаче, разумный первый шаг — описать процесс словами и показать его тому, кто сделает честную оценку. Мы на бесплатной консультации чаще говорим «вам хватит одного агента», чем наоборот.