Когда нужен агент, а когда хватит пайплайна

Спектр архитектур: от простого к сложному

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

100%

колёсико — масштаб · зажать и тянуть — перемещение

Каждый следующий уровень не «лучше» предыдущего — он дороже и сложнее. Используй его только если более простой уровень принципиально не справляется с задачей.

Четыре уровня в деталях

Рассмотрим каждый уровень: что он умеет, чего не умеет, и когда это правильный выбор.

Прямой вызов

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

~100–500 токенов
< 1 сек

Цепочка

Несколько последовательных промптов, выход одного — вход следующего. Порядок шагов жёстко задан в коде. Нет ветвлений на основе результатов. Пример: prompt1 = «выдели тезисы», prompt2 = «переведи тезисы», prompt3 = «оцени тон». Это всё ещё детерминировано — LLM не решает «что делать дальше».

~500–2000 токенов
1–3 сек

Пайплайн

LLM-шаги перемежаются с детерминированным кодом: API-вызовами, записью в БД, валидацией. Маршрут исполнения всё ещё известен заранее. LLM участвует в отдельных шагах, но не принимает решений о следующем шаге. Хорошо подходит для ETL, обработки документов, обогащения данных. Легко тестировать и мониторить.

~1000–5000 токенов
2–10 сек

Агент
              LLM сама решает, какие инструменты вызвать и в каком порядке.
              Порядок шагов неизвестен заранее — он определяется задачей и промежуточными результатами. Агент может «передумать»: если поиск вернул неожиданные данные, он сделает уточняющий запрос. Нужен когда пайплайн не покрывает все ветки решения или их слишком много.
            
~5k–50k токенов
10–120 сек

Мульти-агент

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

~50k–500k токенов
минуты

Критерии выбора: пять вопросов

Вместо интуиции — конкретные вопросы о задаче. Ответы на них однозначно указывают на уровень архитектуры.

Известны ли шаги решения заранее?

→ Да, всегда одинаковые — прямой вызов или цепочка

→ Да, но есть код между шагами — пайплайн

→ Нет, зависят от результатов — агент

Нужны ли внешние данные во время выполнения?

→ Нет, всё в промпте — прямой вызов

→ Да, конкретные заданные источники — пайплайн

→ Да, и неизвестно какие нужны — агент

Насколько критична предсказуемость?

→ Критична (финансы, медицина) — пайплайн с явной логикой

→ Важна, но есть допуск — агент с ограниченным набором инструментов

→ Не критична (творчество, research) — агент с широким доступом

Может ли промежуточный результат изменить план?

→ Нет — пайплайн. Ветвление задай в коде явно.

→ Да, и веток слишком много — агент. LLM обработает все случаи.

Укладывается ли задача в одно контекстное окно?

→ Да — один агент справится

→ Нет, задача огромная — мульти-агент с декомпозицией

Нужна ли параллельная специализированная работа?

→ Нет — один агент с набором инструментов

→ Да (например: researcher + coder + reviewer) — мульти-агент

Реальные задачи: какую архитектуру выбрать

Теория — это хорошо, но решения принимаются на конкретных задачах. Разберём типичные сценарии:

Задача	Почему именно это	Архитектура
Перевести 100 отзывов с английского на русский	Задача атомарна, никаких внешних данных не нужно. Запускай пакетом.	прямой вызов ×100
Определить тональность отзыва, извлечь ключевые темы, записать в БД	Шаги фиксированы: LLM → парсинг → SQL. Порядок не меняется.	пайплайн
Ответить на вопрос по документу (RAG)	Retrieve → Generate. Два фиксированных шага, возможно с reranking.	пайплайн
Написать статью: придумать тему → найти источники → написать → проверить	Шаги известны, но источники непредсказуемы — нужны разные инструменты поиска.	агент
Отвечать на вопросы пользователя о заказах (e-commerce support)	Неизвестно, нужно ли смотреть заказ, статус доставки, историю — LLM решает сам.	агент
Сгенерировать и проверить код, запустить тесты, исправить ошибки	Цикл: write → test → fix → repeat. Количество итераций неизвестно.	агент
Мониторинг новостей: 50 источников, ежечасно, суммаризация по темам	Задачи независимы и однотипны — параллельный пайплайн, не агент.	пайплайн (параллельный)
Разработать фичу: requirements → design → code → tests → review	Разные роли, параллельная работа, контекст не влезет в одно окно.	мульти-агент

Реальная стоимость агента

Агент кажется «бесплатным» пока не смотришь на счёт. Каждая итерация цикла — это запрос к LLM, и размер контекста растёт с каждым шагом. Вот почему агент на 10 итерациях обходится в разы дороже одного вызова:

Прямой вызов

~500 tok

Цепочка ×3

~2k tok

Пайплайн

~4k tok

Агент ×5 итер.

~20k tok

Агент ×15 итер.

~80k tok

Почему контекст растёт так быстро? Каждая итерация добавляет в messages ответ ассистента плюс результаты инструментов. К 10-й итерации в контексте может быть полная история — 30–50 сообщений, и каждый следующий вызов LLM платит за всё это заново. Агент на 15 итерациях с большим контекстом может стоить как 100 прямых вызовов.

⚠️ Установи лимиты до деплоя

Без max_iterations и max_tokens один зациклившийся агент может сгенерировать счёт на сотни долларов. Установи лимиты, добавь мониторинг стоимости на задачу (через response.usage), и предупреди пользователя о сложных задачах заранее.

Антипаттерны: типичные ошибки выбора

❌ Агент вместо пайплайна

Задача: парсить 10k документов, сохранять в БД

Решение: «запустим агента для каждого»

Результат: непредсказуемый маршрут,
в 100× дороже, трудно дебажить

Шаги фиксированы → нужен пайплайн

✅ Пайплайн для фиксированных шагов

Задача: парсить 10k документов, сохранять в БД

Решение: extract() → validate() → store()

Результат: дёшево, детерминировано,
легко мониторить и тестировать

Каждый шаг — отдельная функция с тестом

❌ Пайплайн вместо агента

Задача: отвечать на вопросы клиентов о заказах

Решение: «захардкодим все if-else сценарии»

Результат: 200 if-else, не покрывает
90% реальных запросов, постоянные правки

✅ Агент для непредсказуемых сценариев

Задача: отвечать на вопросы клиентов о заказах

Решение: агент с инструментами get_order(), get_tracking(), issue_refund()

LLM сама выбирает нужный инструмент,
покрывает любые комбинации вопросов

❌ Мульти-агент для простой задачи

Задача: написать короткий пресс-релиз

Решение: orchestrator → writer → reviewer → editor

4 агента, 4× стоимость, сложная
отладка — один промпт справится лучше

✅ Мульти-агент для реально сложных задач

Задача: исследовать рынок и написать 50-страничный отчёт

Решение: researcher + analyst + writer работают параллельно

Задача явно не влезает в одно окно,
параллельность даёт реальный выигрыш

Шпаргалка

Дерево выбора архитектуры

Задача решается одним промптом без внешних данных?
  └─ ДА  → Прямой LLM-вызов

Шаги фиксированы, порядок известен заранее?
  ├─ ДА, только промпты  → Цепочка промптов
  └─ ДА, есть код/API    → Детерминированный пайплайн

Шаги зависят от промежуточных результатов?
  └─ ДА  → Задача вмещается в одно контекстное окно?
              ├─ ДА  → Агент
              └─ НЕТ → Мульти-агент

Правило большого пальца

Начинай с наименьшего уровня, который решает задачу.
Усложняй только когда упёрся в ограничение текущего уровня:
  пайплайн не гибкий? → агент
  контекст переполняется? → мульти-агент
  агент дорого стоит? → декомпозируй и вернись к пайплайну

Стоп-сигналы: не используй агента если:

  • Набор шагов всегда одинаковый — это пайплайн
  • Нужна 100% воспроизводимость — детерминированный код
  • Задача атомарна — один промпт быстрее и дешевле
  • Нет бюджета на эксперименты — агент непредсказуем

Практическое задание

Классификация задач. Возьми пять рабочих задач, с которыми ты сталкивался, и определи для каждой минимально подходящую архитектуру. Обоснуй свой выбор через критерии из этого урока: фиксированы ли шаги, нужны ли внешние данные, насколько важна предсказуемость.
Рефакторинг пайплайна → агент. Возьми задачу, которую ты бы решил пайплайном с 5+ ветками if-else: например, «ответить на вопрос пользователя, но если не знаем — искать в сети, если нашли — суммаризировать, если не нашли — попросить уточнить». Реализуй оба варианта (пайплайн и агент) и сравни: сколько строк кода, покрывает ли каждый 100% случаев?
Замери стоимость. Возьми агента из предыдущего урока и добавь подсчёт токенов через response.usage.input_tokens + response.usage.output_tokens. Запусти 5 разных задач и запиши стоимость каждой в токенах и итерациях. Какие задачи «дорогие», какие — нет?

← Предыдущий урок

Реактивный цикл

perceive → think → act → observe

→ Следующий урок

Как LLM вызывает функции

Tool Calling в деталях