Пять паттернов агентных систем: механика, примеры и цена каждого

Коротко (TL;DR)

Anthropic в каноничном посте (декабрь 2024) описала пять базовых паттернов, из которых собираются почти все агентные системы. Это не теоретическая классификация «для галочки», а шкала возрастающей цены и риска: каждый следующий паттерн дороже в токенах и сложнее в отладке, чем предыдущий, и должен решать конкретную проблему, а не добавляться «на всякий случай».

Главный принцип — начинать с простого и усложнять осознанно. Ниже — механика каждого паттерна, бытовой пример под каждый, честная экономика в токенах и раздел рисков с реальным инцидентом 2026 года.

Воркфлоу или агент: с чего начать

Быстрая рамка, чтобы паттерны встали на место. По разграничению Anthropic, воркфлоу — это когда логику управления держит код (шаги заданы заранее), а агент — когда модель сама динамически выбирает следующий шаг. Первые четыре из пяти паттернов — это воркфлоу-уровень (структура задана кодом), и именно с них стоит начинать: они предсказуемее и дешевле.

Правило простое: start simple, scale intelligently. Не тянитесь сразу к оркестратору с десятком воркеров — сначала проверьте, не решается ли задача цепочкой промптов. Каждый следующий паттерн оправдан, только если он снимает конкретную боль предыдущего уровня.

BYBITВсё ещё смотришь со стороны?Рынок работает без выходных. Счёт на Bybit открывается за 2 минуты.Начать сейчас

Паттерн 1. Цепочка промптов (prompt chaining)

Механика: задача разбивается на последовательные шаги, и между ними ставятся программные «ворота»-проверки (gate). Каждый шаг получает на вход результат предыдущего, а gate решает, можно ли идти дальше.

Anthropic за одиннадцать месяцев набрала 14,8 ГВт вычислений — оценка контрактов до $517 млрд

OpenAI признала «инцидент с вики»: агенты сделали 15 000 правок и делились обходами

Meta Muse Spark 1.3: топ-режим max пока недоступен разработчикам

GPT-6 Astra: что умеет модель OpenAI, сколько стоит и где её пределы

Nvidia покупает Hugging Face за $12,9 млрд: чипы NVIDIA не станут обязательными

Пример — обработка кредитной заявки. Шаг 1: извлечь данные из заявки. Gate: все обязательные поля заполнены? Нет — вернуть на уточнение, не тратить модель дальше. Шаг 2: скоринг. Шаг 3: формирование решения. Программная проверка между шагами не даёт мусорным данным дойти до дорогого этапа.

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

Почему это базовый паттерн (prompt chaining): сама идея «ворот» между шагами — программной проверки, которая не пускает плохой результат дальше, — переиспользуется во всех остальных паттернах. По сути gate это способ вернуть детерминизм в недетерминированную систему: модель может ошибиться на шаге, но код за ней проверит и не даст ошибке дойти до дорогого этапа. Держите ворота узкими и машинно-проверяемыми (формат, диапазон, обязательные поля), а не «пусть модель сама оценит» — иначе проверка наследует ту же ненадёжность, что и генерация.

Паттерн 2. Маршрутизация (routing)

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

Пример — поддержка. Обращение классифицируется: возврат товара / технический вопрос / жалоба — и уходит на свою ветку с подходящим промптом и инструментами. Роутинг по уровню модели — отдельная экономия: типовой вопрос закроет модель класса Claude Sonnet 5 или младше, а сложный эскалируется выше.

Риск, который часто недооценивают: роутер — это граница доверия, а не просто развилка. Если он маршрутизирует или выполняет действия на основе недоверенного внешнего текста, его можно обмануть (подробнее — в разделе рисков).

BYBIT COPY TRADINGКопитрейдинг на BybitОткрытая статистика трейдеров, старт с $10, отключение в один клик.Выбрать трейдера

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

Паттерн 3. Параллелизация (parallelization)

Механика: задача выполняется несколькими путями одновременно. Два подвида: — Sectioning — разбить на независимые подзадачи и решать их параллельно (подзадачи известны заранее). — Voting — прогнать одну задачу несколько раз и проголосовать за результат, повышая надёжность.

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

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

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

Паттерн 4. Оркестратор-воркеры (orchestrator-workers)

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

Пример — мониторинг цен. Оркестратор получает задание «собрать цены на товар по рынку», сам определяет список источников (заранее неизвестный), поднимает воркеров под каждый и сводит в отчёт. Воркерам обычно нужны внешние инструменты и доступ к данным.

Цена: это самый дорогой из воркфлоу-паттернов. По enterprise-оценке Anthropic (2025), полноценная мультиагентная система расходует в 10–15 раз больше токенов, чем одиночный агент. При этом в собственном research-эвале Anthropic мультиагентная конфигурация (ведущий на Opus, воркеры на Sonnet) обошла одиночного агента на 90,2% — но это внутренний замер по одной методике, и он про сложные исследовательские задачи, а не про любые.

Паттерн 5. Оценщик-оптимизатор (evaluator-optimizer)

Механика: один компонент генерирует результат, другой его оценивает и даёт обратную связь — и так по кругу, пока не пройдены критерии. Обычно хватает 2–5 итераций.

Пример — рекламный текст. Генератор пишет вариант объявления, критик проверяет по чек-листу (длина, tone of voice, наличие оффера) и возвращает правки; цикл повторяется, пока текст не пройдёт все критерии. Важно задать потолок итераций, иначе цикл может крутиться бесконечно.

Когда применять: есть чёткий, проверяемый критерий качества и ценность в доводке. Когда избегать: критерий размытый («сделай хорошо») — оценщику не на что опереться, и цикл не сходится.

Почему связка генератор-критик работает лучше одного прохода: модели легче оценить готовый вариант, чем создать идеальный с первого раза. Разделив роли, вы даёте критику сфокусироваться только на проверке по критериям, а генератору — на исправлении конкретных замечаний. Это тот же принцип, что и код-ревью у людей: автор и рецензент видят разное. Условие успеха — критерии должны быть операциональными (что именно проверяем), иначе критик выдаёт расплывчатые «можно лучше», и цикл не сходится к результату.

Какой паттерн под какую задачу

Сведём выбор в короткий решатель. Двигайтесь сверху вниз и останавливайтесь на первом, что закрывает задачу, — это и есть принцип «start simple».

Ключевая ошибка новичков — брать паттерн «покрасивее» без нужды. Если задача решается цепочкой промптов, оркестратор с воркерами не сделает результат лучше — только дороже и менее предсказуемо. Паттерн должен снимать конкретную боль, а не демонстрировать сложность архитектуры.

Ещё одна тонкость про сам первоисточник: пост «Building Effective Agents» опубликован 19 декабря 2024 года (подтверждено независимым разбором Саймона Уиллисона на следующий день), но живая страница с тех пор обновляется — примеры в ней уже ссылаются на актуальные модели, которых в декабре 2024 не существовало. Это нормальная практика Anthropic держать документ живым; на суть пяти паттернов она не влияет.

Живой кейс: паттерны 4 и 5 вместе

Хороший пример, как идеи паттернов работают на практике, — архитектура долгоживущих агентов от самой Anthropic (описана в конце 2025 года). Там два компонента: агент-инициализатор готовит окружение и один раз собирает спеку задач, а агент-кодер в каждой сессии берёт из неё по фиче и доводит до готовности. Спека хранится в JSON, а не в свободном markdown — и это прямая реализация идеи «ворот» из цепочки промптов (паттерн 1): узкий машинно-проверяемый формат снижает шанс, что агент «улучшит» спеку вместо того чтобы её выполнить.

Важное уточнение: это не чистый оркестратор-воркеры и не канонический оценщик-оптимизатор. Список фич задан заранее (а не дробится оркестратором на лету), и готовность каждой фичи проверяет тот же агент-кодер прогоном через браузер (Puppeteer MCP) — это самопроверка через объективный инструмент, а не отдельный агент-критик в цикле генератор⇄оценщик. Но по духу кейс показывает главное: машинная проверка результата вместо «мне кажется, готово» — тот самый принцип «ворот», ради которого паттерны и существуют. Для сравнения, одиночный ИИ-агент без такой обвязки полагается на самооценку — и потому менее надёжен на длинной дистанции.

Экономика паттернов ИИ-агентов: сколько это стоит

Цена паттерна прямо пропорциональна неопределённости задачи. Параллелизация (подзадачи известны заранее) дешевле оркестратора-воркеров (подзадачи решаются на лету) при сопоставимом качестве — отсюда и разброс в оценках стоимости.

Две цифры, которые нельзя смешивать (данные 2025–2026): — 10–15× — enterprise-оценка Anthropic (2025) для полноценной мультиагентной системы против одиночного агента. — 2–4× — независимый эмпирический бенчмарк (Habr, 2026) на конкретных простых задачах (уровня GSM8K/MMLU), где добавляется лишь один дополнительный вызов на голосование или оценку.

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

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

Риски и антипаттерны: где ломается

Для агентных систем это обязательный раздел рисков — цена ошибки здесь реальна.

Роутер и оркестратор — граница безопасности. Показательный инцидент GitLost (Noma Security, 6 июля 2026): через непрямую prompt-инъекцию в тексте GitHub Issue ИИ-агента заставили слить приватные репозитории — защиту обходили простым словом-связкой «Additionally». Урок: любая система, которая маршрутизирует или выполняет действия на основе недоверенного внешнего текста, обязана явно разделять системные инструкции и пользовательский контент. Каждый слой маршрутизации/делегирования — новая потенциальная точка компрометации.

Семь антипаттернов, которых стоит избегать (по разбору индустрии): — God Prompt — один гигантский промпт вместо разбиения на паттерны. — Uncontrolled Recursion — цикл без потолка итераций (см. 277 тысяч токенов выше). — Output-Only Guardrails — проверять только выход, игнорируя вход. — Governance as Afterthought — безопасность «прикрутим потом». — Over-Agentification — агент там, где хватило бы воркфлоу. — Agent Sprawl — расползание неуправляемого зоопарка агентов. — Vibe-Checking as Testing — «на глаз работает» вместо реальных тестов.

Общая нить: большинство провалов — не про «слабую модель», а про отсутствие ворот, лимитов и разделения доверия. Паттерн без этих ограничений опаснее, чем его отсутствие.

Как паттерны комбинируются

Паттерны — это кирпичи, а не взаимоисключающие варианты. Типовые комбинации: роутер на входе направляет в цепочку или к оркестратору; оценщик-оптимизатор оборачивает любой из предыдущих паттернов как внешний контроль качества.

Для тех, кто строит на Claude Agent SDK, полезно знать: SDK не вводит шестой паттерн, а даёт готовые примитивы под уже существующие пять. Субагенты — строительный блок оркестратора-воркеров; хуки — те самые программные «ворота» из цепочки промптов, реализованные как callback. Индустрия к середине 2026 года не заменила эти пять паттернов, а достроила вокруг них каталоги на десяток-другой приёмов — но ядро осталось прежним. Практический вывод для строящих свои системы: освойте эти пять как алфавит, а модные надстройки читайте уже как их комбинации, а не как что-то принципиально новое.

FAQ

Сколько всего паттернов агентных систем и какие они? По канону Anthropic — пять: цепочка промптов, маршрутизация, параллелизация, оркестратор-воркеры и оценщик-оптимизатор. Первые четыре — воркфлоу-уровня (логику держит код), пятый часто оборачивает остальные. Индустрия достроила вокруг них дополнительные приёмы, но эти пять остаются ядром.

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

Правда ли, что чем больше агентов, тем лучше? Нет. Независимый бенчмарк показывает: на простых задачах одиночный агент выигрывает и по точности, и по стоимости. Мультиагентность окупается только на задачах, заведомо сложных для модели. Многоагентная система расходует в разы больше токенов (оценки от 2–4× до 10–15× в зависимости от масштаба), поэтому усложнять стоит только под доказанную необходимость.

Как не сжечь бюджет на паттерне оркестратор-воркеры или оценщик-оптимизатор? Ставьте жёсткие потолки: максимум итераций у оценщика-оптимизатора и лимит на число воркеров и токенов у оркестратора. В независимом тесте оркестратор без потолка сжёг около 277 тысяч токенов на одну задачу — ровно из-за отсутствия ограничения.

Опасны ли паттерны маршрутизации с точки зрения безопасности? Роутер и оркестратор — это границы доверия. Если они принимают решения на основе недоверенного внешнего текста, их можно обмануть prompt-инъекцией — как в инциденте GitLost (июль 2026), где агента через текст GitHub Issue заставили слить приватные репозитории. Обязательно разделяйте системные инструкции и пользовательский контент и проверяйте вход, а не только выход.