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

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

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

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

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

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

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

SpaceX · xStockSpaceX — частная компания. Торгуй её токеном на Bybit за крипту.Торговать SpaceX →

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

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

AMD покупает себе место у Anthropic: 2 гигаватта MI450 в обмен на инвестицию до $5 млрд

Один агент или несколько: как выбрать мультиагентную архитектуру

Воркфлоу против ИИ-агента: как выбрать и не переплатить за автономность

Как не терять контекст в Claude Code: компакт, resume и handoff

Оркестрация агентов Claude Code: как заставить их работать командой

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

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

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

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

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

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

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

Bybit · Rewards Hubдо $30,100Внеси депозит, торгуй 14 дней — и забери награды в Rewards HubЗабрать бонус →

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

Паттерн 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 заставили слить приватные репозитории. Обязательно разделяйте системные инструкции и пользовательский контент и проверяйте вход, а не только выход.