Суть
Один агент = один контекст, один набор инструментов. Когда задача требует разных специализаций, параллелизма или внешнего контроля качества, её разбивают на роли и отдают «виртуальной команде». Это сдвиг от «как написать умный промпт» к «как организовать отдел». Но каждый дополнительный агент множит контекст и оркестрационные издержки.
Когда MAS нужна (и когда нет)
Нужна, если есть хотя бы одно:
- Разные специализации (Researcher / Writer / Reviewer / Actor).
- Высокая цена ошибки → нужен второй контроль (критик/ревьюер, см. Multi Agent Patterns).
- Параллелизм: latency важна и задачу можно разбить → падает в 2–3 раза.
- Авто-коррекция через разделение ролей (исполнитель не оценивает себя сам).
- Логи по ролям — легче дебажить и объяснять решение бизнесу.
НЕ нужна, если: простой workflow, и 80% задач закрываются одним LLM + RAG (см. Agent vs Workflow). Антипример — Paperclip на старте: «бурное обсуждение, что и как делать, но результата нет».
Топологии координации
- Orchestrator-worker — один управляющий агент декомпозирует и раздаёт подзадачи исполнителям (CEO → команда).
- Иерархия — многоуровневое делегирование (CEO → C-level → инженеры).
- Коллегиально / аукцион — агенты равны и «договариваются»; появляется идея тендеров: кому выгоднее и эффективнее отдать кусок задачи прямо сейчас (метафора логистического диспетчера).
Как выбирать топологию. Вопрос решается не вкусом, а тем, кто владеет декомпозицией задачи. Если задачу можно разрезать заранее и разрез не меняется по ходу — берут orchestrator-worker: один владелец плана, предсказуемая трассировка, простой дебаг (Hierarchical Decomposition — когда уровней больше одного). Если состав подзадач выясняется только в процессе и агенты должны реагировать на появление данных, а не на команду, — уместнее событийная схема (Event Driven Agents), но за неё платят потерей единой точки, где видно весь план. Коллегиальная схема с торгом за задачу — самая дорогая по числу обменов и оправдана, когда нет способа заранее сказать, кто справится лучше.
На практике продакшен чаще приходит к гибриду: вероятностный слой агентов сверху, детерминированная стейт-машина под ним (Hybrid Orchestration) — потому что чистая коллегиальность плохо отлаживается, а чистая иерархия плохо переживает изменение задачи.
Окупается ли overhead. Считать надо не число агентов, а суммарный контекст: каждый агент несёт свой промпт и свою историю, поэтому расход растёт быстрее, чем линейно по ролям, и к нему добавляются обмены между ними. Окупается это в трёх случаях, и все три перечислены выше в критериях: параллелизм реально режет latency (в 2-3 раза), цена ошибки выше цены второго прохода критиком, либо нужны раздельные логи по ролям для объяснимости. Если ни одного из трёх нет — команда агентов будет дороже и медленнее одного агента при том же качестве. Проверять это дешевле всего до реализации: посчитать стоимость одного прогона монолитного агента и умножить на число ролей — если результат неприемлем, дальше можно не идти (Agent CostControl).
Базовое свойство таких систем — эмерджентность: поведение целого не сводится к сумме агентов (см. ссылку в Источниках).
Альтернативный взгляд: академическая рамка — мультиагентность как эмерджентность
Вся заметка выше стоит на инженерной рамке: мультиагентная система — это команда специалистов, где мы назначаем роли, раздаём инструкции и следим, чтобы координация окупала свою цену. Метафора — виртуальный отдел с ролями PM, Dev и QA.
Академический взгляд из мультиагентного обучения с подкреплением ставит вопрос иначе. Там агенты не получают ролей — роли и стратегии возникают сами из взаимодействия и функции награды. Метафора другая: одноклеточный слизевик, который собирается в многоклеточный организм, когда кончается еда, или муравейник, где сложное поведение колонии не запрограммировано ни в одном муравье.
Разница не косметическая, она про то, откуда берётся осмысленное поведение системы:
| Инженерная рамка (эта заметка) | Академическая рамка (MARL) | |
|---|---|---|
| Откуда роли | Назначены человеком в промпте | Возникают из обучения, эмерджентно |
| Что настраиваем | Инструкции, топологию, лимиты | Функцию награды и среду |
| Критерий успеха | Ответ получен, бюджет не превышен | Средняя награда растёт, обучение стабильно |
| Сюрпризы | Считаются багом | Считаются результатом |
Последняя строка — самая содержательная. В инженерной системе неожиданное поведение агента это дефект, который надо чинить. В MARL неожиданное поведение — то, ради чего эксперимент ставился: классическая демонстрация от OpenAI, где агенты в игре в прятки нашли дыры в физике мира и стали использовать предметы способами, которых разработчики не предусматривали.
Практический вывод для инженерной работы: если от вашей мультиагентной системы ожидается предсказуемость, эмерджентность вам не союзник, и её стоит гасить лимитами и детерминированным слоем (Hybrid Orchestration). Заимствовать из MARL имеет смысл не приёмы, а словарь — назначение вклада, отложенная награда, нестационарность.
Инженерные паттерны надёжности MAS
Порог, после которого монолитный агент перестаёт справляться, называется конкретно: более 4–5 инструментов или несколько разных доменных областей. Дальше точность выбора функции моделью падает, и монолит заменяется мультиагентной схемой с супервайзером — не ради красоты декомпозиции, а потому что сузился выбор у каждого исполнителя.
Пять приёмов, которые делают такую схему пригодной для продакшена:
- Гибридный супервайзер. Верхнеуровневый управляющий — чистый детерминированный конечный автомат в коде, а LLM-роутер включается только на подзадачах с динамическим ветвлением. Это тот же принцип, что в Hybrid Orchestration, но применённый к самой верхней точке: она обязана быть предсказуемой, потому что её отказ роняет всё дерево.
- Blackboard Pattern. Агенты общаются не передачей полной истории сообщений, а через общее структурированное досье (dossier), разделённое на именованные секции. Каждый читает свою секцию и пишет в свою. Экономит контекстное окно и стоимость, а заодно делает обмен отлаживаемым: видно, кто что положил, а не сплошная лента реплик.
- Изоляция контекста воркера. Перед вызовом исполнителя его контекст очищается — передаётся только исходный запрос и последняя директива супервайзера. Без этого воркер наследует чужие рассуждения и начинает решать не свою задачу.
- Anti-loop hard-stops на трёх уровнях сразу: жёсткое правило в промпте воркера («вызови инструмент X ровно один раз»), глобальный лимит рекурсии на графе оркестрации, счётчик повторов с эскалацией на оператора. Ни один из трёх не самодостаточен: промпт обходится моделью, лимит графа срабатывает слишком поздно, счётчик повторов не ловит зацикливание без ошибок (Agent CostControl).
- Per-role model tiering. Супервайзер — детерминированный код или малая модель; воркеры — лёгкие быстрые модели; финальная сборка ответа — старшая модель. Распределение по ролям, а не по сложности запроса, отличает этот приём от каскадной маршрутизации (Cascade Routing).
Связано с
- Agent Execution Platform — платформенные слои, общие для одного и нескольких агентов
- MARL — академическая мультиагентность: агенты обучаются, а не инструктируются
- MAS Frameworks — чем собирать MAS (CrewAI / AutoGen / LangGraph / Mastra)
- Multi Agent Patterns — паттерны параллелизма и критик/ревьюер
- CrewAI — самый низкопороговый фреймворк для «команды»
- Agent vs Workflow — ось «один агент vs команда», правило 80%
- Agent Roles — роли по полномочиям (Assistant/Executor/Supervisor-Crew/HITL)
- Agent2Agent Protocol — стандарт общения между независимыми агентами