Архитектура мульти-агентных систем: паттерны и best practices

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

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

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

Обязанности оркестратора

• Приём и классификация входящего запроса (NLU — понимание намерения)
• Декомпозиция сложной задачи на атомарные подзадачи
• Выбор подходящего агента-специалиста для каждой подзадачи
• Передача контекста между агентами (результат одного → вход для другого)
• Агрегация результатов и формирование финального ответа
• Обработка ошибок: ретрай, fallback, эскалация на человека
• Логирование всех действий для отладки и аудита

Оркестратор реализуется как Markdown-файл в .claude/agents/orchestrator.md с чётким описанием: какие агенты доступны, когда их вызывать, как передавать контекст, что делать при ошибках. Это декларативный подход — вы описываете поведение, а AI выполняет.

Каждый агент-специалист имеет три компонента: системный промпт (его экспертиза и правила), набор инструментов (MCP tools, которые ему доступны) и область ответственности (какие задачи он может и не может выполнять). Чёткие границы критичны — агент не должен лезть в чужую зону.

Примеры специализированных агентов

Контент-агент: системный промпт описывает tone of voice бренда, форматы контента, целевую аудиторию. Инструменты: генерация текста, подбор хештегов, проверка уникальности. Область: создание и редактирование контента. Не может: публиковать, анализировать метрики.

Аналитика-агент: промпт описывает ключевые метрики, бенчмарки, формат отчётов. Инструменты: чтение данных из Sheets, Instagram Insights, расчёт метрик. Область: сбор, анализ и интерпретация данных. Не может: создавать контент, публиковать.

Публикация-агент: промпт описывает правила публикации, расписание, compliance-требования. Инструменты: публикация в Instagram, Telegram, планирование в Calendar. Область: публикация утверждённого контента. Не может: создавать контент, изменять стратегию.

DevOps-агент: промпт описывает инфраструктуру, деплой-процесс, мониторинг. Инструменты: SSH, Docker, pm2, nginx. Область: деплой, мониторинг, диагностика. Не может: менять бизнес-логику, удалять данные.

Агенты общаются через два протокола. MCP (Model Context Protocol) — для взаимодействия агента с инструментами. A2A (Agent-to-Agent Protocol от Google) — для взаимодействия агентов между собой. MCP стандартизирует "как агент использует инструмент", A2A стандартизирует "как агент общается с другим агентом".

MCP: агент → инструмент

MCP-сервер предоставляет tools (инструменты), resources (ресурсы для чтения) и prompts (шаблоны запросов). Агент вызывает tool — например, sheets_read_range — с параметрами, получает результат и использует его для принятия решения. Транспорт: stdio (для локальных серверов) или HTTP с SSE (для удалённых). MCP-серверы stateless — каждый вызов независим.

A2A: агент → агент

A2A Protocol определяет, как один агент отправляет задачу другому. Каждый агент имеет Agent Card — описание его возможностей. Оркестратор читает карты всех агентов и знает, кому что поручить. Коммуникация идёт через Tasks: оркестратор создаёт Task с описанием, отправляет агенту, получает результат. Task может быть синхронным (ждать ответа) или асинхронным (получить уведомление через SSE).

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

Уровни состояния

• Session state — текущий диалог пользователя с ботом. Хранится в памяти или Redis. Живёт минуты-часы.
• Task state — состояние выполняемой задачи (в процессе, ожидает, завершена). Хранится в PostgreSQL. Живёт часы-дни.
• Business state — данные бизнеса (клиенты, заказы, метрики). Хранится в Sheets/PostgreSQL. Живёт вечно.
• Agent memory — долгосрочная память агента о предпочтениях, паттернах, решениях. Хранится в файлах или векторной БД.

Критично: каждый агент получает только тот контекст, который ему нужен. Контент-агенту не нужна финансовая информация. Аналитика-агенту не нужна история переписки с клиентом. Минимальный контекст = меньше токенов = быстрее ответ = дешевле.

В мульти-агентной системе ошибки неизбежны: API недоступен, агент вернул некорректный результат, таймаут, rate limit. Архитектура должна быть resilient — устойчивой к сбоям.

Стратегии обработки ошибок

• Retry с exponential backoff: при 429 или 5xx — ждать 1с, 2с, 4с, 8с
• Fallback agent: если primary агент недоступен — использовать backup с меньшими возможностями
• Circuit breaker: после N ошибок подряд — прекратить вызовы на M секунд, отправить алерт
• Graceful degradation: если Sheets API недоступен — сохранить данные локально и синхронизировать позже
• Human escalation: если агент не уверен в результате (confidence < threshold) — передать человеку
• Idempotency: каждая операция должна быть безопасна для повторного выполнения

Мульти-агентная система — это распределённая система, и к ней применимы те же практики мониторинга. Три столпа observability: логи (что произошло), метрики (сколько и как быстро), трейсы (путь запроса через агентов).

Что мониторить

• Latency каждого агента: сколько времени занимает обработка запроса
• Token usage: сколько токенов тратит каждый агент на каждую задачу
• Error rate: процент ошибок по каждому агенту и MCP-серверу
• Task completion rate: какой процент задач завершается успешно
• Queue depth: сколько задач ожидают обработки (признак перегрузки)
• Cost per request: стоимость обработки одного запроса через всю цепочку

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

Мульти-агентная система масштабируется горизонтально. Каждый агент — это независимый процесс, который можно запустить в нескольких экземплярах. Очередь задач (Redis, RabbitMQ) распределяет нагрузку между экземплярами. MCP-серверы stateless — можно запускать сколько угодно копий за балансировщиком.

Этапы масштабирования

• Этап 1 (MVP): все агенты на одном сервере, pm2 для управления процессами
• Этап 2 (рост): выделенный сервер для каждого MCP, Redis для очередей
• Этап 3 (масштаб): Kubernetes, горизонтальное масштабирование агентов, мониторинг в Grafana
• Этап 4 (enterprise): multi-region, dedicated GPU для локальных моделей, compliance и аудит

Рассмотрим конкретную архитектуру для автоматизации маркетинга. Оркестратор получает задачу: "Подготовить и опубликовать контент на неделю для Instagram". Вот как он её декомпозирует:

• Шаг 1: Аналитика-агент → анализирует метрики прошлой недели, определяет лучшие типы контента
• Шаг 2: Стратегия-агент → на основе аналитики создаёт контент-план на неделю (темы, форматы, даты)
• Шаг 3: Контент-агент → генерирует тексты для каждого поста по плану
• Шаг 4: Критик-агент → проверяет качество каждого текста, даёт рекомендации по улучшению
• Шаг 5: Контент-агент → улучшает тексты на основе критики (recursive arguing)
• Шаг 6: Публикация-агент → планирует посты в Calendar, подготавливает к публикации
• Шаг 7: Оркестратор → отправляет контент-план на утверждение человеку через Telegram

Весь процесс занимает 5-10 минут вместо 3-4 часов ручной работы. И качество контента выше — потому что каждый этап выполнен специалистом, а не одним перегруженным SMM-менеджером.

Мульти-агентная архитектура мощна, но её легко overcomplicate. Вот распространённые ошибки:

• God Orchestrator — оркестратор, который делает всё сам. Если промпт оркестратора > 500 слов — декомпозируйте.
• Agent sprawl — слишком много мелких агентов. 3-7 агентов оптимально, 20+ — хаос.
• Circular dependencies — агент A вызывает B, B вызывает A. Всегда DAG (направленный ациклический граф).
• Shared state — агенты пишут в одно хранилище без координации. Race conditions гарантированы.
• No fallback — система полностью ломается при недоступности одного API. Всегда degradation.
• Over-engineering — начинать с Kubernetes и микросервисов. Начните с pm2 на одном сервере.

Мульти-агентная архитектура — это следующий эволюционный шаг после одиночных AI-ассистентов. Паттерн оркестратора + специализированные агенты + MCP/A2A протоколы = система, которая может выполнять сложные бизнес-процессы автономно. Ключевые принципы: чёткая специализация, минимальный контекст, устойчивость к ошибкам, наблюдаемость. Начинайте просто, масштабируйте по мере роста. И помните: лучшая архитектура — та, которая решает вашу конкретную задачу, а не та, которая выглядит впечатляюще на диаграмме.