Мультиагентность: роутер, supervisor и цена команды

Мультиагентность: роутер, supervisor и цена команды

Сложность: средняя

Шестая часть цикла (вторая половина) по книге AI Agents and Applications Роберто Инфанте (Manning, 2026). Глава 12: мультиагентные системы. Первая половина: агент и инструменты изнутри. Предыдущие части: фундамент, суммаризация, LangGraph, RAG в глубину, продвинутый RAG.

Мультиагентность: когда один агент перестаёт хватать

Вторая глава строит поверх одного агента два паттерна. Оба нужны, и разница между ними одна, но решающая.

Ситуация: у тебя два домена - туристическая информация и бронирование номеров. Вопросы про достопримечательности ведёт один агент, про наличие мест - второй. Кто решает, куда передать вопрос?

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

Паттерн второй - supervisor. Здесь агенты оформлены как инструменты самого координатора. Координатор получает сложный вопрос, вызывает первого агента (погода), получает ответ, вызывает второго (цены в этом городе), собирает из двух ответов итог. Это обратный билет: результат возвращается координатору, и он продолжает планировать. Осмысленные вопросы через домены начинают проходить.

Критерий выбора между ними ровно один: должен ли координатор увидеть результат и продолжить работу. Да - supervisor. Нет - роутер.

Цена мультиагентности, о которой книга умалчивает

Supervisor-схема вносит четыре новые проблемы, и глава ни одну не разбирает. Перечислю с нашими ответами.

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

"Заметки на полях". Забавная деталь: в Hermes мультиагентность решается вообще без общего состояния - профилями и делегацией. Профиль это отдельный агент со своей сессией, памятью, набором скиллов и даже своей моделью: hermes profile create researcher --description "Reads source code and external docs". Описание - не украшение: его читает канбан-оркестратор, когда решает, кому отдать задачу, - тот же выбор инструмента по описанию, только на уровне агентов. Задача живёт карточкой в базе, переживает перезапуск и возвращается нужному профилю на правку. Роли из примера книги - турагент и бронировщик - легли бы в два профиля, а супервизор превратился бы в оркестратора с канбаном. Родитель запускает детей как субагентов в изолированных контекстах: каждый не видит ничего, кроме своей задачи, наружу отдаёт только итоговый самопроверенный результат.

Тут же живёт и вопрос "кто решает". Общий паттерн из книги - супервизор умнее агентов: умная декомпозирует, простые исполняют по инструкции. Мы много раз разбирали и обратную схему: триаж делает маленькая System One-модель - классификатор или мини-LM, - а по её решению работу получает большая. Так устроен роутер доменов: словарь с весами детерминированно, без единого вызова LLM, выбирает коллекцию; так устроены decision-модели: компактная модель решает, какой вопрос куда. Маленькая решает быстро и за копейки, большая выполняет. Выбор схемы - вопрос цены ошибки: где ошибка триажа дешёвая (переспросить), там маленькая; где нужен план - там умная.

Наши разборы этой схемы: гибридные команды и слой агентской памяти, четыре decision-модели за неделю, открытая альтернатива Jev: два чекпоинта laya, роутинг моделей.

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

Инъекции. Данные из внешних источников - API отелей, путеводитель - попадают в контекст координатора и влияют на его план. Строчка в данных "проигнорируй инструкции и сделай X" едет в супервизора как обычный текст. Чем больше внешних источников, тем актуальнее фильтрация на входе - тема главы 14.

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

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

"Заметки на полях". Supervisor-паттерн у нас - не общее состояние, а канбан. Профили-роли (разведка, исследование, план, исполнение, проверка) получают задачи карточками, каждая передача фиксируется, ребёнок отдаёт только итог. Схема разбирается отдельно: шесть агентов вместо одного. Почему изоляция контекстов обязательна: передача кода между LLM-агентами. Память между репликами, которой нет у "чат-бота" из главы 11: как устроена система памяти Hermes. Про состояние живого агента: state и поиск.

Что забрать в работу

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

2. Ограничения - в код с первого дня: счётчик шагов, лимиты, подтверждение действий с последствиями. Промпт - рычаг мягкий.

3. Один инструмент, второй, и только потом команда. Мультиагентность не делает систему умнее - дороже и сложнее в отладке.

4. Роутер или supervisor - решает один вопрос: должен ли координатор увидеть результат и продолжить работу.

5. Изоляция контекстов: агент отдаёт наружу итог, не процесс. Иначе состояние команды растёт линейно и съедает деньги.

Продолжение - главы 13-14 книги: MCP, память и guardrails.

Книга: AI Agents and Applications (Roberto Infante, Manning, 2026), глава 12.

#AI_Agents_and_Applications #глава_6б