5 паттернов координации AI-агентов: как выбрать правильный и не утроить расход на токены

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

Почему выбор паттерна координации критичен

Мультиагентная архитектура — не просто «несколько LLM-вызовов в одном пайплайне». Это система с собственными failure modes, паттернами деградации и экономикой. Неверный выбор координации бьёт по трём точкам.

Избыточная латентность. Оркестратор, который последовательно вызывает субагентов, добавляет round-trip на каждый шаг. На пяти шагах это 15–30 секунд задержки — для real-time приложений неприемлемо.

Каскад галлюцинаций. Когда выход одного агента становится входом другого без верификации, ошибка первого шага усиливается на каждом следующем. К четвёртому звену в цепочке фактическая точность может упасть на 30–40%.

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

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

Пять паттернов координации: обзор

Паттерны расположены по возрастанию сложности:

Паттерн	Когда подходит	Главный риск
Генератор-верификатор	Критично качество, есть явные критерии оценки	Верификатор без чётких критериев = иллюзия контроля
Оркестратор + субагенты	Задача декомпозируется на независимые подзадачи	Оркестратор — узкое место, потеря контекста при передаче
Команды агентов	Длительные параллельные задачи с минимальными зависимостями	Конфликты при работе с общими ресурсами
Шина сообщений	Событийные пайплайны с растущим числом агентов	Сложная отладка, тихие отказы при ошибке маршрутизации
Общее состояние	Совместная работа, агенты дополняют друг друга	Гонки данных, нет гарантий согласованности

Паттерн 1 — Генератор-верификатор (Evaluator-Optimizer)

Простейший мультиагентный паттерн и при этом один из самых распространённых в production. Два агента: один создаёт результат, другой его проверяет.

Механика

Генератор получает задачу и формирует первичный результат. Верификатор оценивает его по заданным критериям. Если результат не проходит проверку — возвращает генератору конкретную обратную связь с указанием проблем. Цикл повторяется до принятия результата или исчерпания лимита итераций.

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

Критерий применения: цена ошибки выше цены дополнительной итерации генерации.

Когда верификация ломается

Три конкретных симптома:

• Верификатор без критериев. Промпт «проверь, хорошо ли получилось» одобрит почти любой результат. Anthropic называют это проблемой «ранней победы» — иллюзия контроля качества без содержания. Верификатор работает только с явными, измеримыми критериями: «ответ не упоминает deprecated-функции», «каждый тезис подкреплён ссылкой на документацию».
• Неразделимые навыки. Паттерн предполагает, что проверить проще, чем создать. Для кода это верно — запустить тесты проще, чем написать решение. Для креативных задач — далеко не всегда.
• Бесконечный цикл. Генератор не может исправить замечание верификатора — система осциллирует без конвергенции. Решение: лимит итераций (3–5 обычно достаточно) и стратегия фоллбэка — эскалация человеку или возврат лучшей попытки с оговорками.

По нашему опыту, этот паттерн покрывает 60–70% задач, где вообще нужна мультиагентность. Многие команды начинают сразу с оркестратора, хотя им достаточно генератора-верификатора.

Паттерн 2 — Оркестратор + субагенты (Orchestrator-Subagent)

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

Механика

Оркестратор получает задачу и определяет план выполнения. Часть подзадач может решить сам, остальные делегирует субагентам. Каждый субагент работает в собственном контекстном окне и возвращает сжатые результаты. Оркестратор синтезирует финальный ответ.

Именно так устроен Claude Code: основной агент пишет код, редактирует файлы, запускает команды. Для поиска по кодовой базе или исследования независимых вопросов он запускает субагентов в фоне — каждый в изолированном контексте.

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

Критерий применения: задача очевидно декомпозируется, подзадачи слабо зависят друг от друга.

Граница автономии

Оркестратор — информационное узкое место. Когда субагент безопасности находит уязвимость, влияющую на работу архитектурного субагента, информация должна пройти через оркестратор. После нескольких передач критические детали теряются.

Human-in-the-loop для этого паттерна — не опция, а необходимость:

• Irreversible actions. Действия, которые нельзя откатить, требуют подтверждения человека.
• Autonomy budget. Лимит на количество шагов или стоимость токенов, после которого оркестратор обязан запросить ревью.
• Confidence threshold. Если оркестратор не уверен в декомпозиции — эскалирует, а не угадывает.

Паттерн 3 — Команды агентов (Agent Teams)

Когда работа распадается на параллельные подзадачи, каждая из которых требует длительного автономного выполнения.

Механика

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

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

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

Критерий применения: подзадачи независимы, требуют длительной автономной работы с накоплением контекста.

Ловушки параллельной работы

• Конфликты общих ресурсов. Два агента редактируют одну кодовую базу — конфликты неизбежны. Нужно чёткое разделение ответственности: отдельные ветки, lock-файлы, очереди на запись.
• Неравномерное завершение. Один агент заканчивает за две минуты, другой — за двадцать. Координатор должен обрабатывать частичное завершение.
• Стоимость. Без rate limiting и бюджета токенов параллелизм превращается в DDoS на собственный API-ключ.

Практические приёмы оптимизации:

• Батчинг запросов — группировка мелких запросов в пакеты снижает накладные расходы на системные промпты
• Rate limiting на уровне координатора — жёсткие лимиты на количество одновременных агентов и общий бюджет
• Структурированный мёрджинг — агрегация через JSON-схемы вместо «суммаризируй всё» экономит токены и снижает потерю данных

Паттерн 4 — Шина сообщений (Message Bus)

С ростом числа агентов прямая координация становится неуправляемой. Шина вводит общий коммуникационный слой по принципу publish/subscribe.

Механика

Каждый агент подписывается на интересующие топики, маршрутизатор доставляет подходящие сообщения. Новые агенты подключаются без перестройки существующих связей.

Применение: автоматизация SOC. Алерты из разных источников → агент триажа классифицирует по типу и серьёзности → направляет специализированным агентам → результаты стекаются к агенту реагирования.

Критерий применения: событийный пайплайн, workflow определяется потоком событий, экосистема агентов будет расти.

Подводные камни

• Сложность отладки. Один алерт запускает каскад через пять агентов. Нужен trace ID и тщательный логгинг.
• Тихие отказы. Маршрутизатор теряет событие — система не падает, она просто ничего не делает. Ошибка может оставаться незамеченной неделями.

Паттерн 5 — Общее состояние (Shared State)

Автономные агенты координируются напрямую через персистентное хранилище. Центрального координатора нет.

Механика

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

Применение: исследовательские задачи, где агенты-аналитики изучают разные аспекты проблемы. Один анализирует финансовые данные, другой — рыночные тренды, третий — технические факторы. Каждый обогащает общий документ.

Критерий применения: совместная работа, агенты строят общий результат, итеративно дополняя друг друга.

Риски

• Гонки данных — два агента обновляют одну запись, один перезаписывает другого. Нужны блокировки или версионирование.
• Нет гарантий согласованности — никто не гарантирует, что агенты работают с актуальной версией данных.
• Сложность завершения — без центрального «судьи» нужны явные критерии остановки.

Как выбрать паттерн: дерево решений

Пять вопросов о вашей задаче:

Вопрос 1. Решает ли задачу один агент с хорошим промптом? → Если да — мультиагентность не нужна. Один tool-use агент с продуманным промптом покрывает больше сценариев, чем кажется.

Вопрос 2. Задача линейна и критична к качеству выхода? → Генератор-верификатор. Начинайте здесь.

Вопрос 3. Задача декомпозируется на понятные подзадачи? → Оркестратор + субагенты. Если подзадачи независимы и решаются за ограниченное число шагов.

Вопрос 4. Подзадачи требуют длительной автономной работы? → Команды агентов. Если каждая подзадача — многошаговый процесс.

Вопрос 5. Workflow определяется потоком событий или агенты должны совместно строить результат? → Шина сообщений — для событийных пайплайнов. → Общее состояние — для совместной аналитики.

Главное правило: начинайте с простейшего подходящего паттерна и усложняйте, только когда видите конкретные ограничения в production.

Комбинирование паттернов: гибридные архитектуры

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

Пример — система обработки клиентских обращений:

1. Маршрутизация — классификатор определяет тип обращения и направляет к нужному специалисту
2. Оркестрация — оркестратор декомпозирует задачу: собрать историю клиента, проверить статус, сформулировать ответ
3. Верификация — каждый ответ проходит через верификатор с критериями точности, тона и полноты

Когда гибрид оправдан:

• Разные части системы имеют разные характеристики
• Есть требования и к параллельности, и к качеству
• Система эволюционирует, модули на разных стадиях зрелости

Когда это over-engineering:

• Задача решается одним паттерном
• Команда не может объяснить, зачем каждый компонент
• Стоимость поддержки превышает выигрыш

Топ-5 ошибок при проектировании мультиагентных систем

1. Преждевременная сложность. Оркестратор с пятью субагентами для задачи, которую решает один агент. Правило: если один LLM-вызов решает задачу на 80%+ — мультиагентность не нужна.

2. Отсутствие observability. Без логирования промежуточных шагов, метрик латентности и расхода токенов диагностировать проблемы невозможно. Структурированное логирование с trace ID — минимальное требование.

3. Игнорирование стоимости токенов. Каждый агент — отдельный контекст, системный промпт и история. Пять агентов — минимум пятикратный расход. Считайте unit-экономику до выбора архитектуры.

4. Отсутствие fallback. Что произойдёт, если субагент зависнет? Если шина потеряет сообщение? Проектируйте graceful degradation заранее.

5. Неверная декомпозиция. Подзадачи с высокими зависимостями создают оркестратор, который тратит больше токенов на координацию, чем субагенты — на полезную работу. Хорошая декомпозиция минимизирует обмен данными между агентами.

Матрица выбора паттерна

Паттерн	Тип задачи	Сложность	Стоимость (токены)	Когда избегать
Генератор-верификатор	Качество критично	Низкая	2–3x	Нет чётких критериев оценки
Оркестратор + субагенты	Декомпозируемая задача	Средняя	3–5x	Подзадачи сильно зависимы
Команды агентов	Параллельные длительные задачи	Высокая	5–10x	Общие ресурсы
Шина сообщений	Событийные пайплайны	Высокая	Зависит от потока	Линейный workflow
Общее состояние	Совместная аналитика	Высокая	3–7x	Нет разрешения конфликтов

Мультиагентные системы — мощный инструмент, но сложность архитектуры должна быть пропорциональна задаче. Начинайте с простого. Усложняйте по данным из production, а не по ощущениям на этапе проектирования.

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

---

Подписывайтесь на наш канал: @vibelogia

Поделимся опытом

hello@vibelab.ru

8 800 201 85 68

Написать в Telegram