Мультиагентная система ИИ: когда бизнесу нужен один агент, а когда несколько

На презентации легко нарисовать «отдел» из пяти ИИ-агентов: один принимает задачу, второй ищет информацию, третий анализирует, четвёртый проверяет, пятый собирает ответ. Схема выглядит убедительно. Иногда она действительно нужна.

Но каждый новый агент — не бесплатная роль в цифровой команде. Это отдельная инструкция, контекст, набор инструментов, права доступа, состояние, журналы и правила передачи результата. Вместе с возможностями растут задержка, стоимость и число мест, где процесс может сломаться.[1][2][3]

Поэтому решение по умолчанию простое: сначала один агент внутри явно заданного workflow. Переходить к нескольким стоит только тогда, когда разделение устраняет измеримую проблему — например, изолирует права, разводит независимые предметные области или даёт полезную параллельную работу.

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

Что считать мультиагентной системой

Несколько вызовов модели ещё не образуют мультиагентную систему.

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

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

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

Это различие важно. Иначе обычный конвейер из трёх ИИ-шагов называют «командой агентов», добавляют динамическую маршрутизацию и получают сложность, которая не решает никакой бизнес-задачи.

Один агент с инструментами — полноценная архитектура

Представим условный процесс обработки B2B-заявки.

Сайт, почта или Telegram передают обращение в workflow. Обычная логика проверяет контакты, ищет дубли и сохраняет исходный текст. Один агент получает очищенные данные, обращается к базе знаний, определяет потребность клиента и возвращает структурированный результат: тему, краткое резюме, недостающие сведения и черновик ответа. Затем код проверяет поля, создаёт запись в Bitrix24 или amoCRM и передаёт сообщение менеджеру на подтверждение.

Здесь один агент использует несколько инструментов, но сохраняет единый контекст и отвечает за один понятный результат. Разделять его на «агента-классификатора», «агента-аналитика» и «агента-копирайтера» обычно рано.

Один агент особенно уместен, когда:

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

Даже роли «планировщик», «исполнитель» и «проверяющий» не требуют трёх агентов автоматически. Microsoft рекомендует сначала проверить, может ли один агент выполнить задачу с условными инструкциями, единым контекстом и ограниченным набором инструментов.[2]

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

Когда несколько агентов действительно оправданы

После добавления второго агента появляется передача работы. Вместе с ней возникают новые вопросы: что передавать — весь диалог или резюме, где хранить общее состояние, кто заметит противоречие, как восстановить процесс после ошибки API и кто отвечает за итог.

Google Cloud отдельно отмечает, что мультиагентной системе нужны дополнительные механизмы оценки, безопасности, надёжности и управления стоимостью. Для каждого агента приходится задавать контекст и права, а для всей системы — строить устойчивую оркестрацию.[1] Microsoft добавляет задержки на передачах, синхронизацию состояния и новые сценарии отказа.[2][3]

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

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

1. Нужно жёстко разделить права и данные

Один агент не должен одновременно читать всю клиентскую базу, готовить платёж и подтверждать его выполнение. Если процесс пересекает разные контуры безопасности, отдельные агенты могут работать под разными техническими идентичностями и получать только необходимые данные.

Например, один агент анализирует заявку в CRM в режиме чтения. Второй работает с внутренним каталогом. Третий готовит предложение на основе уже проверенных данных, но не имеет доступа к исходной клиентской базе. Действия с финансовыми или юридическими последствиями подтверждает человек.

Такое разделение имеет смысл только при технической изоляции. Разные системные промпты с одним административным токеном не создают границу безопасности. Подход к ограничению операций подробнее разобран в статье о правах ИИ-агента в CRM.

2. Процесс пересекает независимые предметные области

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

Условный пример — подготовка ответа на сложный B2B-тендер. Технический агент работает с документацией продукта, коммерческий — с данными клиента и утверждёнными условиями, агент проверки сопоставляет черновик с обязательными требованиями. Центральный координатор собирает результат, а сотрудник утверждает финальную версию.

Ключевой признак здесь не «разные роли», а разные контракты: данные, инструменты, политики и ответственные команды действительно отличаются.

3. Задачу можно полезно распараллелить

Несколько агентов могут одновременно исследовать независимые направления: рынок, продукт, риски, конкурентов или разные группы документов. Это сокращает время только тогда, когда ветки почти не зависят друг от друга и могут быть объединены по понятным правилам.

Google Research проверил 180 конфигураций агентных систем. На параллелизуемой задаче централизованная мультиагентная схема заметно превзошла одиночного агента, а на последовательной задаче все проверенные мультиагентные варианты ухудшили результат. Авторы связывают разницу с декомпозируемостью задачи и стоимостью координации.[5]

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

4. Один агент стабильно путается в инструментах

По мере роста системы промпт обрастает условиями, а инструменты начинают пересекаться. Агент выбирает похожий метод API, вызывает лишние функции или пропускает важную политику. В такой ситуации специализация может улучшить управляемость.

Но сначала нужно исключить более простые причины:

• неясные названия и описания инструментов;
• слишком широкие функции вроде call_any_api;
• плохой поиск по базе знаний;
• передача лишнего контекста;
• отсутствие детерминированной маршрутизации;
• смешение нескольких бизнес-задач в одном запуске.

OpenAI рекомендует разделять агентов, когда следующей ветке действительно нужны другие инструкции, инструменты или политика.[4] Сам по себе длинный промпт ещё не доказывает необходимость мультиагентной системы.

5. Следующий специалист должен принять управление

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

Если специалист только выполняет ограниченную операцию — например, классифицирует документ или делает краткое резюме, — основной агент может остаться владельцем процесса и вызвать специалиста как инструмент. В документации OpenAI эти варианты разделяются как передача управления и «агент как инструмент».[4]

Когда несколько агентов мешают и какую схему выбрать

Мультиагентность не стоит вводить только ради организационной метафоры.

Чтобы каждый этап назывался агентом. Если порядок известен заранее, его надёжнее задаёт workflow. Модель не должна решать, кого вызвать следующим, когда это можно определить обычным условием.

Чтобы добавить критика. Проверяющий агент полезен, если у него есть независимый источник, формальная проверка или другой набор ограничений. Второй агент, читающий тот же текст и выражающий ещё одно вероятностное мнение, не гарантирует качество.

Чтобы обработать большой объём документов. Сначала проверьте разбиение, индексацию, фильтры доступа, поиск и сжатие контекста. Проблема retrieval не превращается автоматически в проблему числа агентов.

Чтобы повысить автономность. Больше агентов означает больше точек принятия решений, а не больше контроля.

Исследователи MAST проанализировали более 1600 трасс семи мультиагентных фреймворков и выделили 14 режимов отказа. Они относятся к проектированию системы, рассогласованию между агентами и проверке завершения задачи.[7] Это не статистика производственных инцидентов, но хороший сигнал: ошибки координации образуют отдельный класс.

Схема	Когда подходит	Что контролирует маршрут	Основной риск
Workflow с ИИ-шагами	Порядок известен заранее	Код или платформа автоматизации	Ошибка ИИ-шага без корректной валидации
Один агент с инструментами	Один домен, общий контекст, динамический выбор действий	Один агент в заданных границах	Перегрузка промпта и похожими инструментами
Координатор и специалисты	Несколько доменов, один итоговый владелец	Центральный агент или оркестратор	Ошибка декомпозиции и сборки результата
Передача управления	Специалист должен продолжить диалог по другой политике	Активный агент выбирает handoff	Циклы и неверная маршрутизация
Параллельные агенты и агрегатор	Независимые направления можно исследовать одновременно	Детерминированный запуск или координатор	Противоречивые результаты и высокая стоимость
Групповое обсуждение	Исследовательская задача, поиск гипотез	Менеджер диалога	Зацикливание и трудная воспроизводимость

Для большинства бизнес-пилотов, где несколько агентов всё же нужны, разумная отправная точка — центральный координатор. Он сохраняет ответственность за итог, выдаёт специалистам ограниченные задания и собирает структурированные ответы. В контролируемых экспериментах Google централизованные схемы также лучше сдерживали распространение ошибок, чем независимая параллельная работа без проверки.[5]

Но если маршрут известен, роль координатора должен выполнять код. Не нужно платить модели за решение, которое уже записано в таблице правил.

Как проверить один и несколько агентов на пилоте

Архитектуру лучше выбирать не по демонстрации, а по сравнению.

1. Зафиксируйте одну бизнес-задачу

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

2. Соберите тестовый набор

Используйте реальные обезличенные примеры: обычные, неполные, противоречивые, пограничные. Добавьте ошибки инструментов, недоступную CRM, устаревший документ, повторный запуск и запрос, который обязан перейти человеку.

3. Сначала создайте базовую версию с одним агентом

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

4. Добавляйте агента под конкретную гипотезу

Например: «отдельный технический агент уменьшит ошибки выбора документа» или «параллельная проверка трёх источников сократит общее время». Без гипотезы сравнивать нечего.

5. Выравнивайте условия

Обе архитектуры должны работать на одном наборе данных, с одинаковыми правами и критериями результата. Отдельно контролируйте число вызовов, токены и лимит шагов. В препринте 2026 года при одинаковом бюджете рассуждений одиночные агенты на проверенных многошаговых задачах соответствовали или превосходили мультиагентные схемы; часть заявленных преимуществ нескольких агентов объяснялась дополнительными вычислениями.[8]

6. Измеряйте не только качество текста

Для бизнес-пилота нужны:

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

7. Оставляйте несколько агентов только при измеримой выгоде

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

Anthropic сообщает, что в их исследовательской системе обычные агенты использовали примерно в четыре раза больше токенов, чем чат, а мультиагентная схема — примерно в пятнадцать раз больше. Компания связывает экономическую оправданность подхода с дорогими задачами, сильной параллелизацией и объёмом информации, который не помещается в контекст одного агента.[6] Эти цифры относятся к конкретной системе поставщика, но показывают, почему стоимость нужно считать на завершённую бизнес-операцию.

Условие	Решение по умолчанию
Маршрут можно описать заранее	Workflow, при необходимости с отдельными ИИ-шагами
Один домен и общий контекст	Один агент с ограниченными инструментами
Роли различаются только названием	Сначала один агент и тест
Есть независимые контуры прав и данных	Несколько изолированных агентов
Несколько команд владеют разными доменами	Мультиагентная схема с явными контрактами
Подзадачи независимы и выполняются параллельно	Сравнить параллельную схему с одиночной
Каждый шаг зависит от полного предыдущего контекста	Один агент или центральный координатор
Не определён проверяемый результат	Сначала доработать процесс, а не архитектуру

Вывод

Мультиагентная система ИИ нужна не тогда, когда в процессе можно придумать несколько ролей. Она нужна, когда между ролями существует реальная архитектурная граница: разные права, данные, владельцы, политики или независимые ветки работы.

По умолчанию стоит начать с одного агента внутри управляемого workflow, измерить качество, стоимость и задержку, а затем добавлять специалистов по одному. Агент должен становиться отдельным компонентом не потому, что получил должность на схеме, а потому, что у него изменился контракт.

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

Что такое мультиагентная система ИИ?

Это архитектура, в которой несколько ИИ-агентов с отдельными инструкциями, контекстом или инструментами координируют работу для достижения общего результата. Координация может быть последовательной, параллельной, централизованной или строиться на передаче управления.

Может ли один ИИ-агент выполнять несколько ролей?

Да. Один агент может менять режим работы, вызывать разные инструменты и проходить этапы планирования, выполнения и проверки. Отдельный агент нужен, когда меняются права, данные, политика, владелец результата или независимый контекст.

Сколько агентов использовать в первом пилоте?

Обычно одного. Исключение — заранее известная жёсткая граница безопасности или независимые домены, которые нельзя объединять. Каждый следующий агент должен добавляться под проверяемую гипотезу.

Мультиагентная система всегда работает лучше?

Нет. Она может выигрывать на параллелизуемых задачах и проигрывать на последовательных из-за передач контекста, дополнительных вызовов и ошибок координации.

Как считать стоимость системы ИИ-агентов?

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

Источники

1. Choose a design pattern for your agentic AI system — Google Cloud Architecture Center, проверено 10 августа 2026 года.
2. Один агент или несколько агентов — Microsoft Cloud Adoption Framework, проверено 10 августа 2026 года.
3. AI agent orchestration patterns — Microsoft Azure Architecture Center, проверено 10 августа 2026 года.
4. Orchestration and handoffs — OpenAI API documentation, проверено 10 августа 2026 года.
5. Towards a science of scaling agent systems: When and why agent systems work — Google Research, 28 января 2026 года.
6. How we built our multi-agent research system — Anthropic, 13 июня 2025 года.
7. Why Do Multi-Agent LLM Systems Fail? — Mert Cemri и соавторы, последняя редакция 26 октября 2025 года.
8. Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets — Dat Tran, Douwe Kiela, последняя редакция 11 апреля 2026 года.