Всем привет! Продолжаю делиться опытом построения ИИ‑агентов. За последние полгода собрал несколько кейсов на мой взгляд интерсеных чтобы рассказать о них.
Но каждый раз натыкался на один вопрос: а мне здесь вообще агент нужен, или хватит обычного воркфлоу? Слово «агент» за последний год прилепили ко всему подряд от Telegram‑ботов до Excel‑плагинов. А разница между пайплайном и настоящим агентом огромная. И по возможностям, и по стоимости, и по головной боли при отладке.
Сегодня разберём архитектуры ИИ‑агентов от самой простой до самой сложной. По каждой объясню, как устроена внутри, когда какую применять, как агенты общаются между собой, что с памятью. Постараюсь раписать все просто, так как я сам это вижу.
Это первая часть из двух:
Часть 1 (эта) разберем архитектуры ИИ‑агентов
Часть 2 построим Travel Agent на базе архитектуры deep agent
Workflow vs Agent
Прежде чем разбирать конкретные архитектуры, зафиксируем главное: есть два принципиально разных подхода:
Workflow — это конвейер. Мы сами прописываем: сначала сделай это, потом это, потом это. LLM тут исполнитель. Она делает свой кусок работы (классифицирует текст, генерирует ответ, парсит данные), но куда идти дальше решает наш код или флоу. Порядок шагов зафиксирован, как на кком‑нибудь производстве.
Простой пример: пришла заявка, LLM вытаскивает из неё данные, код проверяет, всё ли на месте дальше в LLM и та уже формирует ответ. Каждый шаг заранее определён нами. LLM ничего не выбирает просто делает то, что ей сказали на каждом шаге.
Agent тут всё наоборот. Мы даём модели цель («забронируй мне отель в Барселоне на май») и набор инструментов (поиск, бронирование, браузер). А дальше модель сама решает, какой инструмент вызвать, в каком порядке, сколько раз, и когда остановиться. Мы не знаем заранее, сколько шагов будет: три или тридцать.
Разница в том, кто контролирует поток выполнения. В workflow наши правила, и система которую мы построили строго последовательноназовем их бизнес правилами. В агенте контролирует и решает LLM модель.
Это не «лучше или хуже». Workflow предсказуемее, дешевле, проще в отладке. Агент гибче, но дороже и капризнее. Для большинства задач хватает workflow, а агент нужен, когда задачу нельзя разложить на шаги заранее.
Разберём давайте оба типа: сначала workflow‑архитектуры, потом агентские.
Workflow‑архитектуры
Prompt Chaining (цепочка промптов) — это конвейер с контролем качества
Смысл вот в чём. Когда у нас сложная задача, мы не пытаемся решить её одним запросом к LLM. Вместо этого мы разбиваем задачу на несколько простых шагов и вызываем модель несколько раз подряд. Результат первого вызова передаём во второй, результат второго в третий. И так далее, по цепочке.
Почему не одним вызовом? Потому что модель, когда пытается сделать всё сразу, делает хуже. А когда каждый шаг простой и конкретный — каждый отдельный результат получается точнее.
Но есть проблема: если первый шаг вернул ерунду, то второй шаг получит эту ерунду на вход и тоже выдаст ерунду и третий тоже. Вся цепочка поедет. Поэтому между шагами ставят gate это шлюз, проверка.
Gate — это обычный код, не LLM. Он смотрит на результат предыдущего шага и проверяет: JSON валидный? Все нужные поля заполнены? Ответ не пустой? Если проверка не прошла, шаг перезапускается с другим промптом или вся цепочка останавливается.
Если убрать gate, получится просто pipeline данные текут по цепочке без проверок. Добавляем gate между шагами получается Prompt Chaining.
Когда применять? Если ваша задача линейна и разбивается на чёткие шаги.
Например: Генерация отчётов, обработка документов, парсинг данных.
Routing (маршрутизация)
Routing это распределение запосов по маршрутам. Как сортировочный центр на почте: посылка приходит, сканер считывает адрес, конвейер отправляет посылку в нужный отсек. Никто не разбирает посылку — просто определяет, куда она должна ехать.
Здесь то же самое. Запрос от пользователя приходит, и первым делом LLM (или обычный код) определяет: о чём этот запрос? Это вопрос про оплату? Техническая проблема? Общий вопрос? В зависимости от ответа запрос уходит к нужному обработчику. Каждый обработчик это LLM модель со своим промптом, инструментами и знаниями.
Может показаться, что это похоже на агента ведь LLM принимает решение. Но нет. В Routing модель принимает одно решение — классифицирует запрос. И всё. Дальше работает код: берёт результат классификации и направляет запрос куда надо. Модель не выбирает инструменты, не работает в цикле, не решает «что дальше». Одно решение, один раз это workflow.
Зачем вообще маршрутизировать? Потому что один LLM не может одинаково хорошо разбираться во всём. Обработчик оплаты знает тарифы, правила возврата и имеет доступ к платёжной системе. Обработчик техподдержки знает, как читать логи. Если все запросы кидать в одну модель с одним промптом качество будет средним по всем темам. А если маршрутизировать каждый запрос попадает к «специалисту».
Важный момент: обработчиком может быть что угодно один LLM‑вызов, цепочка Prompt Chaining, или полноценный ReAct‑агент. Зависит от сложности задач в этой категории.
Когда применять? Запросы чётко делятся на категории: саппорт (оплата, техника, общие вопросы), модерация контента (спам, нормально, нужна ручная проверка), мультиязычные системы (каждый язык обрабатывает свой специализированный LLM).
Parallelization — параллельная обработка
Parallelization — распараллеливание. Если все 2 предыдщуих workflow были последовательными: шаг за шагом, о этот тип архитектуры помогает обрабатывать парралельно запросы.
Есть два принципиально разных способа распараллеливания и они решают совершенно разные задачи.
Sectioning разделение на секции. Мы берём задачу, разбиваем на разные независимые куски и раздаём разным LLM. Каждый делает своё. Результаты в конце собирает агрегатор: код или LLM, который объединяет всё в один ответ
Пример: конкурентный анализ. Нам нужны данные о ценах, функциях продукта и отзывах клиентов. Это три независимых задачи одна не зависит от другой. Запускаем три LLM параллельно:
Первый парсит цены
Второй анализирует функции Третий собирает отзывы
Второй анализирует функции
Работают одновременно, не ждут друг друга, что заняло бы 30 секунд последовательно, и за 10 секунд параллельно. и в конце просто агрегатор собирает три набора данных в единый отчёт.
Voting решение задач путем голосования. Тут наоборот: несколько LLM решают одну и ту же задачу независимо друг от друга. Потом результаты сравниваются, побеждает большинство.
Зачем? Одна модель может ошибиться. Две маловероятно одинаково. Три ещё надёжнее. Короче, когда вы скрамливаете сырые данные очеты, другие цифры, то лучше пользвоатьс ятаким типом архитектуры, надежность растет.
Когда применять?
Sectioning если задача естественно разбивается на независимые части. Исследования, сбор данных из разных источников, параллельная генерация контента.
Voting если нужна повышенная надёжность решения. Медицина, юридика, безопасность, модерация.
Важный момент: в обоих вариантах подзадачи фиксированы нами заранее. Мы сами решаем, на что разбить (Sectioning), или сколько голосов нужно (Voting). Модель тут не решает ничего мы всё определили. Если количество подзадач зависит от данных (сегодня нужно два, завтра пять) — это уже не workflow, а агентская архитектура. Про них поговорим дальше.
Evaluator‑Optimizer генерация с итеративной проверкой
Это последняя workflow‑архитектура, и она отличается от всех предыдущих одной важной вещью: здесь есть цикл. В Prompt Chaining данные шли строго вперёд от первого шага к последнему, без возвратов. В Routing запрос уходил в один обработчик и всё. А тут результат может вернуться назад на доработку. Несколько раз.
Но это всё ещё workflow, а не агент. Почему? Потому что цикл контролируется нашим кодом. Мы заранее определяем: кто генерирует, кто оценивает, по каким критериям, сколько максимум итераций. Модель не решает, что делать дальше она либо генерирует, либо оценивает и роли фиксированы.
Теперь про название. Evaluator — оценщик, тот кто проверяет результат. Optimizer — тот кто улучшает, оптимизирует. На практике в этой архитектуре два LLM (или один и тот же LLM с разными промптами) работают в паре:
Generator (генератор) создаёт результат. Пишет текст, код, отчёт — что угодно
Evaluator (оценщик) смотрит на результат и оценивает: хорошо или нет. Если нет формирует конкретный фидбэк, что именно не так и отдает генератору. Генератор получает фидбэк, переделывает. Оценщик снова проверяет. И так по кругу, пока качество не станет достаточным или не кончится лимит итераций.
Зачем это вообще нужно? Затем что LLM с первого раза редко выдаёт идеальный результат. Но если попросить другую модель (или ту же модель с другим промптом) посмотреть критически она найдёт ошибки, которые первая пропустила. Свежий взгляд со стороны работает и для людей, и для моделей.
Память
Generator видит всё: исходный запрос, все свои предыдущие попытки и весь фидбэк от Evaluator. Контекст растёт с каждой итерацией после 4–5 кругов контекстное окно раздувается настолько, что модель начинает путаться в своих же версиях. Это ещё одна причина, почему больше 2–3 итераций обычно не имеет смысла.
Когда применять? Когда качество критичнее скорости и когда можно чётко сформулировать критерии оценки: что значит «хороший код», «хороший текст», «хороший отчёт». Без чётких критериев Evaluator не сможет дать полезный фидбэк. Хорошо подходит для генерации кода, маркетинговых текстов, юридических документов, аналитических отчётов.
Когда хватает workflow
Подавляющее большинство продакшн‑задач решается workflow‑архитектурами. Если задача:
Предсказуема — набор сценариев конечный
Декомпозируема — можно разбить на чёткие шаги
Проверяема — после каждого шага можно оценить результат
В этих кейсах workflow будет надёжнее и дешевле агента. Агент нужен, когда количество шагов неизвестно заранее, модель должна сама выбирать инструменты и адаптироваться по ходу выполнения. Ну поехали разбираться агентские арзитектуры
Агентские архитектуры
Основной и отличительной часть агентких архитектур или ИИ‑агентов является принцип принятия решения самой моделью. В общем тут рулит модель, мы ей даем только цели и задачами а так же инструменты для выполнения, но модель сама решает когда кого вызвать. И Архитектуры ИИ‑агентов бывают разные давайте их разберем
ReAct — Reasoning + Acting
ReAct (Reasoning + Acting = рассуждение + действие) это самая базовая агентская архитектура и фундамент всех современных ИИ-агентов. Когда ChatGPT «ищет в интернете» или Claude Code «читает файл и правит код» под капотом крутится именно этот паттерн. Чтобы понять, как он работает, разберём три компонента, из которых состоит любой агент.
Три компонента агента: LLM, инструменты, память
LLM мозг агента. Языковая модель (Claude, GPT, Gemini, любая другая ) — это центральный элемент, который принимает все решения. Она читает задачу, рассуждает, выбирает следующее действие, интерпретирует результаты. LLM сама ничего не «делает» во внешнем мире не ходит на сайты, не читает файлы, не отправляет письма. Она только генерирует текст: рассуждения и команды вида «вызови такой-то инструмент с такими-то параметрами». Всю реальную работу выполняет система вокруг неё.
Инструменты (tools) руки агента. Инструмент – это любое действие, которое агент может попросить систему выполнить: поиск в интернете, запрос к API, чтение файла, запись в базу данных, отправка сообщения. У каждого инструмента есть текстовое описание: что он делает и какие данные ему нужны. Все описания загружаются в контекст модели, и она каждый раз выбирает подходящий.
Два момента, которые важны на практике.
Во-первых, описания инструментов занимают место в контексте 15 инструментов могут «съесть» тысячи токенов.
Во-вторых, качество описаний решает всё: модель выбирает инструмент по тексту описания, и если описание невнятное она выберет не тот инструмент или вызовет его с неправильными параметрами. Простое правило: если вы, прочитав описание, не понимаете, когда его использовать модель тоже не разберётся.Память (контекстное окно). Вся память ReAct-агента это одно большое пространство (контекстное окно), куда складывается абсолютно всё: системные инструкции, описания инструментов, сообщение пользователя, все рассуждения агента, все вызовы инструментов и все их результаты. У Claude это окно вмещает 200K токенов, у GPT-5 до 2M. А маленькие LLM модели начинаются от 32к токенов.
Проблема в том, что окно заполняется быстро. Каждая итерация цикла добавляет сотни токенов% рассуждение, вызов инструмента и его результат, который может оказаться целой веб страницей или длинным JSON ответом от API. После 20–30 итераций окно подходит к пределу, и модель начинает терять информацию из начала разговора это фундаментальное ограничение, которое решается только в более сложных архитектурах вроде Deep Agent с его четырьмя типами памяти, но об этом дальше.
Как ReAct использует эти три компонента ?
ReAct берёт LLM, инструменты и память и соединяет их в цикл из трёх фаз:
Think – LLM рассуждает: «Что мне нужно? Какой инструмент вызвать?»
Act – LLM выбирает инструмент, инструменты его выполняют
Observe – результат возвращается в контекст, LLM смотрит и решает: хватит или нужен ещё шаг.
Цикл повторяется, пока модель сама не решит, что у неё достаточно данных для ответа. Мы не прописываем количество шагов в коде модель определяет это динамически. В этом вся разница с workflow.
Смотрите схему:
Orchestrator-Workers — главный агент со своими субагентами.
Orchestrator-Workers работает так: один «начальник» (оркестратор) разбивает задачу на части и раздаёт «исполнителям» (субагентам). Оркестратор сам решает, на сколько частей разбить задачу и что каждому поручить. Для одной задачи может быть достаточно двух субагентов, другая – пять. Это определяется динамически, а не прописано в коде.
Смотрите схему:
Чем отличается от Parallelization? В Parallelization (workflow) мы фиксируем исполнителей (субагентов) в коде: всегда три LLM, всегда одни и те же. В Orchestrator-Workers субагенты создаются динамически — оркестратор сам определяет количество worker'ов, глядя на конкретную задачу.
Пример: Claude Code. Вы говорите: «Сделай веб-приложение для трекинга привычек с авторизацией и дашбордом».
Оркестратор берет задачу и декомпозирует примерно так:
Субагент 1 (фронтенд): React-компоненты, UI, стили
Субагент 2 (бэкенд): API, база данных, авторизация
Субагент 3 (тесты): юнит-тесты и интеграционные
Субагенты 1 и 2 работают параллельно каждый в своём контексте, со своими инструментами. Субагенты 3 ждёт, пока оба закончат. Оркестратор следит за прогрессом: если API-формат у бэкенда не совпадает с тем, что ожидает фронтенд замечает и корректирует.
Каждый Субагенты по сути отдельный ReAct-агент. Оркестратор тоже ReAct-агент но его задача управлять.
Мы разобрали Orchestrator-Workers: когда один начальник раздаёт задачи исполнителям. Но возникает вопрос: а как именно оркестратор общается с субагентами? Как выбирает, какого агента создать? И что если агенты уже существуют как с ними связаться?
В мультиагентных системах есть три паттерна общения, и они решают разные задачи:
Централизованное управление (Orchestrator-Workers) — один начальник, все решения через него. Оркестратор сам создаёт субагентов, сам раздаёт задачи, сам собирает результаты. Субагенты общаются только с оркестратором друг о друге они не знают. Это то, что мы разобрали выше: оркестратор видит задачу, решает «тут нужны три субагента», создаёт их и координирует. Тут важно они все части одной системы они общаются через передачу контекста проше говоря через код.
Через общие файлы — например субагент 1 записал что-то в NOTES.md: Субагент 2 прочитал файл и просто черпает оттуда знанния. Никакого HTTP, MCP между ними нет это вызовы функций внутри одного процесса.
Через задачи с зависимостями — оркестратор создаёт задачи со статусами и зависимостями: «Task 3 заблокирована, пока не завершены Task 1 и Task 2». Субагенты берут следующую доступную задачу из очереди. Похожая схема с работой через общие файлы, по сути это просто общая память для всех.
Выводы?
Мы прошли путь от простого к сложному. Вот как это всё складывается:
Простой пайплайн (Prompt Chaining) самое базовое. Цепочка вызовов LLM друг за другом с проверками между ними. Данные входят, проходят через шаги, выходит результат. Никакой магии, никаких решений модели просто конвейер. Подходит для 80% задач.
Умный пайплайн (Routing, Parallelization, Evaluator‑Optimizer) — тот же пайплайн, но хитрее. Routing раскидывает запросы по специалистам. Parallelization запускает несколько LLM одновременно. Evaluator‑Optimizer гоняет результат по кругу пока не станет хорошо. Всё ещё workflow — всё ещё рулим мы.
Одиночный агент (ReAct) — тут уже модель рулит сама. У неё есть инструменты и контекстное окно, она сама решает что вызвать и когда остановиться. Цикл Think‑Act‑Observe. Один агент, одно контекстное окно, одна задача.
Мультиагентная система (Orchestrator‑Workers) — когда одного агента мало. Главный агент разбивает задачу на части и раздаёт субагентам. Каждый субагент — отдельный ReAct со своим контекстом. Работают параллельно, результаты собирает оркестратор.
Правило простое: начинайте с пайплайна. Не хватает берите ReAct. Задача большая и нужна параллельная работа Orchestrator‑Workers. Каждый следующий уровень: дороже, сложнее, больше мест для ошибок. Не усложняйте пока не припрёт.
––––
Во второй части построим Travel Agent на архитектуре Deep Agent. Разберём как все эти штуки складываются в одну систему: план, выполнение, рефлексия, память, субагенты.
Все материалы выложу в Telegram-канал. Спасибо, что прочитали.
