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

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

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

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

Воркфлоу чи агент: із чого починати

Швидка рамка, щоб патерни стали на свої місця. За розмежуванням Anthropic, воркфлоу — це коли логіку керування тримає код (кроки задані заздалегідь), а агент — коли модель сама динамічно обирає наступний крок. Перші чотири з п’яти патернів — це рівень воркфлоу (структуру задає код), і саме з них варто починати: вони передбачуваніші й дешевші.

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

BINANCEДосі дивишся збоку?Ринок працює без вихідних. Рахунок на Binance відкривається за 2 хвилини.Почати зараз

Патерн 1. Ланцюжок промптів (prompt chaining)

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

Anthropic набрала 14,8 ГВт обчислень за одинадцять місяців

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 або молодша, а складне ескалюється вище.

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

BINANCEДосі дивишся збоку?Ринок працює без вихідних. Рахунок на Binance відкривається за 2 хвилини.Почати зараз

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

Патерн 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 не вводить шостий патерн, а дає готові примітиви під уже наявні п’ять. Субагенти — будівельний блок оркестратора-воркерів; хуки — ті самі програмні «ворота» з ланцюжка промптів, реалізовані як колбек. Індустрія до середини 2026 року не замінила ці п’ять патернів, а добудувала навколо них каталоги на десяток-другий прийомів — але ядро лишилося тим самим. Практичний висновок для тих, хто будує власні системи: опануйте ці п’ять як алфавіт, а модні надбудови читайте вже як їхні комбінації, а не як щось принципово нове.

FAQ

Скільки всього патернів агентних систем і які вони? За каноном Anthropic — п’ять: ланцюжок промптів, маршрутизація, паралелізація, оркестратор-воркери й оцінювач-оптимізатор. Перші чотири — рівня воркфлоу (логіку тримає код), п’ятий часто огортає решту. Індустрія добудувала навколо них додаткові прийоми, але ці п’ять лишаються ядром.

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

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

Як не спалити бюджет на патерні оркестратор-воркери чи оцінювач-оптимізатор? Ставте жорсткі стелі: максимум ітерацій в оцінювача-оптимізатора і ліміт на кількість воркерів і токенів в оркестратора. У незалежному тесті оркестратор без стелі спалив близько 277 тисяч токенів на одне завдання — саме через відсутність обмеження.

Чи небезпечні патерни маршрутизації з погляду безпеки? Роутер і оркестратор — це межі довіри. Якщо вони приймають рішення на основі недовіреного зовнішнього тексту, їх можна обдурити prompt-ін’єкцією — як в інциденті GitLost (липень 2026), де агента через текст GitHub Issue змусили злити приватні репозиторії. Обов’язково розділяйте системні інструкції та користувацький контент і перевіряйте вхід, а не лише вихід.