Пять AI-агентов в одном пайплайне: как это собирают на практике

Одиночный агент, который «умеет всё», на практике проигрывает связке из нескольких узких. Это уже не гипотеза с форумов, а рабочий паттерн: вместо одной модели с раздутым системным промптом команды разбивают задачу на этапы и на каждый ставят отдельного агента¹ — со своим набором инструментов, своим контекстом и своей моделью. Ниже — как выглядит такой пайплайн из пяти агентов, чем оркестраторы вроде LangGraph, CrewAI и AutoGen отличаются друг от друга и во что это обходится по токенам.

Что значит «пять агентов в одном пайплайне»

Речь про обработку одного бизнес-запроса цепочкой специализированных агентов, где выход одного становится входом следующего. Типичный набор для задачи «принять входящий запрос клиента и подготовить ответ с данными» выглядит так:

1. Роутер — классифицирует запрос и решает, каким веткам его отдать. Обычно самая дешёвая модель, потому что задача узкая.
2. Ресёрчер — тянет данные: ходит в базу знаний через RAG², дёргает внутренние API, собирает контекст.
3. Аналитик — сверяет найденное с правилами, считает, проверяет непротиворечивость.
4. Райтер — превращает структурированный результат в текст для человека.
5. Критик (валидатор) — проверяет ответ на галлюцинации и соответствие политике, при провале возвращает задачу назад.

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

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

Как связывают агентов между собой

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

Линейная цепочка

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

Граф с ветвлением

Роутер направляет запрос в одну из веток в зависимости от типа. Часть агентов вообще не вызывается для конкретного запроса — экономия на токенах. Здесь и работают фреймворки с явным описанием состояния и переходов.

Иерархия с супервайзером

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

Чем отличаются фреймворки-оркестраторы

Собирать связку руками на голых вызовах API можно, но на пятом агенте вы неизбежно напишете свой велосипед для передачи состояния и ретраев. Поэтому чаще берут готовый оркестратор. Возможности и статус фреймворков меняются быстро — сверяйтесь с их документацией перед выбором.

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

Где реально теряются деньги и время

Мультиагентный пайплайн платит за качество разбиения задачи двумя ресурсами — токенами и задержкой.

• Токены множатся. Каждый агент получает свой системный промпт и часть контекста. Пять агентов на один запрос — это пять отдельных обращений к модели, а при цикле «критик завернул» число вызовов растёт.
• Латентность копится. Линейная цепочка складывает задержки всех шагов. Если каждый агент отвечает 2–4 секунды, финальный ответ приходит через 10–20 секунд — для чата это ощутимо.
• Ошибки накапливаются. Неточность ресёрчера тянется дальше по цепочке, и критик в конце ловит уже не первопричину, а следствие.
• Модели стоят по-разному. Ставить топовую модель на каждый узел — самый быстрый способ раздуть счёт. Роутеру и валидатору обычно хватает модели попроще.

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

Кому это пригодится, а кому нет

Пригодится, если:

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

Не пригодится, если:

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

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

¹ Агент — модель, которой дан не только текст, но и набор инструментов (поиск, вызов API, код) и цикл, в котором она сама решает, каким инструментом воспользоваться, пока не выполнит задачу.

² RAG (retrieval-augmented generation) — подход, при котором модель перед ответом подтягивает релевантные документы из внешней базы и отвечает, опираясь на них, а не только на то, что «запомнила» при обучении.