Мультиагентные системы: когда один агент справится лучше

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

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

Описанное ниже поведение фреймворков сверено с актуальной документацией разработчиков 26 октября 2026 года. Таблица выбора показывает, как применить задокументированные подходы к типичным задачам разработки.

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

В мультиагентной системе разные агенты отвечают за части общей задачи и могут обмениваться результатами работы. В приложении на базе большой языковой модели (LLM) агент — это модель, работающая в цикле: она выбирает инструменты, изучает результаты их вызова и решает, что делать дальше. В системе с несколькими агентами эти решения согласуются между исполнителями, а не принимаются одним из них. Более широкое понятие взаимодействующих агентов описано в обзоре IBM.

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

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

Мультиагентные системы в ИИ: о каких задачах пойдёт речь?

Область мультиагентных систем охватывает также роботов, автономный транспорт и симуляции — об этом рассказывает обзор Google Cloud. Здесь мы рассматриваем выбор архитектуры для LLM-агентов, занятых исследованиями, разработкой ПО и бизнес-задачами.

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

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

Архитектура мультиагентных систем: выбирайте под задачу

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

Прежде чем выбирать фреймворк, возьмите за основу эти варианты:

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

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

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

Основные схемы взаимодействия агентов

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

Координатор и исполнители: за результат отвечает один агент

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

В актуальном руководстве LangChain по координатору агенты календаря и почты оформлены как высокоуровневые инструменты. Координатор вызывает эти инструменты и получает итоговые ответы специалистов. Ему не нужно включать каждую промежуточную операцию в собственную историю диалога.

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

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

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

Иерархия: делегирование через управляющих агентов

CrewAI, фреймворк для координации агентов с заданными ролями, строит команду вокруг агентов, задач и порядка выполнения. Его иерархический процесс использует Process.hierarchical вместе с manager_llm или manager_agent. Управляющий агент распределяет работу, проверяет результаты и решает, завершены ли задачи.

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

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

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

Передача управления: специалист продолжает диалог

OpenAI Agents SDK, библиотека для запуска агентов и инструментов, реализует механизм handoff как передачу управления другому агенту. Конфигурация handoffs перечисляет агентов, которым можно передать работу. Получивший управление специалист отвечает за следующий ответ. Это отличается от вызова специалиста через as_tool(), при котором ответственность за ответ остаётся у управляющего агента. Документация OpenAI по оркестрации явно проводит это различие.

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

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

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

Общий чат: агенты работают через совместное обсуждение

Microsoft Agent Framework, фреймворк для создания агентных приложений и рабочих процессов, реализует общий чат с оркестратором, который выбирает следующего участника. Его GroupChatBuilder для Python поддерживает функцию выбора или оркестратор на базе агента, а также условие завершения. У участников отдельные сессии с синхронизируемой историей диалога. Механизм описан в документации Microsoft по общему чату.

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

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

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

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

Примеры мультиагентных систем: где разделение приносит пользу

Исследование широкого круга вопросов — более убедительный повод начать, чем правка тесно связанных частей одного результата. В описанной Anthropic системе Research ведущий агент координирует параллельных исполнителей: они изучают отдельные направления и возвращают выводы. В опубликованной внутренней оценке связка ведущего Claude Opus 4 с субагентами Claude Sonnet 4 превзошла одиночный Claude Opus 4 на 90.2%. Это заявленное относительное улучшение в рамках конкретной оценки исследовательских задач, а не доля успешных решений в 90.2% и не универсальная прибавка от добавления агентов. Кроме того, в этом сравнении меняются состав моделей и организация вычислений. Инженерный разбор Anthropic.

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

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

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

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

Почему мультиагентные системы на базе LLM дают сбои?

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

Больше токенов и ожидания между зависимыми этапами

Делегирование добавляет инструкции, контекст исполнителей, возвращаемые результаты и их итоговое обобщение. Повторные попытки и общая история диалога увеличивают объём работы. По собственным данным Anthropic, расход токенов у её мультиагентных систем — примерно 15× по сравнению с чатами. База сравнения здесь — чаты, а не запуски одиночного агента; использовать это соотношение как универсальный коэффициент для планирования нельзя. Данные Anthropic о расходе токенов.

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

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

Отладка становится сложнее

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

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

Сравнивая варианты архитектуры, проверьте, можете ли вы найти самое раннее отклонение от задачи: что поручили исполнителю, какие подтверждения ему дали, что он вернул и что следующий исполнитель принял за установленный факт. Если эти переходы нельзя изучить, вы не сможете понять, улучшает ли дополнительный проверяющий систему или просто дописывает успокаивающее заключение.

При передаче работы ошибки накапливаются

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

Исходная неопределённость исчезла из текста, хотя никто её не разрешил. Агентов стало больше, но недостающие подтверждения так никто и не проверил.

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

Какие ожидания от команд агентов завышены?

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

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

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

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

С чего начать на практике: проверьте минимальное полезное разделение

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

1. 1

   Определите, что не работает сейчас

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

2. 2

   Опишите альтернативу с чёткими границами

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

3. 3

   Сравните результаты по единым критериям приёмки

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

4. 4

   Сохраните разделение или откажитесь от него

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

Вопросы о мультиагентных системах

ChatGPT — это мультиагентная система?

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

Какой пример мультиагентной системы можно привести?

Система Research от Anthropic поручает исследования отдельным исполнителям и объединяет их выводы. Это пример схемы «координатор и исполнители».

Какая мультиагентная система лучше?

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

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

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

ChatGPT — это агент или LLM?

ChatGPT — название приложения, а LLM — тип модели, которая лежит в его основе. Агентом называют систему, использующую модель для выбора действий и реакции на их результаты. Эти понятия относятся к разным уровням, поэтому изучайте конкретную функцию, а не считайте термины взаимозаменяемыми.

Какие бывают 7 типов ИИ-агентов?

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

Какие ИИ-агенты встречаются чаще всего?

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

Какие примеры ИИ-агентов можно привести?

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

Какие выделяют 5 типов ИИ-агентов?

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

Чтобы принимать практические решения о разработке с ИИ, подпишитесь на рассылку.