Финал кластера 04. Когда задача слишком большая для одного агента — разбиваем на несколько. Когда лучше три специализированных, чем один универсальный. И почему «multi-agent system» — это часто переусложнение, а иногда — единственный разумный путь.
Мультиагентные системы — это не «модно», а архитектурный выбор. Один агент с 30 инструментами часто хуже трёх специализированных с 8-10 каждый: меньше путаницы, чище контекст, проще отлаживать. Но цена — оркестратор, передача данных, общая память, координация. Сегодня учимся видеть, когда разделение оправдано, а когда добавляет проблем без выгоды.
В Кластере 02 ты строил агентов с одним циклом, одним массивом messages, одной моделью. Это здорово работает для большинства задач. Но в какой-то момент ты увидишь признаки, что архитектура «треснула». Вот они:
Один-два сигнала из списка — терпимо, можно лечить в рамках одного агента. Три и больше — это уже архитектурный долг, который накапливается, и проще разделить.
Мультиагентность — это не «когда умно», а когда один агент становится узлом сложности, который тебе невыгодно тянуть. До этого момента — не плоди сущности.
Обратная сторона: соблазн «сделать как у больших, multi-agent». Часто это вредит. Признаки, что тебе не нужно разделение:
В таких случаях добавление второго агента — это удвоенный код, лишний оркестратор, удвоенная отладка, без выигрыша по качеству. Просто более «продвинуто звучит», и это плохая причина.
За год-два, что индустрия экспериментирует с мультиагентами, выкристаллизовалось несколько устойчивых паттернов. Изучим четыре главных:
Один «менеджер» делегирует задачи нескольким «исполнителям»
Главный агент (оркестратор) принимает задачу от пользователя, разбивает её на подзадачи и поручает их специализированным агентам. Каждый специалист — со своими инструментами, промптом, иногда моделью.
Пример: исследовательский агент. Оркестратор получает «изучи рынок ниши X». Делегирует: research-agent ищет источники, analyst-agent обобщает данные, writer-agent пишет финальный отчёт. Оркестратор координирует, держит общую цель, собирает результаты.
A → B → C, каждый шаг — отдельный агент
Не «оркестратор разруливает», а код задаёт чёткий конвейер. Агент A делает свою работу, его результат отправляется агенту B, тот — агенту C. Линейная передача данных, без центрального координатора.
Пример: AI-помощник для код-ревью. parser-agent разбирает diff PR. analyzer-agent ищет проблемы в каждом изменённом файле. writer-agent формирует финальные комментарии в стиле проекта.
Простой агент классифицирует запрос и передаёт специализированному
Лёгкий первый агент (router) на маленькой модели читает запрос пользователя и определяет, к какому из специализированных агентов его отправить. Дальше работает один специалист — никакой координации в процессе.
Пример: служба поддержки. Запрос «не работает оплата» → router → billing-agent. «Не приходит письмо» → router → communications-agent. «Хочу вернуть деньги» → router → refunds-agent. У каждого свои инструменты, свой тон, свои ограничения.
Два агента общаются между собой, пока не придут к ответу
Самый «исследовательский» паттерн. Два агента ведут диалог: один генерирует решения, второй критикует. Или: один задаёт вопросы, другой отвечает. Через 3-7 ходов диалога приходят к решению.
Пример: writer-agent пишет текст, critic-agent читает его глазами целевой аудитории и говорит, что улучшить. Цикл повторяется, текст становится лучше.
В реальных системах часто комбинируют: внешний маршрутизатор отправляет к оркестратору, который запускает конвейер из специалистов. Все четыре паттерна — кирпичики, которые складываются.
Главное решение в мультиагенте: оркестратор тоже на LLM или это программный код?
Оркестратор-LLM: гибко (можно делегировать на ходу, принимать новые типы задач), но непредсказуемо. Хорошо для задач, где «план зависит от того, что выяснится».
Оркестратор-код: жёстко (поток фиксирован), но надёжно и быстро. Хорошо для повторяющихся задач, где этапы известны заранее.
Гибридный подход (часто самый разумный): скелет — код, отдельные решения внутри — LLM. Код задаёт «сначала исследование, потом анализ, потом написание». Внутри каждого этапа LLM-агент свободно выбирает инструменты. Это и есть Task State Machine из Дня 13, расширенная на несколько агентов.
Соблазн — везде использовать одну большую модель. На практике большая часть специалистов прекрасно работает на средних моделях:
Хорошо спроектированная мультиагент-система экономит деньги, потому что большая модель используется только там, где правда нужна. Плохо спроектированная — тратит больше моноагента, потому что 10 запросов средней модели вместо 2 запросов большой.
Презентация с «мультиагентной архитектурой, где Research Agent взаимодействует с Analyst Agent» — впечатляющая. Реальный продукт, где это не нужно — это в 2 раза больше кода, в 2 раза больше багов, в 2 раза больше отладки.
Тест: работала ли бы эта задача в одном агенте с 8 инструментами? Если да — не разделяй. Технологическая красота никогда не стоит усложнения архитектуры.
«Research-agent наработал 20 итераций по 2K токенов — передаю весь его массив analyzer-agent». В контексте второго агента уже 40K токенов истории первого, до того как он начал работать.
Правильная привычка: между агентами передаётся результат, не история. Research-agent должен выдать структурированный ответ (факты, ссылки, выводы). Это и идёт в следующего. Возвращаемся к Дню 10: «контекст — это конструкция, не лог».
Каждый агент — это отдельный LLM-вызов. Координация между ними — это ещё дополнительные вызовы (оркестратор должен принимать решения). В сумме система из 3 агентов делает 6-10 вызовов вместо 3-5 одного агента.
Если делишь — будь готов к тому, что latency и стоимость выросли, не упали. Выигрыш в качестве должен перекрывать этот рост. Если нет — оставляй моноагент.
Оркестратор на LLM — это удобно, но он ошибается. Может неправильно разбить задачу, неправильно выбрать специалиста, неправильно интерпретировать результат. Когда вся система зависит от его решений — одна ошибка ломает всё.
Возвращаемся ко Дню 15: критические переходы — это красная зона. «Окей, оркестратор предложил план — давайте покажем пользователю и попросим подтвердить, прежде чем гнать его всем специалистам». Особенно важно в продакшен-системах.
Кластер 04 — это переход от «модель сама что-то делает» к «модель в инфраструктуре стандартных инструментов и грамотной композиции». Пять уроков, пять слоёв:
У нас есть агенты, память, инструменты. Не хватает одного — знаний. Что делать, когда нужная информация не в обучении модели, а в твоих документах, базах, файлах? Об этом — Кластер 05:
Индексация документов, эмбеддинги, семантический поиск, реранкинг. Как агент находит нужное в куче данных и тянет в контекст.
Приватность и автономность. Когда нужны локальные модели, как разворачивать, какие компромиссы.
Финал курса: собираем всё в реальные продукты. Ассистент разработчика, ревью кода, поддержка, работа с файлами.
Современные продвинутые AI-приложения — это часто мультиагенты под капотом. Cursor в «Agent mode» — оркестратор + специалисты. ChatGPT в «Research mode» — конвейер агентов. Claude с computer use — мультиагент с координатором. Сделай 2-3 сложных запроса в каждом и понаблюдай: сколько LLM-вызовов в одном запросе? Есть ли «промежуточные результаты»? Можно ли увидеть передачу между этапами? Это даст ощущение архитектуры в действии.
Возьми задачу, которая в реальности занимает у тебя 1-2 часа (например, «подготовить еженедельный отчёт» или «найти и оценить пять кандидатов на роль»). Спроектируй её как мультиагент: какой паттерн (оркестратор/конвейер/маршрутизатор), какие специалисты, какие инструменты у каждого, как передаются данные. Через 30 минут такой работы у тебя на бумаге — готовая архитектура серьёзного агента, которую можно начать реализовывать.
Возьми мультиагент-систему, спроектированную в Эксперименте 02. Пройди по каждому отдельному агенту и спроси: могла бы эта функция жить как «дополнительный инструмент» в основном агенте? Какие — да, какие — нет (с обоснованием)? Это очищает архитектуру от лишних разделений. Часто финальная версия в 2 раза проще первого черновика.