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

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

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

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

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

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

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

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

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

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

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