Паттерны оркестрации LLM-агентов: что победило в корпоративном проде

Разговоры про «правильную архитектуру агентов» шли с тех пор, как у агентов вообще появились инструменты. Multi-agent, ReAct, Plan-and-Execute - терминов много, внятных сравнений на реальных задачах было мало. За последний год у нас накопилось достаточно практики, чтобы сказать что-то конкретное. Не «паттерн X лучше», а «для задачи Y паттерн X работает, для задачи Z - нет, и вот почему».

Три задачи, три разных паттерна, три разных итога.

Задача первая: incident triage

Это наш RCA-агент поверх Zabbix + Loki. Алерт прилетел - агент собирает контекст, строит гипотезу, пишет дежурному.

Мы начинали с ReAct (Reasoning + Acting): агент шаг за шагом рассуждает, решает, какой инструмент вызвать, смотрит на результат, продолжает. Выглядело логично - инцидент непредсказуем, жёсткий план не поможет.

На практике ReAct дал проблему, которую мы не ожидали: агент застревал в петлях. Видит ошибку в логах, идёт в Zabbix за метриками, видит там аномалию, возвращается в Loki за контекстом этой аномалии - и так несколько кругов. Каждый круг - вызов LLM, задержка, стоимость токенов. При этом конечный ответ не становился лучше после второго круга.

Мы зафиксировали максимум 3 итерации и добавили явный «план» на старте: сначала Loki за последние 15 минут, потом Zabbix за метриками, потом синтез. Это уже ближе к Plan-and-Execute, чем к чистому ReAct. Агент стал предсказуемым и дешевле. Качество диагностики при этом не упало - скорее чуть выросло, потому что порядок сбора контекста стал осмысленным.

Вывод по incident triage: ReAct хорош теоретически, но в инциденте, где есть шум и ложные корреляции, нужны ограничения. Облегчённый Plan-and-Execute с фиксированным порядком инструментов и потолком итераций работает лучше.

Задача вторая: knowledge retrieval

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

Здесь мы с самого начала попробовали простую цепочку без агентной оркестрации: пользователь -> embeddings-поиск -> reranker -> LLM. Сработало на базовых запросах. Но посыпалось на составных: «покажи, как настроить nginx для нашего кластера и какие ограничения в политике ИБ для внешних портов». Это два поиска, результаты которых нужно свести вместе.

Multi-agent здесь дал правильное разделение: оркестратор принимает запрос, декомпозирует на подзадачи, каждую отдаёт агенту-специалисту (search-agent для KB, policy-agent для ИБ-документов), потом синтезирует ответы. Каждый агент маленький и предсказуемый, оркестратор не лезет в детали поиска.

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

Вывод по knowledge retrieval: multi-agent даёт ценность именно на составных запросах с разными источниками данных. На простых запросах оркестрация - лишний оверхед и лишние токены. Классификатор сложности запроса на входе обязателен.

Задача третья: конфигурационный аудит

Периодическая задача: обойти инфраструктуру клиента, собрать конфиги, проверить на соответствие baseline-у, сформировать отчёт. Это не интерактив - это батч с детерминированным результатом.

ReAct здесь даже не рассматривали: задача хорошо декомпозируется заранее. Plan-and-Execute в чистом виде - составить план обхода, потом выполнить каждый шаг - подходит идеально.

Агент-планировщик принимает список хостов и категорий проверок, строит граф задач. Агент-исполнитель проходит по задачам, вызывает инструменты (SSH, API Ansible, запросы к инвентарю), собирает результаты. Агент-синтезатор сводит результаты в читаемый отчёт.

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

Вывод по конфигурационному аудиту: Plan-and-Execute для батчевых задач с детерминированной структурой - просто правильный выбор. Персистентный граф задач с восстановлением после сбоев делает задачу надёжной без сложной логики в промпте.

Что общего между тремя случаями

Если смотреть поперёк задач, видны два фактора выбора паттерна.

Первый - предсказуемость структуры задачи. Если структура известна заранее (аудит, батч, отчёт) - Plan-and-Execute. Если структура зависит от того, что агент найдёт по пути (инцидент, исследование) - ReAct, но с ограничениями. Если задача композитная и хорошо делится на независимые части - multi-agent.

Второй - стоимость ошибки. ReAct в инциденте ошибается дорого: петля из пяти итераций в два часа ночи задерживает ответ. Plan-and-Execute ошибается дешевле: провалил шаг - перезапустил шаг. Multi-agent ошибается предсказуемо: если упал один агент-специалист, оркестратор это видит.

Отдельное наблюдение по мониторингу агентов: без трейсов на уровне span-ов мы бы не увидели, что ReAct на incident triage делает лишние круги. Число итераций на запрос - метрика, которую теперь смотрим отдельно для каждого агента.

Где мы сейчас

Ни один из трёх паттернов не стал «дефолтным» для всех задач. Это раздражает, потому что хочется единого шаблона, но практика показывает: паттерн - следствие структуры задачи, а не предпочтение архитектора.

Одна вещь, которую мы планируем проверить в ближайших спринтах: гибридный оркестратор, который начинает как Plan-and-Execute, но позволяет агенту-исполнителю отклоняться от плана при неожиданных находках. По ощущениям, это могло бы закрыть пробел между incident triage и аудитом. По факту - пока не знаем.