Главная
→
Блог
→
Мультиагентность: как оркестратор делит задачу между агентами

Мультиагентность: как оркестратор делит задачу между агентами

“

Саммари: Один ИИ-агент упирается в потолок быстрее, чем кажется: на достаточно большой задаче он теряет контекст, накапливает мелкие ошибки или просто застревает. Разбираем, как устроена архитектура с оркестратором — и почему «просто добавить ещё агентов» не является стратегией.

Зачем вообще делить задачу

Проблема одиночного агента вполне конкретная: дайте ему достаточно большую задачу, и он либо потеряет ранний контекст, либо накопит серию мелких ошибок, либо просто встанет, пытаясь удержать в памяти слишком много одновременно, при этом «просто добавить больше агентов» не является стратегией — работающие в продакшене команды агентов требуют осознанной архитектуры: чётких ролей, определённых каналов связи, обработки отказов и структуры управления.

Отрезвляющая статистика: 40% мультиагентных пилотов проваливаются в течение шести месяцев после вывода в продакшен — и дело не в том, что мультиагентные системы не работают, а в том, что команды выбирают неподходящий паттерн оркестрации под свою задачу или выбирают правильный, не понимая, как именно он ломается.

Как работает оркестратор

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

Ключевая деталь, объясняющая экономику такой архитектуры: оркестратор использует более мощную модель, а исполнители — более дешёвые и заточенные под задачу, что сокращает затраты на 40–60%.

Делегирование бывает двух типов: параллельное — когда подзадачи не зависят друг от друга, что быстрее, и последовательное — когда более поздняя работа требует результатов ранней; большинство реальных процессов смешивают оба типа.

Именно такая архитектура лежит в основе наших диалоговых ассистентов для ВкусВилл и ДомаДом. Агент-оркестратор делит задачу на подзадачи и делегирует их отдельным агентам: один отвечает за подбор товаров, другой — за оформление заказа, третий — за эскалацию оператору, а вся система интегрирована с каталогом, сайтом и CRM в единый сквозной процесс. Подробнее — на allsee.team.

Где это уже даёт результат

Примеры из корпоративной практики показывают масштаб эффекта. Wells Fargo использует этот паттерн, чтобы дать 35 000 банковским сотрудникам доступ к 1700 регламентам за 30 секунд — против 10 минут раньше. Другой задокументированный пример — юридическая фирма, где генерация договора разложена на отдельных агентов: выбор шаблона, кастомизация пунктов, проверка на соответствие и оценка рисков — каждый этап обрабатывается отдельным ИИ-агентом.

Чем платят за мультиагентность

Здесь важно не поддаться очарованию архитектуры. Накладные расходы реальны: четырёхагентный конвейер накапливает около 950 мс координационных издержек, тогда как самообработка занимает 500 мс, а трёхагентный конвейер потребляет 29 000 токенов против 10 000 у эквивалентного одноагентного подхода — то есть если специализация вам не нужна, вы платите втрое за тот же результат.

Второй типичный сбой — распространение ошибки: плохой результат на первом этапе каскадом идёт через все последующие без возможности откатиться. Третий — узкое место в самом оркестраторе, когда вся система упирается в пропускную способность координирующего агентаосторожно с узкими местами оркестратора.

Как выбирать архитектуру

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

Есть и архитектурное свойство, ради которого всё это и делается: иерархические паттерны разделяют контекст так, что ни одному агенту не нужен полный контекст всей системы. Именно это решает исходную проблему — потерю контекста на больших задачах.

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

Итог

Мультиагентная архитектура решает конкретную проблему — потолок контекста и накопление ошибок у одиночного агента — но делает это ценой координационных издержек и утроенного расхода токенов. Правильный вопрос перед внедрением звучит так: действительно ли моя задача требует специализации, или я просто усложняю то, с чем справился бы один агент? Если требует — начинайте с простейшего паттерна «оркестратор и исполнители» и добавляйте параллельность только там, где подзадачи по-настоящему независимы.