Multi-agent системы: паттерны 2026

Multi agent llm — это архитектурный подход, где решение разбивается на независимые агенты с разными ролями и контрактами обмена. Статья даёт практические паттерны 2025–2026 годов: роли, коммуникацию, координатор, фреймворки и критерия «overkill».

• Планировщик (Planner) — разбивает цель на задачи, расставляет приоритеты. Рекомендуемые ресурсы: 0.5 vCPU, 512 MB RAM, тип инстанса t3.small (AWS) ~0.02 USD/час (~15 USD/мес при 24/7). Часто запускается как синхронный сервис с латентностью 50–200 мс.
• Исполнитель (Executor / Worker) — вызывает LLM, встраивает в пайплайн действий, запускает внешние API. Рекомендуется 1–2 vCPU, 1–4 GB RAM; при использовании локальных LLM или CUDA-ускорения — 6–16 GB GPU RAM. Стоимость: t3.medium ~0.04 USD/час, GPU-узел типа g5 на 16GB — 0.8–2.0 USD/час.
• Оракул (Oracle / Knowledge Agent) — отвечает за поиск и подачу контекстных данных (векторный поиск, база фактов). Ресурсы: 2 vCPU, 4–8 GB RAM + SSD IOPS для хранения индексов. Типичный индекс для 10M документов: 500 GB, стоимость хранилища ~20–100 USD/мес.
• Валидация (Verifier) — проверяет ответы на корректность, безопасность и соответствие политике; может запускать дополнительный LLM или rule-engine. SLA валидации: 95–99% прохождения, среднее время проверки 200–800 мс. Ресурсы: 1 vCPU, 1 GB RAM.
• Router / Gateway — распределяет задачи между исполнителями, реализует балансировку и приоритеты, следит за очередями. Рекомендуется 0.5–1 vCPU, 512 MB RAM; задаёт лимиты по retry и backoff.
• Store / Memory Agent — управляет долговременной памятью с TTL, отвечает за шардирование и CAS-операции. Ресурсы зависят от объёма: Redis для сессий (32 GB RAM) или Postgres для истории (1–2 TB хранилища).

Практический пример: для proof-of-concept (PoC) на 100 активных сессий в сутки нужно минимум 3 исполнителя + 1 планировщик + 1 оракул. Итоговые расходы облака (без LLM токенов) — ~120–300 USD/мес; при 1000 сессий это масштабируется до 800–1 500 USD/мес.

Как назначать количество агентов на роль?

Подход «на пользователя» (per-session agents) оправдан для долгоживущих сессий, но приводит к высокому потреблению памяти. Альтернатива — пул воркеров: фиксированный pool size N, где N рассчитывается по формуле N = ceil(R * d / T), где R — среднее число запросов в секунду, d — среднее время обработки (сек), T — средняя нагрузка на один воркер (сессионные контексты). Пример: R=20 req/s, d=0.5 s → N=10.

Шаг 2: коммуникация

Коммуникация между агентами определяет надёжность и стоимость системы. Ниже описаны паттерны с конкретными параметрами и примерами инструментов 2025–2026 годов.

• HTTP request-reply — удобен для простых синхронных цепочек. Латентность сетевого вызова 5–50 мс внутри одного облачного региона; общий отклик с LLM 100–800 мс. Подходит для Planner→Executor вызовов, где требуется немедленный результат.
• gRPC — экономит пропускную способность и даёт бинарный протокол; хорош для межсервисной коммуникации с требованиями <200 мс. Используйте с потоковой сериализацией и deadline 500–1500 мс.
• Pub/Sub / Broker (Redis Streams, Kafka, RabbitMQ) — для асинхронных задач, батчинга и retries. Рекомендации: Redis Streams при latency-sensitive задачах (P99 < 5 ms), Kafka для длительной истории событий (log retention >7 дней). Параметры: batch.size = 16–64, commit interval = 100–500 ms, max.retries = 3, backoff initial = 500 ms.
• WebSocket / Server-Sent Events — для двунаправленных соединений с фронтом, чтобы отправлять промежуточные результаты пользователю. Поддерживать heartbeat 10–30s, TTL соединения 60s для восстановления.

Пример настройки очереди на Redis Streams для агентной системы (практические параметры): stream key — tasks:stream, consumer group — agents-group, блокировка чтения (XREADGROUP) timeout 1000 ms, лимит сообщений 20. Для production рекомендуем retention policy: maxlen=~100000, обычно 1–7 дней хранения событий при интенсивности 1000 msg/min.

# Псевдокод работы consumer с Redis Streams
while True:
    messages = xreadgroup(group='agents-group', consumer=id, count=20, block=1000)
    if not messages:
        continue
    for msg in messages:
        process(msg)
        xack(stream, 'agents-group', msg.id)

При использовании multi agent llm коммуникация часто включает передачу токенов контекста и ссылок на документы вместо полного контента. Это снижает сеть на 40–80% по сравнению с передачей больших payload'ов.

Стратегии ретраев и дедлайнов

Рекомендованная стратегия: максимум 3 попытки с экспоненциальным бэкоффом (500 ms → 1 s → 2 s) и сквозной deadline для задачи 10–30 секунд; если задача не завершилась — перевод в режим «failure with compensating action» (отмена, откат, фоллбек на другой модельный путь). Для задач, чувствительных к порядку (transactions), применяйте транзакционные паттерны с idempotency key и TTL 60–300 секунд.

Шаг 3: координатор

Координатор (orchestrator) лежит в центре multi agent llm: он управляет жизненным циклом задач, распределяет роли, делает лидер-выбор и собирает результат. В 2025–2026 паттерны эволюционировали в сторону лёгких координаторов с внешним хранилищем состояния (Redis/Postgres) и минимальной бизнес-логикой.

Ниже — конкретный набор контрактов и механизмов, который применяем при реальных деплойментах.

• Heartbeat и лидер-выбор: heartbeat interval 5s, lease TTL 15s. Лидер берёт lock через Redis SET resource:leader NX PX 15000. При падении лидера другой экземпляр пытает получить lock через каждые 5s.
• Состояния задач: finite-state machine с конкретными статусами: NEW → SCHEDULED → RUNNING → WAITING_FOR_ORACLE → VALIDATING → COMPLETED | FAILED. Каждое состояние хранится в Postgres с полями updated_at, attempt_count (max 3) и last_error (VARCHAR 512).
• Атомарность и idempotency: все transitions выполняются через транзакции БД и используют idempotency-key. Для Redis Streams — проверяйте уже обработанные message IDs в таблице processed_messages.
• Timeouts: per-stage timeout: Planner 3s, Executor 30s (можно увеличить для генерации длинных ответов), Oracle 5s, Verifier 10s. Если таймаут превышен — координатор делает compensating action в 1–3s и переводит задачу в FAILED или RE-RUN в зависимости от политики.

# Минимальный пример координатора на Python + aioredis (псевдокод)
async def coordinator_loop():
    while True:
        task = await fetch_next_task()
        if not task:
            await asyncio.sleep(0.2)
            continue
        await claim_task(task.id)
        try:
            await schedule_to_worker(task)
            await wait_for_completion(task.id, timeout=30)
            mark_completed(task.id)
        except Exception as e:
            increment_attempt(task.id)
            if attempts > 3:
                mark_failed(task.id, str(e))
            else:
                requeue(task.id)

Практический кейс: в продакшене я запускал координатор как три реплики с ELB + healthchecks. Лидер занимал lock в Redis. При нагрузке 500 TPS координатор держал 3 реплики, каждая с CPU 2 vCPU и 2 GB RAM, latency P95 для task pick — 20–40 ms.

Какие фреймворки?

К 2026 году экосистема инструментов для multi agent llm выросла. Ниже — проверенные мной и командами практические варианты с конкретными сценариями применения.

• LangChain — удобен для быстрого прототипа и соединения LLM с инструментами (tool-using agents). Используем для PoC и workflow orchestration с небольшими требованиями к latency. Поддерживает function-calling, chains и memory. На боевом уровне подходит, если обработка не более 200 req/s и не требуется сложное распределение state.
• AutoGen (Microsoft) — даёт удобные паттерны для dialog-агентов и role-playing, полезен для сложных chains of thought и симуляции нескольких агентов. Хорошо взаимодействует с Azure OpenAI и внутренними LLM.
• Ray (Serve + Ray Core) — для масштабируемой оркестрации вычислений и stateful actors. Применяем для workloads с интенсивными вычислениями, batching и GPU-шардированием; выдерживает тысячи актеров при правильной конфигурации. Рекомендован для продакшена при load > 500 req/s.
• LlamaIndex / Vector DB — для управления retrieval-частью (RAG). Используем вместе с Milvus или Pinecone для векторных индексов — realistic latency на 1M векторов ≈ 5–20 ms при поиске топ-10.
• Open-source orchestrators — Temporal и Cadence для надёжной долгоживущей оркестрации бизнес-процессов; хороши там, где нужна гарантия выполнения задач (exactly-once semantics). Temporal полезен для workflows с шагами, ревизиями и audit trail.

Практический набор для типичного старта 2026: LangChain + Redis Streams + LlamaIndex + Ray Serve (если требуется горизонтальное масштабирование и GPU batching). Стоимость стека для MVP: 300–800 USD/мес без учёта токенов LLM.

Ниже внутренние материалы для углубления по интеграции и MLOps:

• Практики AI — статьи по интеграции агентов с внешними API и хранилищами.
• ML Ops — деплой, мониторинг и CI/CD для моделей и агентов.

Пример связки: LangChain + Ray Serve + Redis

Сценарий: планировщик на LangChain генерирует task descriptors, кладёт в Redis Stream; pool исполнителей Ray Serve читает stream, параллельно вызывает LLM через async client; результаты сохраняются в Postgres для историчности. Параметры: batch size Ray = 8, max concurrency per replica = 16, Redis retention = 7 дней.

Когда overkill?

Мульти-агентность даёт гибкость, но не всегда оправдана. Конкретные критерии «overkill» на 2026 год:

• Бюджет на проект меньше 200 USD/мес и прогнозируемая нагрузка < 100 запросов в день — проще запустить единый сервис с LLM и кешем.
• Требование к latency P95 < 50 ms для диалогов — multi agent с сетевыми вызовами и внешними брокерами добавит задержку; монолитный in-process вызов модели или локальная интеграция будет быстрее.
• Сложность логики меньше 3 шагов (input → LLM → output) и нет необходимости верифицировать ответы — агентность добавляет ненужную оркестрацию и стоимость разработки.
• Команда не имеет опыта DevOps и распределённых систем. Ошибки в координации, retries и семантических дедлайнах приводят к багам, которые сложнее отлаживать, чем в монолите.

Если ваш MVP — бот, выполняющий 1–2 простых действия (ответ на FAQ, поиск по базе) и вы прогнозируете user growth < 10k пользователей в год, лучше начать с single-agent архитектуры и добавить мульти-агентность при росте требований к concurrency и модульности.

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

Практические пороги для перехода на мульти-агент

Рекомендованные метрики для решения о переходе:

• Ежедневные активные сессии > 1 000 и/или пиковая нагрузка > 200 req/s.
• Требование разделения ответственности (например, разные команды развивают Planner и Verifier отдельно).
• Необходимость параллельной обработки шагов: уменьшение latency за счёт распараллеливания критично.

Частые вопросы

Как начать MVP с multi agent llm без больших затрат?

Начните с минимальных ролей: один Planner и пул Executors (2–4 экземпляра). Используйте облачные серверы низкой мощности (t3.small/t3.medium) и managed Redis (или бесплатный Redis на малых объёмах). Для LLM используйте cloud API с pay-as-you-go, контролируйте токены через лимиты: max tokens/response = 256, max requests/user/day = 50. Бюджет первого месяца: ориентируйтесь на 200–800 USD, включая токены, инфраструктуру и мониторинг. Сохраняйте контекст не в сессиях, а через ссылки на документы, чтобы уменьшить трафик.

Что делать с безопасностью и приватностью данных в multi-agent системах?

Жёсткая сегментация ролей помогает: Oracle и Store могут иметь отдельные IAM-права; Verifier — отдельная audit-ролевая зона. Шифруйте в покое (AES-256) и в движении (TLS 1.3). Для PII применяйте дедупликацию и маскирование перед отправкой в сторонние LLM: удалять поля email/SSN и хранить оригиналы в защищённом хранилище. Логийте меньше: храните резюме операций вместо полного payload. Наконец, используйте SLA по ретенции логов: 30–90 дней для debug, и 7 лет для audit при необходимости compliance.

Почему стоит тестировать агенты отдельно перед интеграцией?

Тестирование отдельных агентов даёт быстрый feedback loop: вы измеряете latency, failure rate и correctness per-role. Unit-тесты для Planner проверяют разбиение задач; для Executor — вызовы LLM mock; для Oracle — latency и recall@k. В CI запускайте интеграционные тесты с emulated Redis и fake LLM (соглашение response fixtures). Это сокращает время отладки в продакшене до 50–70%.

Сколько стоит содержание multi-agent продукта в продакшне?

Стоимость сильно варьируется. Для типичного SMB-продукта с 5 000 ежемесячных активных пользователей и средней интенсивностью 20 запросов/пользователь/месяц, инфраструктура (compute, storage, broker) — 1 000–5 000 USD/мес; LLM-токены добавляют 2 000–10 000 USD/мес в зависимости от модели и длины контекста. Для enterprise с высоким SLA — 10 000–100 000 USD/мес. В расчётах учитывайте резерв на мониторинг (Prometheus + Grafana ~100–400 USD/мес), логирование (ELK/Datadog ~200–1 000 USD/мес) и резервирование GPU для локальных моделей ~1 000–8 000 USD/мес.