А.2 Архитектурные паттерны агентов

Зачем вообще нужны паттерны?

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

Метафора

Представьте, что LLM - это повар высшего класса. Он умеет готовить любые блюда. Но если вы просто бросите его на кухне и скажете «готовь», он растеряется.

Паттерны - это разные форматы работы ресторана:

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

Plan-and-Execute - это приготовление банкета по заранее утверждённому меню. Сначала план, потом исполнение.

Multi-Agent - это команда: шеф-повар, су-шеф, заготовщик, каждый отвечает за свою зону.

Без паттерна агент просто отправляет запрос в LLM, получает ответ и останавливается. Это не агент, это LLM с одним вызовом.

Три основных паттерна покрывают 95% реальных применений агентов. Остальные 5% - это гибриды и исследовательские архитектуры, которые вам, скорее всего, не понадобятся в ближайший год.

Три основных паттерна, которые покрывают 95% реальных применений.

Зачем вообще нужны паттерны? LLM сама по себе - это двигатель. Она умеет рассуждать, но не знает, как организовать свою работу. Три основных паттерна покрывают 95% реальных применений. Сравните их потоки управления на схеме ниже.

Рисунок. Паттерны агентов: ReAct vs Plan-and-Execute vs Supervisor

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

Первый паттерн, с которого почти все начинают, - ReAct (Reason + Act).

Он самый простой и прозрачный: агент думает вслух, делает один шаг, видит результат, снова думает - и так до ответа.

Это как шахматист, который объявляет каждый ход перед тем, как передвинуть фигуру. Идеально для диалогов и коротких задач. Но когда шагов становится много, ReAct начинает спотыкаться: слишком много вызовов LLM, нет долгосрочного плана.

А.2.1 ReAct (Reason + Act)

Метафора

Шахматист, который объявляет вслух каждый свой ход и его обоснование, прежде чем передвинуть фигуру. Он не строит план на 20 ходов вперёд, а реагирует на позицию на доске после каждого хода соперника.

Как это работает

Ключевая особенность ReAct , которую часто упускают

Рассуждение и действие чередуются на каждом шаге. Агент не накапливает "незакрытые" рассуждения - каждое рассуждение немедленно приводит к действию или ответу. Это делает ReAct очень прозрачным для отладки: вы висте каждую мысль агента перед каждым действием.

Когда использовать ReAct

Когда НЕ использовать ReAct

ReAct хорош, когда следующий шаг зависит от немедленной реакции среды. А что, если задача сложная: «Подготовь квартальный отчёт, сравни с прошлым годом, найди аномалии и отправь руководителю»?

Здесь агент не может действовать вслепую. Ему нужен план. Сначала составить последовательность действий, проверить её, и только потом выполнять.

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

А.2.2 Plan-and-Execute

Метафора

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

Как это работаете (четыре фазы)

Пример плана для задачи "Подготовить отчёт о продажах за квартал"

· Подключиться к базе данных sales_db

· Выполнить SQL-запрос: SUM(amount) WHERE quarter='Q3'

· Если данных нет - подключиться к резервной БД и повторить

· Сформировать таблицу в Markdown

· Отправить результат пользователю

Ключевая особенность Plan-and-Execute, которую часто упускают: План - это не просто список. План может содержать условную логику ("если А, то Б, иначе В"), параллельные ветки ("выполнить шаги 2 и 3 одновременно") и циклы ("повторять шаг 4, пока не накопится 10 результатов"). Чем богаче язык плана, тем сложнее его генерировать LLM, но тем мощнее агент.

Когда использовать Plan-and-Execute

Когда НЕ использовать Plan-and-Execute

Практическое правило

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

И ReAct, и PlanandExecute работают с одним агентом. Но что делать, если задача настолько разнородна, что один и тот же агент начинает путаться: он должен быть и креативным, и строгим, и работать с цифрами, и писать тексты?

Человек не справляется с десятком ролей одновременно - агенту это тоже не под силу.

Решение - multi-agent systems.

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

А.2.3 Multi-Agent Systems (Супервизор vs Рой)

Вводная метафора (для всего подраздела): Один агент - это универсальный солдат, который умеет и стрелять, и готовить, и чинить радио. Multi-Agent System - это армия, где каждый специализируется на своём: снайперы стреляют, повара готовят, связисты чинят радио. Вопрос не в том, что лучше. Вопрос в том, насколько сложна ваша задача.

Почему один агент может быть недостаточен

· Проблема одного агента / Решение через нескольких агентов

· Огромный системный промпт (тысячи токенов) - агент "забывает" инструкции / Каждый агент имеет короткий, специализированный промпт

· Конфликтующие роли ("ты должен быть креативным И следовать строгим правилам") / Разные агенты для разных ролей

· LLM путается, когда нужно переключаться между разными форматами вывода / Каждый агент выдаёт свой, жёстко определённый формат

· Сложно отлаживать, почему агент сделал неожиданный шаг / Каждый агент делает только свою работу - проще изолировать ошибку

Начнём с централизованного варианта - супервизор.

Это как главный редактор в газете: он не пишет статьи сам, но знает, кто пишет про политику, кто про спорт, кто про экономику. Редактор распределяет темы, следит за дедлайнами, решает, что идёт на первую полосу.

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

Плюс - полный контроль и лёгкая отладка.

Минус - единая точка отказа.

А.2.3.1 Супервизор (Supervisor) - централизованная архитектура

Метафора

Главный редактор в газете. Он не пишет статьи сам, но распределяет темы между журналистами (кто-то пишет про политику, кто-то про спорт, кто-то про экономику), следит за дедлайнами и решает, что идёт на первую полосу. Редактор не делает всю работу - он делает так, чтобы работа была сделана.

Роли в архитектуре Супервизор

Поток работы в архитектуре Супервизор

· Supervisor получает задачу от пользователя

· Supervisor анализирует задачу и решает, какие агенты нужны и в каком порядке

· Supervisor вызывает первого агента с конкретным подзаданием

· Агент выполняет, возвращает результат Supervisor'у

· Supervisor решает: вызвать следующего агента, вернуть результат пользователю или запросить уточнение

· Supervisor сохраняет состояние всего процесса - если что-то упало, можно восстановиться с последнего успешного шага.

Ключевая особенность Супервизора, которую часто упускают

Supervisor - это единая точка отказа, но он же и единая точка наблюдения. Всё, что происходит в системе, проходит через Supervisor. Это означает, что observability (логи, метрики, трейсы) можно повесить на Supervisor и получить полную картину работы системы без сбора данных от каждого агента отдельно.

Когда использовать Супервизора

Когда НЕ использовать Супервизора

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

Это рой - децентрализованная архитектура, где каждый агент знает только свою роль и реагирует на сигналы соседей. Нет диспетчера - поведение возникает как следствие правил взаимодействия. Рой сложнее в отладке, его почти невозможно объяснить начальнику, но он устойчивее (нет единой точки отказа) и может адаптироваться к неожиданностям.

Когда выбирать рой, а когда супервизора - сравним.

А.2.3.2 Рой (Swarm) - децентрализованная архитектура

Метафора

Муравьиная колония. Нет главного муравья, который всем командует. В колонии нет ни одного муравья, который знает "общий план". Каждый муравей знает свою роль и реагирует на сигналы от соседей. Если один муравей нашёл еду - он оставляет феромонный след, и остальные подтягиваются без центральной команды. Интеллект роя - это интеллект связей между агентами, а не каждого агента по отдельности.

Роли в архитектуре Рой

Пример простого роя (обработка текста)

Агент A (Tokenizer) → Агент B (NER) → Агент C (Classifier) → Агент D (Responder)

Каждый агент делает своё и передаёт результат дальше. Никто не говорит Агенту C, что он должен делать после Агента B - это зашито в архитектуру.

Ключевая особенность Роя, которую часто упускают:

В чистом виде рой - это не то, что вы программируете. Вы программируете агентов и правила их взаимодействия. Поведение роя возникает как следствие. Это ближе к симуляции, чем к традиционному программированию.

Когда использовать Рой

Когда НЕ использовать Рой

А.2.3.3 Сравнение Супервизора и Роя

Практическое правило выбора между Супервизором и Роем

· Если вам нужно объяснить клиенту или начальнику, как система работает → Супервизор. (Рой вы не сможете объяснить предсказуемо.)

· Если вы пишете научную статью или исследуете новое поведение → Рой.

· Если вы не уверены → начинайте с Супервизора. Переход от Супервизора к Рою возможен, обратный путь - переписывание всего.

Пример реализации Supervisor-архитектуры: GigaCowork (Сбер)

Платформа GigaCowork от Сбера - это Supervisor-система, где:

· Оркестратор распределяет задачи между агентами

· Агенты работают в изолированных рабочих пространствах

· Инструменты подключаются через протокол MCP (CRM, ERP, 1С, почта)

· Человек утверждает финальное решение (HITL)

Настройка - через текстовое описание процесса на естественном языке, без кода. Агенты могут работать параллельно, а Supervisor собирает результаты .

Supervisor не абстракция. Это работающая архитектура для enterprise-автоматизации бэк-офиса.

Резюме по архитектурным паттернам (таблица выбора)

Паттерны мы выбрали - ReAct, PlanandExecute, супервизор или рой.

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

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

Универсальный инструмент всегда хуже специализированного. Поэтому вместо списка «10 фреймворков, которые вы должны выучить» - разберём логику выбора: от низкоуровневого контроля до высокоуровневого прототипирования.