Главная мысль урока: сложные агентные системы собираются из пяти типовых «кирпичей» — паттернов оркестрации, описанных Anthropic и принятых всей индустрией. Зная их по именам, вы сможете читать архитектурные предложения разработчика как чертёж. И главное: мультиагентность — не «круче», а в ~15 раз дороже, и оправдана только для определённого класса задач.
Пять кирпичей
В уроке 1 мы разделили мир на workflow (маршрут задан) и агентов (маршрут выбирает модель). Канонический текст «Building Effective Agents» описывает пять паттернов — четыре первых это workflow разной хитрости, пятый добавляет агентность. Вся терминология индустрии 2025–2026 идёт отсюда.
1 · Цепочка (prompt chaining)
задача → [шаг 1] → [шаг 2] → [шаг 3] → результат
Выход одного вызова модели — вход следующего. Каждый шаг проще и надёжнее, чем «всё одним промптом», между шагами можно вставить проверки.
Пример из вашей практики: транскрибация эфира → конспект → черновик письма → проверка на «признаки ИИ».
2 · Маршрутизация (routing)
запрос → [классификатор] → ветка А / ветка Б / ветка В
Первый вызов определяет тип запроса и направляет его в специализированную ветку — каждая со своим промптом, инструментами и даже моделью (простые запросы — дешёвой модели, сложные — мощной).
Пример: входящие сообщения учеников — вопрос по оплате / по контенту курса / жалоба — три разных обработчика.
3 · Параллелизация (parallelization)
задача → [вызов А] + [вызов Б] + [вызов В] одновременно → свод
Независимые подзадачи выполняются одновременно — либо разные аспекты (один проверяет факты, другой стиль), либо «голосование» (три ответа на один вопрос → выбор лучшего).
Пример: пять ревьюеров одновременно ищут разные типы ошибок в коде — так работает ваш скилл bug-hunt.
Одна модель создаёт, другая оценивает по заданным критериям, первая дорабатывает — цикл, пока критик не примет работу. Работает там, где есть чёткие критерии качества.
Пример: письмо для рассылки → проверка по чеклисту (длина, тон, призыв к действию) → доработка → повторная проверка.
5 · Оркестратор с воркерами (orchestrator-workers)
Единственный по-настоящему агентный паттерн из пяти: ведущая модель сама решает, на какие подзадачи разбить работу и каких воркеров-субагентов запустить — заранее этого не знает никто. Каждый воркер работает в своём чистом контексте (урок 2!) и возвращает оркестратору сводку.
Пример: «исследуй тему X» → оркестратор запускает 4 поисковиков с разных углов → сводит их отчёты. Так устроен ваш скилл deep-research и продукт Research от Anthropic.
Великий спор 2025 года: а нужны ли вообще мультиагенты?
Летом 2025 индустрия публично поспорила — и этот спор стоит знать, потому что обе позиции верны.
За: Anthropic
Построили продакшн-систему Research на оркестраторе с параллельными субагентами
Мультиагентная версия обошла одиночного агента на 90% в их внутреннем бенчмарке исследовательских задач
Но честно: система ест ~15× больше токенов, чем обычный чат
Консенсус, к которому пришла индустрия (его сформулировал глава LangChain): оба правы — для разных задач.
Задачи на чтение (исследование, сбор информации, аудит) отлично параллелятся: воркеры не мешают друг другу, каждый просто читает свой угол. Задачи на письмо (код, документ, дизайн) параллелятся плохо: результаты воркеров конфликтуют, и склейка обходится дороже выигрыша. (LangChain, How and When to Build Multi-Agent Systems, июнь 2025)
🔬 Под капотом: откуда берутся 15×
Каждый субагент — это отдельный полный цикл из урока 1 со своим контекстным окном: ему заново выдают инструкции и описания инструментов, и он заново читает нужные данные. То, что в обычном чате лежало в окне один раз, здесь оплачивается столько раз, сколько агентов работает.
Плюс надстройка: оркестратор пишет задания, читает отчёты воркеров и сводит их вместе — это тоже токены. Так и набегает ~15× по замерам Anthropic: не «магический налог», а простая арифметика повторяющихся контекстов.
🧭 Правило выбора одной строкой
Читаем много → параллельные субагенты. Пишем одно → один агент с хорошим контекстом. И всегда: самый простой паттерн, который решает задачу. Цепочка лучше маршрутизации, маршрутизация лучше оркестратора — если результат тот же.
Зачем это вам как заказчику
Теперь вы читаете предложения разработчика: «сделаю пайплайн» = цепочка; «классифицируем запросы» = маршрутизация; «запустим субагентов» = оркестратор. Можете спросить: «почему именно этот паттерн, а не более простой?»
Если предлагают мультиагентную систему для создания чего-то одного (письма, документа, кода) — красный флаг: вспомните Cognition.
Если задача — перелопатить кучу источников, а предлагают одного агента — резонно спросить про параллельных воркеров: будет быстрее и качественнее.
Помните про цену: мультиагентность ≈ 15× токенов. Для регулярных задач это умножение счёта за API.
Проверьте себя
Повторение урока 4. База знаний — 30 страниц правил клуба, меняется раз в полгода, вопросы — каждый день. Что выбрать?
Верно! 30 страниц спокойно живут в окне — первый пункт дерева выбора. Любая инфраструктура поверх — лишняя.
Вернитесь к дереву из урока 4, пункт 1: база помещается в окно с запасом → длинный контекст. RAG и оркестраторы здесь — стрельба из пушки по воробьям.
Поток обращений в поддержку школы: вопросы об оплате, технические проблемы, вопросы по контенту. Какой паттерн напрашивается первым?
Именно! Типы запросов известны заранее → маршрутизация: каждая ветка со своим промптом и инструментами, простые ветки можно посадить на дешёвую модель.
Здесь типы запросов известны заранее и им нужны разные обработчики — это классическая маршрутизация. Оркестратор дороже без выгоды, а evaluator-optimizer — про итеративное улучшение, не про сортировку.
Чем оркестратор-с-воркерами отличается от параллелизации?
Точно! Это та же граница «workflow vs агент» из урока 1, применённая к параллельной работе: фиксированное разбиение против динамического планирования.
Скорость и вендоры ни при чём. Разница — кто разбивает задачу: код заранее (параллелизация) или модель на ходу (оркестратор). Это граница workflow/агент из урока 1.
Разработчик предлагает: «пять агентов будут одновременно писать пять разделов вашего нового лендинга, потом склеим». Что вы вспомните?
Верно! Лендинг — единое произведение: тон, логика, связки. Параллельные авторы с разными предпосылками дадут лоскутное одеяло. Один агент с хорошим планом — надёжнее (и в 15 раз дешевле).
Это ловушка «мультиагентность = круче». Лендинг — write-задача: единый тон и логика. Вспомните Cognition: параллельные агенты не видят решений друг друга. Здесь лучше один агент.
А вот задача: «проанализируй 40 записей звонков отдела продаж и найди типовые возражения». Здесь мультиагентность…
Именно! Чтение параллелится отлично: воркеры не конфликтуют, а 40 записей в одно окно и не влезут (урок 2). Это ровно профиль задачи, где Anthropic получила +90% качества.
Это как раз идеальный случай для оркестратора с воркерами: read-задача, источники независимы, в одно окно всё не влезет. «Читаем много → параллелим» — вторая половина правила.
Практика: посмотрите на оркестратор в работе
🛠 Задание на 10 минут
Откройте Claude Code и дайте ему read-задачу с явной параллельностью, например: «Запусти трёх параллельных субагентов: пусть каждый изучит один из моих проектов [назовите три] и вернёт краткую сводку — что за проект, какой стек, в каком состоянии. Потом сведи в общую таблицу».
Наблюдайте структуру: главный агент (оркестратор) формулирует задания → субагенты (воркеры) работают одновременно в своих контекстах → оркестратор собирает сводки. Это паттерн №5 вживую.
Обратите внимание: вы видите только итоги работы воркеров — их черновой процесс остался в их окнах (изоляция контекста из урока 2).
Контрольный вопрос себе: в моих регулярных задачах — где есть «читаем много» (кандидаты на воркеров), а где «пишем одно» (один агент)? Запишите по 2 примера — пригодится в финальном проекте курса (урок 9).
Что дальше
Следующий урок — память агентов: чем краткосрочная память отличается от долгосрочной, как агент «помнит» вас между сессиями, что такое memory tool и почему память — это файлы, а не магия.