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

Три признака, что один агент не справляется

Первый — контекст переполнен: в промпт приходится втискивать регламенты, историю переписки, данные из 1С и справочники, и модель начинает «забывать» начало. Второй — конфликт ролей: агент одновременно должен быть строгим валидатором и гибким собеседником, а эти режимы требуют разных инструкций и температуры. Третий — отсутствие проверки: результат некому оспорить, и ошибка уходит в CRM или в документ без ревью.

Есть и четвёртый сигнал — экономический. Если один агент даёт 70% качества, а процессу нужно 95%, доработка промпта быстро упирается в предел, и разделение ролей оказывается дешевле бесконечного тюнинга.

Архитектуры: оркестратор, роли, общая память

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

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

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

Российская практика: где это уже окупается

В российских внедрениях мультиагентность чаще всего появляется в трёх местах. Первое — обработка входящих документов: OCR-агент распознаёт скан, агент-экстрактор вытаскивает реквизиты, агент-валидатор сверяет их с данными 1С, а спорные случаи уходят оператору. Второе — поддержка продаж: один агент ищет по базе знаний и прайсам, второй проверяет остатки и условия поставки, третий готовит коммерческое предложение. Третье — внутренний ассистент по регламентам, где поиск, цитирование и проверка актуальности версии документа разделены.

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

Практические шаги внедрения

Начните с одного процесса и зафиксируйте метрику: доля корректно обработанных заявок, время цикла, стоимость обработки одного случая. Затем вынесите в отдельного агента самую шумную операцию — обычно это извлечение данных или поиск, — и сравните результат с базовым. После этого добавьте критика с формальными правилами: он не «думает», а проверяет поля, суммы и ссылки на источники. И только когда схема стабильна, масштабируйте на смежные процессы, сохраняя журнал решений и возможность ручного вмешательства.

Отдельно заложите контур оценки: набор тестовых кейсов с эталонными ответами, который прогоняется после каждого изменения промптов или модели. Разворачивать всё это лучше на приватном контуре — данные из 1С, CRM и внутренних регламентов не должны уходить во внешние API. Локальные модели плюс собственный оркестратор дают контроль над версиями, логированием и стоимостью.

Как мы можем помочь

Мы в АПС проектируем и внедряем мультиагентные системы под конкретные процессы: определяем, где действительно нужны несколько агентов, собираем оркестрацию и общую память, подключаем приватные LLM и интеграции с 1С/CRM, настраиваем логирование и метрики качества. Начинаем с пилота на одном процессе, чтобы вы увидели результат до масштабирования. Обсудить проект.