Архитектура ИИ агент паттерн LLM автоматизация выбирается от задачи: для линейного процесса хватит цепочки, для неопределённого — одного агента с инструментами, а для сложного проекта нужны роутер, оркестратор или команда специализированных агентов.

6архитектурных паттернов
3вопроса перед выбором

Схема выбора архитектуры ИИ-агента под задачу автоматизации

Почему архитектура важнее красивого промпта

ИИ-агент — это не просто чат с кнопкой «сделать». Он получает цель, выбирает действие, обращается к инструменту, смотрит на результат и может повторить цикл. Архитектура определяет, кто принимает решения и сколько свободы получает модель.

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

При выборе смотри на три вещи:

  1. Насколько задача предсказуема. Если шаги почти всегда одинаковые, фиксируй их кодом или цепочкой.
  2. Нужно ли выбирать исполнителя. Для разных типов запросов может понадобиться роутер.
  3. Нужна ли независимая проверка. В задачах с риском ошибки полезен отдельный оценщик.

В статье Towards Data Science эти идеи собраны в шесть архитектурных паттернов. Ниже я перевела их на язык реальных рабочих процессов.

1. Последовательная цепочка: шаг за шагом

Это самая понятная схема. Результат одного шага становится входом для следующего:

входные данные → анализ → черновик → проверка → готовый результат

Пример: из расшифровки встречи сделать пост.

  • первая модель выделяет факты и главную мысль;
  • вторая превращает их в структуру;
  • третья пишет текст;
  • четвёртая проверяет длину, тон и фактические ошибки.

Здесь не нужен автономный агент. Каждый шаг можно протестировать отдельно, а не гадать, почему финальный текст внезапно уехал в другую сторону.

Последовательная цепочка хорошо подходит для:

  • подготовки контента;
  • обработки документов;
  • классификации заявок;
  • подготовки отчётов;
  • преобразования данных из одного формата в другой.

Минус очевидный: если первый шаг ошибся, ошибка поедет дальше по конвейеру. Поэтому между этапами нужны проверки формата и обязательных полей.

Цепочка уже описывает процесс, но не решает вопрос качества на каждом шаге.

В канале «А.М. решает вопросы» Арина показывает рабочие схемы автоматизации и разборы таких ошибок:

зайти в канал и посмотреть примеры

2. Один агент с инструментами: цель, цикл, результат

В этой архитектуре LLM сама решает, какое действие выполнить дальше. У неё есть цель, набор инструментов и правила остановки.

Например, агент для поддержки может:

  1. прочитать сообщение клиента;
  2. найти заказ в CRM;
  3. проверить статус доставки;
  4. составить ответ;
  5. передать сложный случай человеку.

Это уже не линейный сценарий. Агент выбирает следующий шаг в зависимости от ситуации. Такой подход близок к тому, как работает Claude Code: агент получает задачу, обращается к файлам и инструментам, применяет изменения и может продолжать работу после отдельных действий. Конфигурационные инструкции для Claude Code обычно хранят в файле CLAUDE.md.

Подробнее о базовой сборке можно почитать в статье как собрать агента на Claude и в материале создание ИИ-агента.

Такой паттерн выбирай, когда:

  • заранее неизвестно, сколько шагов потребуется;
  • у агента есть несколько полезных инструментов;
  • решение зависит от результата предыдущего действия;
  • человек готов подтвердить опасные операции.

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

Один ИИ-агент выбирает инструменты и проверяет результат задачи

3. Роутер: сначала определить тип запроса

Роутер не решает задачу целиком. Он определяет, куда её отправить.

Простейшая схема:

сообщение клиента → классификация → нужный исполнитель

В интернет-магазине роутер может отправить:

  • вопрос о доставке в агента логистики;
  • запрос на возврат в сценарий поддержки;
  • жалобу в очередь сотруднику;
  • вопрос о товаре в агента, который ищет данные в каталоге.

Плюс роутера в том, что каждый исполнитель остаётся узким. Ему не нужно знать весь бизнес-процесс.

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

4. Параллельная схема: несколько веток одновременно

Иногда задачу можно разделить на независимые части и выполнить их параллельно.

Например, перед запуском продукта нужно:

  • собрать вопросы аудитории;
  • изучить конкурентов;
  • проверить прошлые результаты;
  • подготовить варианты оффера.

Четыре независимых исполнителя работают одновременно, а потом общий шаг собирает их выводы.

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

Для такой сборки заранее определи общий формат результата. Иначе один агент вернёт таблицу, второй — три абзаца, третий — философское эссе, и собирать это вручную будет веселее, чем хотелось.

5. Оркестратор и исполнители: сложная задача по ролям

Оркестратор получает большую цель, разбивает её на подзадачи, раздаёт их исполнителям и собирает общий результат.

Пример для аналитического отчёта:

  • оркестратор формулирует план;
  • исследователь ищет данные;
  • аналитик сравнивает показатели;
  • редактор собирает текст;
  • проверяющий ищет противоречия;
  • оркестратор решает, что отправить пользователю.

Это гибче обычной цепочки. Если данные неполные, оркестратор может добавить уточняющий шаг. Если проверяющий нашёл проблему, можно отправить конкретный фрагмент на доработку.

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

В разборе мультиагентных систем я бы особенно смотрела на места, где агенты передают друг другу непроверенные выводы. Там чаще всего и появляется эффект «все уверенно согласились с первой ошибкой».

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

6. Оценщик и исполнитель: результат через проверку

В этой схеме один агент создаёт результат, а второй оценивает его по правилам.

исполнитель → результат → оценщик → доработка или выпуск

Пример: агент пишет коммерческое письмо, а оценщик проверяет:

  • есть ли конкретное предложение;
  • не придуманы ли факты;
  • соблюдён ли тон бренда;
  • нет ли запрещённых обещаний;
  • помещается ли текст в заданный объём.

Паттерн подходит, когда качество можно описать критериями. Если критерии расплывчатые, оценщик начнёт придумывать собственные стандарты.

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

Какую архитектуру выбрать под свой проект

Вот короткая карта, с которой можно начать:

Твоя задача Подходящая архитектура Почему
Всегда одинаковые этапы Последовательная цепочка Легко тестировать и отлаживать
Непредсказуемое число действий Один агент с инструментами Модель выбирает следующий шаг
Разные типы входящих запросов Роутер Каждый запрос попадает к нужному исполнителю
Несвязанные исследования Параллельные ветки Работа идёт одновременно
Большая задача с ролями Оркестратор и исполнители Можно делегировать части процесса
Нужен контроль качества Исполнитель и оценщик Результат проходит отдельную проверку

Начинай с минимальной схемы и добавляй следующий уровень только после измерения проблемы. Не хватает качества — добавь оценщика. Не справляется один агент — раздели роли. Долго классифицирует запросы — поставь роутер.

А вот что не стоит делать сразу:

  • запускать много агентов без разных ролей;
  • давать всем полный доступ к базе и файловой системе;
  • передавать между агентами весь контекст целиком;
  • считать число агентов показателем зрелости системы;
  • оставлять процесс без лимита стоимости и итераций.

По данным материала The Decoder, разработчик Codex отдельно критиковал роевые схемы за расход токенов без гарантии прироста качества. Это не запрет на мультиагентные системы. Это напоминание: у каждого дополнительного участника должна быть конкретная функция.

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

Мини-план первого прототипа

  1. Опиши одну задачу, которую агент должен закрывать до конца.
  2. Зафиксируй вход, ожидаемый результат и критерий ошибки.
  3. Собери последовательную цепочку или одного агента с двумя-тремя инструментами.
  4. Добавь журнал действий: запрос, решение, инструмент, результат.
  5. Поставь лимит итераций и ручное подтверждение опасных действий.
  6. Прогони прототип на реальных примерах, а не на красивом тестовом кейсе.

Если задача повторяется и правила становятся стабильными, часть логики можно вынести из LLM в обычный код. Это обычно дешевле и предсказуемее. Агент нужен там, где приходится читать неструктурированный текст, выбирать из вариантов и работать с неполной информацией.

Шесть архитектур ИИ-агентов собраны в карту выбора для автоматизации

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

По материалам: гид Towards Data Science по шести архитектурным паттернам, документация Claude Code, разбор роевых схем агентов в The Decoder.

Читайте также

Ты уже понимаешь, какую схему тестировать первой, но дальше нужны живые примеры и разборы без теории ради теории.

В канале «А.М. решает вопросы» Арина показывает, как агенты собираются в рабочие процессы и где их приходится ограничивать:

подписаться и забрать практические разборы