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

После первого работающего ИИ-агента довольно быстро появляется следующая идея: а давайте разделим его на несколько.

Один будет планировать. Второй — искать информацию. Третий — проверять. Четвёртый — работать с CRM. Сверху поставим ещё одного, который будет ими управлять.

Технически такую систему собрать можно.

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

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

Разберём, где проходит эта граница и как принять решение до того, как пилот превратится в небольшую распределённую систему.

Сначала разделим workflow, одного агента и несколько агентов

В обсуждении ИИ эти понятия часто смешивают.

Workflow заранее задаёт маршрут. Получили заявку → проверили поля → определили категорию → создали сделку → поставили задачу. Отдельные шаги могут использовать языковую модель, но сама последовательность известна программе.

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

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

Google описывает single-agent как базовый паттерн и отдельно рекомендует начинать с него на раннем этапе разработки. Multi-agent появляется тогда, когда крупную задачу приходится разделять между специализированными агентами, потому что один агент уже плохо справляется с совокупностью обязанностей. При этом к системе добавляются отдельные требования к оценке качества, безопасности, надёжности, оркестрации и стоимости.[2]

То есть выбор выглядит не так:

один агент → два агента → пять агентов → стало лучше.

Скорее так:

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

Почему несколько агентов выглядят привлекательнее, чем работают

Идея понятна. В обычной компании сложную работу тоже делят между специалистами. Почему бы не сделать отдел из ИИ?

Проблема в том, что вместе со вторым агентом появляется не только новая специализация.

Появляется handoff — передача задачи.

Нужно решить:

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

Microsoft прямо относит к издержкам multi-agent архитектуры дополнительную координацию, синхронизацию состояния, рост количества модельных вызовов, задержку при передачах и новые поверхности безопасности.[1][4]

Получается важный практический критерий:

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

Если этого нельзя показать хотя бы на пилоте, разделять систему рано.

Когда одного агента достаточно

1. У процесса одна предметная область

Допустим, агент обрабатывает входящие B2B-заявки.

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

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

Microsoft отдельно предупреждает: разделение ролей само по себе не является достаточным основанием для multi-agent. Сначала стоит проверить, справляется ли один агент с нужными политиками, инструментами и контекстом.[1]

2. Всем шагам нужен один и тот же контекст

Если каждая следующая операция зависит от всей предыдущей истории, разрезать процесс особенно неудобно.

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

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

3. Все действия находятся в одном контуре прав

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

Сначала лучше ограничить сами инструменты.

Например, вместо универсального доступа к CRM дать функции:

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

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

4. Вы ещё проверяете саму ценность проекта

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

Главный вопрос намного проще:

решает ли эта автоматизация бизнес-задачу достаточно хорошо, чтобы её вообще развивать?

Если этот ответ ещё неизвестен, сложная оркестрация только увеличивает количество переменных в эксперименте.

Сначала полезнее получить baseline: один процесс, один агент, понятные инструменты и измеримый набор сценариев.

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

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

1. Между задачами проходит настоящая граница доступа

Представим, что один компонент работает с обращениями клиентов, другой — с внутренними финансовыми данными.

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

Microsoft называет security и compliance boundaries одним из прямых оснований для нескольких агентов.[1] AWS обращает внимание ещё на одну сторону: после разделения нужно защищать уже и сам обмен между агентами — проверять идентичность, ограничивать права, валидировать сообщения и сохранять каждую передачу в журнале.[6]

То есть разделение не отменяет безопасность. Оно переносит её на новый уровень.

2. Есть действительно разные предметные области

Например, общий ассистент компании должен работать одновременно с:

• кадровыми регламентами;
• технической документацией;
• договорами;
• коммерческими условиями.

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

Microsoft Copilot Studio предлагает отделять агента, если подзадача достаточно сложна для собственного набора инструментов или знаний, требует другого управления доступом либо должна переиспользоваться несколькими другими агентами. И там же дана полезная обратная рекомендация: не создавать отдельного агента для каждой мелкой задачи; практический старт — один агент и разделение по мере появления реальной границы.[3]

3. Работу можно выполнять по-настоящему параллельно

Это один из самых сильных аргументов в пользу multi-agent.

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

У Anthropic есть интересный пример именно такого класса. В их внутренней системе Research ведущий агент запускает несколько исследовательских агентов параллельно. На собственном research-eval компания зафиксировала преимущество multi-agent варианта над одним агентом на 90,2%.[5]

Но эта цифра требует двух больших оговорок.

Во-первых, это внутренняя оценка поставщика на конкретной исследовательской задаче, а не универсальный результат для бизнеса.

Во-вторых, сама Anthropic сообщает, что такая архитектура в их данных расходовала примерно в 15 раз больше токенов, чем обычный чат. Авторы отдельно отмечают, что multi-agent хуже подходит для задач с большим количеством зависимостей и общим контекстом между исполнителями.[5]

Вот хороший пример того, почему нельзя обсуждать архитектуру отдельно от экономики.

Если задача ценная и хорошо параллелится — дополнительные вычисления могут окупаться.

Если агент просто переносит заявку из письма в CRM, 15-кратный рост работы модели вряд ли сам по себе станет преимуществом.

4. Один агент уже упёрся в измеренное ограничение

Это, пожалуй, самый здоровый момент для разделения.

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

Здесь есть конкретная проблема.

Можно сформулировать гипотезу:

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

И проверить её на одном тестовом наборе.

Google прямо связывает переход к multi-agent с ситуациями, где увеличение количества инструментов и обязанностей начинает ухудшать работу одного агента.[2]

Это совсем другая логика, чем «давайте сразу построим отдел ИИ».

Как выбрать архитектуру на пилоте

Когда не нужен даже один агент

Есть ещё один вариант, который легко потерять в обсуждении single-agent против multi-agent.

Не использовать агента вообще.

Если маршрут известен заранее, системе необязательно самостоятельно решать, что делать дальше.

Например:

новая заявка → проверка обязательных полей → запрос недостающих данных → создание сделки → назначение менеджера.

Это workflow.

Модель можно вставить в одну конкретную точку — например, чтобы классифицировать свободный текст. Но превращать каждый блок в агента смысла нет.

Google отдельно рекомендует рассматривать неагентные решения для предсказуемых и хорошо структурированных задач.[2]

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

Это хорошая проверка перед любым multi-agent проектом:

если часть процесса можно заменить обычной функцией или workflow, сначала замените её.

Условный пример: один агент вместо «ИИ-отдела»

Представим торговую B2B-компанию.

Клиенты пишут на почту и в мессенджер. Они спрашивают о наличии, характеристиках, доставке, документах и статусе существующего заказа.

Первая идея может выглядеть эффектно:

• агент-продавец;
• агент-консультант;
• агент по логистике;
• агент по документам;
• управляющий агент.

Я бы не начинал с этой схемы.

Для первой версии можно оставить один агент. Он определяет намерение клиента и получает несколько узких инструментов: поиск по каталогу, чтение статуса заказа, поиск утверждённого документа и создание черновика ответа.

Программный workflow по-прежнему контролирует права, журнал и передачу сотруднику.

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

Вот теперь появилась реальная граница.

Логистический компонент можно вынести в отдельного агента с собственными данными и правами, а основной агент будет передавать ему только номер заказа и конкретный вопрос.

Не потому, что «агентов должно быть много».

Потому что появился отдельный контур ответственности.

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

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

Спорить о single-agent и multi-agent на схеме можно долго. Лучше поставить эксперимент.

Шаг 1. Зафиксировать одну бизнес-задачу

Не «создать мультиагентную систему», а:

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

Шаг 2. Собрать baseline на самой простой архитектуре

Если достаточно workflow — начинайте с workflow.

Если нужен выбор инструментов и последовательности действий — один агент.

Прогоните репрезентативный набор реальных сценариев.

Шаг 3. Найти место, где он ломается

Не общую оценку «агент слабоват», а конкретный тип ошибки:

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

Шаг 4. Разделить только эту ответственность

После этого появляется второй вариант архитектуры.

Например, один агент остаётся координатором, а поиск по специальной базе выполняет отдельный агент.

Шаг 5. Сравнить обе версии

Минимальный набор показателей:

Метрика	Что показывает
Доля полностью выполненных сценариев	Решает ли архитектура задачу
Исправления сотрудником	Сколько ручной работы осталось
Ошибки выбора инструмента	Помогла ли специализация
Ошибки handoff	Что потерялось между агентами
Время выполнения	Цена дополнительной координации
Стоимость успешной операции	Оправдана ли сложность экономически
Ошибки интеграций и повторов	Насколько система устойчива
Нарушения границ доступа	Безопасно ли разделены полномочия

Если multi-agent не даёт заметного выигрыша по проблеме, ради которой его добавляли, оставляем более простую версию.

И это нормальный результат пилота.

Короткая матрица выбора

Перед тем как добавлять второго агента, задайте шесть вопросов.

Можно ли заранее задать маршрут? Если да — сначала workflow.

У одного агента уже есть измеренная проблема? Если нет — сначала протестируйте одного.

У частей задачи действительно разные данные, права или владельцы? Если да — разделение становится разумнее.

Подзадачи могут выполняться независимо и параллельно? Если да — multi-agent может дать выигрыш.

Стоимость и задержка дополнительных вызовов приемлемы? Если нет — выигрыш архитектуры может не окупиться.

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

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

Вывод и частые вопросы

Количество ИИ-агентов — плохая метрика зрелости системы.

У хорошей архитектуры может быть пять агентов. Может быть один. А иногда в ней вообще нет агента — только workflow с одним модельным шагом.

Я бы использовал простой порядок:

сначала процесс → затем workflow → при необходимости один агент → тесты → найденное ограничение → только потом разделение.

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

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

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

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

Чем несколько агентов лучше одного?

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

Сколько ИИ-агентов нужно бизнесу?

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

Нужно ли делать отдельного агента для проверки другого агента?

Не автоматически. Если проверка сводится к формату, допустимым значениям, правам или бизнес-правилам, надёжнее выполнить её обычным кодом. Второй агент оправдан там, где сама проверка требует отдельного анализа или независимой предметной экспертизы. Для критичных действий модель при этом не должна быть единственным механизмом контроля.

Источники

1. Single agent or multiple agents — Microsoft Learn.
2. Choose a design pattern for your agentic AI system — Google Cloud Architecture Center, проверено 28 мая 2026 года.
3. Multi-agent orchestration patterns and best practices — Microsoft Learn, обновлено 22 мая 2026 года.
4. AI Agent Orchestration Patterns — Microsoft Azure Architecture Center.
5. How we built our multi-agent research system — Anthropic Engineering, 13 июня 2025 года.
6. Secure multi-agent orchestration — AWS Well-Architected.