Зачем эталонные схемы
Перед реальной задачей соблазн — сразу собрать сложную сеть агентов, которые «сами разберутся». Это почти всегда ошибка: больше агентов = больше точек отказа, латентности, стоимости и непредсказуемости (помнишь урок «когда НЕ нужны мультиагенты»). Reference flows дают противоядие — минимальную структуру под тип задачи.
Ключевое различие, с которого всё начинается:
Шаги и переходы заданы кодом заранее. LLM работает внутри фиксированной структуры. Предсказуемо, дёшево, легко отлаживать. Большинство задач — сюда.
LLM сама решает, какие шаги и инструменты выбрать, сколько итераций. Гибко, но дороже и непредсказуемее. Только когда путь заранее неизвестен.
Начинай с самого простого, что решает задачу. Часто это вообще один LLM-вызов с хорошим промптом и парой инструментов — без всякой мультиагентности. Усложняй, только когда простое измеримо не справляется. Reference flows — это лестница сложности, поднимайся по ней по одной ступени.
Пять базовых flow
Вот карта эталонных схем — от простейшей к самой гибкой. Каждую ты уже частично видел в разделах про паттерны; здесь они собраны как готовый каталог выбора.
Коротко о каждом:
① Prompt chaining — цепочка
Задача разбита на фиксированную последовательность шагов, выход одного — вход следующего. Это Pipeline из раздела координации. Когда: задача чётко раскладывается на понятные подзадачи (черновик → редактура → перевод). Можно ставить между шагами «gate»-проверки.
② Routing — маршрутизация
Классификатор определяет тип входа и направляет его специализированному обработчику. Когда: категории задач различаются и для каждой лучше свой промпт/агент/модель (простые запросы → дешёвая модель, сложные → мощная). Опирается на Skills-роутинг из прошлого урока.
③ Parallelization — параллелизм
Задача бьётся на независимые части, выполняемые одновременно, потом результаты собираются. Это параллельное выполнение и Debate (голосование). Когда: подзадачи независимы (обработать 10 документов) или нужно несколько мнений на агрегацию.
④ Orchestrator–workers — оркестратор
Центральный агент динамически декомпозирует задачу и раздаёт подзадачи воркерам. Это Supervisor. Отличие от parallelization: число и характер подзадач не известны заранее — их определяет LLM в рантайме. Когда: декомпозиция зависит от входа (сложный research, где заранее не знаешь, сколько направлений копать).
⑤ Evaluator–optimizer — генератор+критик
Один агент генерирует, другой оценивает и возвращает на доработку — цикл до прохождения критериев. Это проверка и критика / Reflection. Когда: есть чёткие критерии качества и итерация измеримо улучшает результат (перевод с уточнениями, код с прогоном тестов).
Как выбрать flow
Не гадай — иди по вопросам от простого к сложному:
| Вопрос о задаче | Reference flow |
|---|---|
| Решается одним хорошим промптом + пара tools? | Никакой — просто один LLM-вызов |
| Чёткая фиксированная последовательность шагов? | ① Prompt chaining |
| Разные категории входа → разные обработчики? | ② Routing |
| Независимые подзадачи / нужно много мнений? | ③ Parallelization |
| Декомпозиция зависит от входа, заранее неизвестна? | ④ Orchestrator–workers |
| Есть критерии качества, помогает итерация? | ⑤ Evaluator–optimizer |
| Путь полностью открыт, нужна автономия? | Автономный агент (дороже, осторожно) |
Prompt chaining, routing, parallelization, orchestrator–workers, evaluator–optimizer — это workflow: структура задана кодом. Их проще отлаживать, дешевле гонять и легче тестировать, чем полностью автономного агента. Автономию бери последней, когда ни одна структурированная схема не подходит.
Комбинирование flow
Reference flows — не взаимоисключающие: реальные системы вкладывают их друг в друга. Один узел цепочки может внутри быть параллелизацией; воркер оркестратора — сам цепочкой с evaluator–optimizer на выходе.
Пример: исследовательский пайплайн (проект модуля)
routing → классифицировать запрос (простой / глубокий research)
└─ orchestrator–workers → разбить тему на N направлений
└─ parallelization → искать по направлениям одновременно
└─ prompt chaining → на каждом: поиск → выжимка → факт-чек
└─ evaluator–optimizer → критик проверяет отчёт → доработка
└─ prompt chaining → финал: свести → отредактировать → оформить
Именно так рождаются сложные, но управляемые системы: не «рой агентов, которые сами разберутся», а вложенные предсказуемые схемы, каждая из которых по отдельности проста и тестируема. Протоколы (A2A, MCP) при этом — «провода» между узлами: MCP вниз к инструментам/подчинённым, A2A вбок к автономным сервисам.
Reference flows связывают всё: зачем мультиагенты (специализация, параллелизм, критика) → чем строить (AutoGen, CrewAI, LangGraph) → как координировать (Supervisor, Pipeline, Swarm, Debate) → как связывать по сети (A2A, MCP, Skills). Flow — это рецепты, где все ингредиенты раздела собраны в проверенные блюда.
Типичные ошибки
Начинать с «умного роя, который сам разберётся» — путь к недебажимой, дорогой системе. Сначала попробуй простейший workflow; автономию добавляй, только когда структура измеримо не тянет.
Многие задачи закрываются одним LLM-вызовом с хорошим промптом и парой tools. Reference flow — не обязательство усложнять, а выбор минимально достаточного.
Цикл «генерируй–критикуй» полезен, только если оценщик судит по чётким критериям. Без них — бесконечная болтовня и трата токенов без сходимости к лучшему.
Роутер встретит вход, не подходящий ни под одну категорию. Всегда предусматривай fallback-обработчик, иначе задача «проваливается в никуда».
Шпаргалка
ПРАВИЛО №1: начинай с самого простого. Часто = 1 LLM-вызов + tools (без агентов)
усложняй по одной ступени, только когда простое измеримо не тянет
WORKFLOW (структура задана кодом, предсказуемо) vs AGENT (LLM сама рулит, дороже)
бери workflow по умолчанию; автономию — последней
5 БАЗОВЫХ FLOW:
① prompt chaining — фикс. цепочка шагов (= Pipeline) → чёткая последовательность
② routing — классиф. → нужный обработчик (= Skills) → разные категории входа
③ parallelization — параллельно + агрегация (= Debate/parallel)→ независимые части/мнения
④ orchestrator-workers— динам. декомпозиция (= Supervisor) → подзадачи неизвестны заранее
⑤ evaluator-optimizer — генератор+критик в цикле (= Reflection) → есть критерии, итерация помогает
ВЫБОР: 1 промпт? → без flow · последовательность? → ① · категории? → ② ·
независимо? → ③ · декомпозиция от входа? → ④ · критерии+итерация? → ⑤ ·
путь открыт? → автономный агент (осторожно)
КОМБИНИРОВАНИЕ: flow вкладываются друг в друга (узел = под-flow)
протоколы = «провода»: MCP вниз (инструменты/подчинённые), A2A вбок (сервисы)
ГРАБЛИ: сразу автономный агент · мультиагенты вместо 1 вызова ·
evaluator без критериев · routing без fallback
Практическое задание
Задание: подбери flow под задачи
- Для каждой задачи выбери reference flow и обоснуй: (а) «перевести документ: черновик → выверить термины → финал»; (б) «сортировать входящие тикеты по отделам»; (в) «прогнать 50 отзывов через анализ тональности»; (г) «написать эссе и итеративно улучшать по рубрике»; (д) «глубокий research по теме, направления заранее неизвестны».
- Найди задачу, которая на деле не требует мультиагентов — решается одним LLM-вызовом. Как отличить её от той, что требует?
- Спроектируй вложенную композицию для «сгенерировать аналитический отчёт по компании»: какие flow вложишь друг в друга и почему?
- Для схемы с routing допиши fallback-ветку: что делает система с входом, не попавшим ни в одну категорию?
- Для evaluator–optimizer из задачи (г) сформулируй 3 конкретных критерия, по которым оценщик решает «готово / доработать».
- Со звёздочкой: собери один из flow в LangGraph (модуль 03) — например, evaluator–optimizer с условным ребром «прошло/не прошло» — и прогони на реальной задаче.
Что дальше
Раздел «Протоколы взаимодействия» закрыт, а с ним — вся теория модуля 05. Осталось собрать всё руками: проект модуля — автоматический исследовательский пайплайн, где reference flows, протоколы и координация складываются в работающую систему.