Single-agent или multi-agent: когда одному AI-агенту уже недостаточно

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

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

Multi-agent система устроена иначе. В ней задача раскладывается между несколькими специализированными агентами, а сверху обычно есть центральный управляющий слой — orchestrator, supervisor или planner. Он распределяет работу, определяет порядок шагов и решает, когда должен включаться каждый отдельный агент. Такая архитектура даёт больше модульности и лучше подходит для сложных процессов, где у разных частей задачи разные инструменты, разная логика и разная цена ошибки.

Главная ошибка здесь — думать, что multi-agent всегда лучше. Это слабая инженерная позиция. Если задачу можно надёжно закрыть одним агентом, дополнительная оркестрация только усложнит систему. Один агент хорошо работает в простых сценариях с ограниченным набором инструментов. Типовые примеры — персональный помощник с доступом к календарю, агент-калькулятор или web-search агент, который просто обращается к поисковому API и возвращает актуальные данные.

Переход к multi-agent становится оправданным не тогда, когда это “модно”, а когда single-agent начинает перегружаться. В статье выделяются характерные признаки такой перегрузки: слишком много инструментов, многошаговая логика, разные типы ответственности, необходимость проверки результата перед финальным ответом. На этом этапе начинают проявляться типовые проблемы: перегруженный prompt, слабый routing инструментов, размытые обязанности и общее падение надёжности системы.

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

Хороший пример — software engineering agent. Для такой задачи логично разделить роли: один агент оркестрирует процесс, другой пишет код, третий тестирует, четвёртый проверяет качество и замечает ошибки. В статье это сведено к простой схеме: Orchestrator → Coder → Tester → Reviewer. Именно на таких задачах multi-agent выглядит не как украшение, а как нормальная структурная декомпозиция.

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

Именно поэтому вопрос “когда строить multi-agent” нужно формулировать не как технологический, а как инженерный. Не “можем ли мы”, а “ломается ли single-agent под нагрузкой этой задачи”. Если да — появляется пространство для оркестратора, специализированных агентов и более строгого пайплайна. Если нет — один агент почти всегда будет лучше.

С multi-agent системами сейчас та же проблема, что когда-то была с микросервисами: их начинают строить раньше, чем появляется реальная необходимость.

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