Типичная ошибка при построении AI-агента: Начинаешь с простого бота → добавляешь функции → добавляешь интеграции → добавляешь логику
Через два месяца получается монстр с промптом на 10 000 токенов, который стоит дорого, работает медленно и ведёт себя непредсказуемо.
Решение: декомпозиция на специализированных агентов.
Проблема монолитного агента
Когда один агент делает всё, возникают проблемы.
Что происходит с универсальным агентом
| Проблема | Последствие |
|---|---|
| Огромный контекст | каждый запрос съедает тысячи токенов |
| Медленная обработка | модель с трудом обрабатывает гигантские инструкции |
| Непредсказуемое поведение | смешанная логика создаёт хаос |
| Сложная отладка | непонятно, на каком этапе произошла ошибка |
Это классическая монолитная архитектура, перенесённая в мир AI-агентов.
Минимальная декомпозиция
Самый простой способ избежать монстра — разбить универсального агента на специализированных.
Пример: HR-процесс найма
Было: один агент-универсал
• Парсит резюме
• Общается с кандидатом
• Оценивает ответы
Стало: три специализированных агента
• Parser Agent — извлекает данные из резюме
• Speaker Agent — беседует с кандидатом
• Scorer Agent — выставляет оценку
Каждый агент получил чёткую инструкцию и стал работать стабильнее. Появилась возможность дорабатывать компоненты независимо.
Линейная архитектура (Pipeline)
Агенты передают результат друг другу по цепочке. Эстафета с обработкой данных.
Когда использовать
Pipeline подходит для задач с чёткой, последовательной логикой выполнения.
Примеры:
• Обработка заявок (приём → проверка → исполнение)
• Анализ документов (извлечение → классификация → резюме)
• HR-процессы (скрининг → интервью → оценка)
Преимущества и недостатки
| Плюсы | Минусы |
|---|---|
|
Специализация агентов Явная передача контекста Простота реализации Лёгкая отладка Модульность |
Низкая отказоустойчивость Нет параллелизма Падение одного агента валит процесс |
Pipeline — самая простая и понятная архитектура. Идеальна для MVP и стандартных процессов.
Оркестратор (Router + Workers)
Центральный агент-оркестратор анализирует задачу и распределяет работу между специализированными агентами.
Когда использовать
- Разнородные задачи — запросы требуют разных типов обработки
- Много инструментов — десятки API и сервисов
- Строгие SLA — нужны fallback-сценарии и мониторинг
- Масштабирование — динамическое добавление агентов
Пример: AI-ассистент для корпоративного портала
Запрос пользователя
↓
Orchestrator Agent (анализ и маршрутизация)
↓
┌───┴───┬───────┬────────┐
↓ ↓ ↓ ↓
HR Agent IT Agent Finance Legal
↓ ↓ ↓ ↓
└───┬───┴───────┴────────┘
↓
Ответ пользователю
Агенты-специалисты:
• HR Agent — вопросы по кадровой политике, отпускам
• IT Agent — технические проблемы, доступы
• Finance Agent — командировки, компенсации
• Legal Agent — договоры, юридические вопросы
Оркестратор классифицирует запрос и передаёт нужному агенту.
Преимущества и недостатки
| Плюсы | Минусы |
|---|---|
|
Гибкость добавления агентов Параллельная работа Централизованный контроль |
Сложность логики роутинга Единая точка отказа Дополнительные LLM-вызовы |
Оркестратор — стандарт для корпоративных систем с разнородными задачами.
Рой (Swarm)
Агенты работают как равноправные участники. Передают задачи друг другу, обмениваются информацией, совместно решают проблемы.
Когда использовать
- Генерация гипотез — рассмотрение проблемы с разных сторон
- Анализ документов — разные агенты для разных типов контента
- Сложные reasoning задачи — итеративное улучшение решения
Пример: анализ инвестиционных предложений
Команда агентов анализирует стартап:
• Market Analyst — размер рынка, конкуренты
• Financial Analyst — финансовые показатели
• Tech Analyst — технологические решения
• Risk Analyst — потенциальные риски
• Synthesis Agent — итоговое заключение
Агенты запрашивают информацию друг у друга:
Market Analyst → Financial Analyst: "Какая средняя выручка конкурентов?"
Tech Analyst → Risk Analyst: "Насколько критична зависимость от библиотеки?"
Преимущества и недостатки
| Плюсы | Минусы |
|---|---|
|
Коллективный интеллект Адаптивность Глубина анализа |
Сложность координации Высокая стоимость Непредсказуемость времени |
Рой — самый дорогой подход. Оправдан, когда приоритет — качество анализа, а не скорость.
Гибридная архитектура
В продакшене комбинируют разные подходы в зависимости от задачи.
Когда использовать
- Сложные продуктовые системы — разные части решают разные классы задач
- Высокие требования к производительности — оптимизация под разные SLA
- Эволюция системы — адаптация под новые требования
Пример: расширенный корпоративный ассистент
Уровень 1: Оркестратор
• Принимает запросы пользователей
• Маршрутизирует к подагентам-специалистам
Уровень 2: Pipeline для обработки заявок
• Приём заявки
• Финансовые расчёты
• Опрос сотрудника
Уровень 3: Pipeline для мониторинга
• TurnoverTrendAgent — динамика увольнений
• ProductivityTrendAgent — тренды производительности
• SatisfactionTrendAgent — удовлетворённость
Преимущества и недостатки
| Плюсы | Минусы |
|---|---|
|
Оптимальность решения Масштабируемость Гибкость |
Сложность архитектуры Требует опытной команды Долгая разработка |
Гибрид — для enterprise-решений с разнородными требованиями.
Сравнение архитектур
| Критерий | Pipeline | Оркестратор | Swarm | Гибрид |
|---|---|---|---|---|
| Сложность задач | Простые | Средние | Сложные | Любые |
| Время разработки | Быстро | Среднее | Долго | Долго |
| Предсказуемость | Высокая | Высокая | Низкая | Средняя |
| Стоимость работы | Низкая | Средняя | Высокая | Зависит |
| Масштабируемость | Ограничена | Хорошая | Отличная | Отличная |
| Отладка | Простая | Средняя | Сложная | Сложная |
Практические рекомендации
Начинайте с простого и усложняйте только при появлении реальных ограничений.
Один агент — по умолчанию
Если задача укладывается в контекст модели (<50% от максимума), логика линейная, достаточно одного агента.
Для MVP и пилотов один агент — оптимальный выбор:
• Быстрее в разработке
• Дешевле в эксплуатации
• Проще в отладке
К декомпозиции переходите при проблемах с качеством, стоимостью или масштабированием.
Pipeline — следующий шаг
Когда агент начинает делать всё сразу, а промпт разрастается — разделите процесс на этапы.
Pipeline закрывает большинство продуктовых сценариев. Большинство задач можно разложить на последовательные этапы.
Оркестратор — для сложных систем
Если запросы разнородные, много интеграций, нужны SLA — вводите центральный роутинг.
Оркестратор распределяет задачи и помогает масштабировать систему.
Swarm — для глубокой аналитики
Рой используется точечно: где важны экспертиза с разных сторон и сложный reasoning.
Это самый дорогой подход, оправдан когда приоритет — качество анализа.
Главный принцип
Проектируйте систему так, чтобы можно было легко переключаться между архитектурами.
Начинайте с одного агента и постепенно усложняйте без переписывания кода.
Архитектура должна решать реальные проблемы, а не создавать новые. Мультиагентность не самоцель.
Ключевые выводы:
- Один агент — для MVP и простых задач
- Pipeline — для большинства продуктовых сценариев
- Оркестратор — для корпоративных систем с разными запросами
- Swarm — для сложной аналитики и генерации гипотез
- Гибрид — для enterprise-решений
Правильная стратегия: начать с простого и усложнять по мере необходимости.
Частые вопросы
Когда переходить от одного агента к мультиагентной системе?
Когда промпт превышает 50% контекста модели, появляются проблемы с качеством или стоимостью, либо нужно масштабировать систему. Для MVP достаточно одного агента. Декомпозиция нужна при реальных ограничениях, а не «на будущее».
Какая архитектура подходит для чат-бота техподдержки?
Оркестратор. Запросы разнородные (технические проблемы, вопросы по продуктам, биллинг), нужна маршрутизация к специализированным агентам. Pipeline не подойдёт — нет чёткой последовательности. Swarm избыточен — не требуется глубокий анализ.
Как оценить стоимость мультиагентной системы?
Считайте количество LLM-вызовов. Pipeline: N агентов = N вызовов. Оркестратор: +1 вызов на роутинг. Swarm: непредсказуемое количество (агенты обмениваются запросами). Тестируйте на типовых сценариях и умножайте на ожидаемый объём запросов.