«Мультиагент» как модный диагноз
Мультиагентные системы — модная тема, и это создаёт ловушку: архитектуру выбирают «потому что круто», а не потому что задача её требует. Типичный путь — взять простую задачу («ответь на вопрос по документации»), раздуть её до пяти агентов с супервайзером — и получить систему, которая дороже, медленнее и капризнее, чем один аккуратный ReAct-агент решал бы то же самое.
Базовое правило инженерии работает и здесь: начинай с простого и усложняй, только когда простое перестаёт справляться. Один хороший агент — это база. Мультиагентность — осознанный шаг, когда у тебя есть конкретная причина из прошлых уроков (разные домены, нужен независимый критик, реальная потребность в параллелизме), а не дефолт.
Система из десяти агентов выглядит «серьёзнее», но в продакшене ценится обратное: самая простая архитектура, которая решает задачу. Каждый агент, которого можно убрать без потери качества, нужно убрать — он только добавляет точек отказа, стоимость и задержку.
Из чего складываются накладные расходы
Каждый агент в системе платит «налог» по нескольким статьям. На малой задаче этот налог превышает всю выгоду от разделения.
- Стоимость токенов. Координация — это вызовы LLM. Супервайзер, который решает «кому отдать», тоже тратит токены. Команда из четырёх агентов — минимум вчетверо больше обращений к модели, чем один.
- Задержка. Передачи между агентами и шаги маршрутизации добавляют время. Последовательная команда часто медленнее одного агента (параллелизм спасает не всегда).
- Накопление ошибок. Если каждый агент надёжен на 95%, цепочка из пяти даёт уже ~77% (0.95⁵). Ошибки перемножаются вдоль конвейера, и длинная команда менее надёжна, чем кажется.
- Сложность отладки. Переплетённые трейсы, передача контекста между ролями, «испорченный телефон» при пересказе — всё это новые классы багов, которых нет у одного агента.
Когда один агент лучше
Сигналы, что мультиагентность — оверинжиниринг и достаточно одного агента:
- задача в одном домене
- немного инструментов (влезают в один промпт)
- шаги зависимы (всё равно по очереди)
- важны низкая задержка и цена
- нет потребности в независимом ревью
- реально разные домены/специализации
- много независимых подзадач (параллелизм)
- высокая цена ошибки → независимый критик
- система должна расти новыми способностями
- один агент уже «захлёбывается» в инструментах
Прежде чем дробить на команду, выжми максимум из одного агента: лучший промпт, грамотные описания инструментов, ReAct-цикл, при необходимости — self-reflection (модуль 03). Очень часто «проблема, которую хотели решить вторым агентом» снимается хорошим промптом первого. Мультиагентность — следующий шаг, когда этого уже не хватает.
Промежуточные решения
Выбор не бинарный «один агент против команды из десяти». Между ними — лестница усложнения, по которой поднимаются по необходимости:
1. Один агент — базовый ReAct с инструментами ↓ не хватает качества самопроверки 2. + self-reflection — тот же агент критикует себя (1 модель) ↓ нужна независимая проверка / другой домен 3. 2–3 агента — минимальная команда (напр. writer + critic) ↓ реально много ролей и рост 4. Команда + супервайзер — полноценная мультиагентная система ↓ ролей стало слишком много для одного управляющего 5. Иерархия команд — супервайзеры над супервайзерами
Поднимайся на следующую ступень, только когда текущая перестала справляться — и можешь объяснить, какую именно проблему решает усложнение. Если объяснения нет, ты, скорее всего, на ступеньку выше, чем нужно.
Правило выбора
Свести всё к одному вопросу: «Какую конкретную проблему одного агента решает добавление второго — и стоит ли это его цены?»
- Не можешь назвать проблему → второй агент не нужен.
- Проблема есть, но снимается лучшим промптом → почини промпт, а не плоди агентов.
- Проблема структурная (разные домены, независимость, параллелизм, рост) → команда оправдана, бери ровно столько агентов, сколько ролей.
Заводить отдельного агента под каждое микро-действие («агент, который форматирует дату») — верный способ получить дорогую, медленную и хрупкую систему. Агент оправдан, когда у него есть содержательная зона ответственности, а не одна операция. Микро-шаги — это функции и инструменты внутри агента, а не отдельные агенты.
Типичные ошибки
Начинать с команды «потому что это правильно/модно» — оверинжиниринг. Начинай с одного агента; усложняй по конкретной причине.
Длинная цепочка агентов менее надёжна (надёжности перемножаются). Больше звеньев — выше шанс, что где-то сломается.
Отдельные агенты под атомарные операции — лишняя координация и стоимость. Микро-шаги — это инструменты внутри агента.
Команда часто в разы дороже и медленнее одного агента. Если важны cost и latency, сравни числа, прежде чем дробить.
Шпаргалка
ПРАВИЛО: начни с ОДНОГО агента; усложняй по конкретной причине
НАКЛАДНЫЕ РАСХОДЫ команды:
💸 стоимость — координация = доп. вызовы LLM (4 агента ≈ 4×+)
⏱ задержка — маршрутизация + передачи (часто медленнее одного)
🐞 надёжность — ошибки перемножаются: 0.95^5 ≈ 0.77
🔍 отладка — переплетённые трейсы, «испорченный телефон»
ОДНОГО АГЕНТА ХВАТИТ, если:
• один домен · мало инструментов
• шаги зависимы (всё равно по очереди)
• важны цена и задержка
• нет нужды в независимом ревью
КОМАНДА ОПРАВДАНА, если:
• реально разные домены · много независимых подзадач
• высокая цена ошибки → независимый критик
• система должна расти новыми способностями
ЛЕСТНИЦА: 1 агент → +self-reflection → 2–3 агента →
команда+супервайзер → иерархия (вверх — по необходимости)
ВОПРОС-ФИЛЬТР: какую проблему одного агента решает второй —
и стоит ли это его цены?
Практическое задание
Потренируй критическое мышление об архитектуре:
Задание: нужна ли тут команда?
- Возьми три задачи: (а) «отвечай на вопросы по нашей документации», (б) «подготовь рыночный отчёт с фактами, анализом и редактурой», (в) «классифицируй входящие письма по теме». Для каждой реши: один агент или команда? Обоснуй через накладные расходы.
- Для задачи, где ты выбрал команду, посчитай примерно: во сколько раз больше вызовов LLM и насколько выше задержка относительно одного агента.
- Прикинь надёжность цепочки: если каждый агент верен в 90% случаев, какова надёжность конвейера из 4 агентов? Что это говорит о длине цепочки?
- Возьми «мультиагентную» задачу и попробуй сначала решить её одним агентом (промпт + инструменты + self-reflection). Где это сломается и сломается ли?
- Найди в гипотетической системе «агента на микро-действие» и преврати его обратно в инструмент/функцию внутри другого агента.
- Со звёздочкой: сформулируй для своей команды короткий чек-лист «оправдан ли ещё один агент» из 3–4 вопросов, который можно прикладывать к любой новой роли.
Что дальше
На этом раздел «зачем» закрыт: ты знаешь и причины собирать команду (специализация, параллелизм, критика, рост), и причины этого не делать (накладные расходы). Дальше — практика: фреймворки, которые реализуют мультиагентов, начиная с AutoGen.