Патерни робочих процесів AI-агентів: 7 патернів і коли кожен справді перемагає (2026)

Патерни робочих процесів AI-агентів: 7 патернів і коли кожен справді перемагає (2026)

Патерни робочих процесів AI-агентів нарешті підкріплені числами: у січні 2026 року Google Research оцінила 180 конфігурацій агентів і з'ясувала, що та сама зміна координації підняла паралелізоване фінансове міркування на 80,9%, але обвалила послідовне планування на PlanCraft на цілих 70%. Той самий важіль, протилежні наслідки. Вирішальна змінна це можливість декомпозиції завдання, а не кількість агентів; сім патернів нижче оцінені за опублікованими даними, а не за діаграмами вендорів.

• Важливі сім патернів: послідовний, маршрутизація, паралелізація, оркестратор-виконавці, рефлексія, ReAct, плануй-і-виконуй.
• Можливість декомпозиції завдання визначає переможця. Паралелізована робота виграє, послідовна деградує.
• Починайте з одного агента. Додавайте другого, лише коли один агент застрягає нижче ~85% точності.

Патерни робочих процесів AI-агентів у підсумку: що кажуть дані

Сім патернів AI-агентів це послідовний (ланцюжок промптів), маршрутизація (передача), паралелізація (розгалуження/злиття), оркестратор-виконавці, рефлексія (оцінювач-оптимізатор), ReAct і плануй-і-виконуй. П'ять вендорів називають їх по-різному, але ці сім форм покривають усі класифікації, які зараз публікують Anthropic, OpenAI, Vercel, Microsoft і Google Cloud. Людина в контурі не входить до сімки: це контрольний шар, який обгортає будь-який із них.

Стовпець вимірювань читайте скептично. Три рядки містять реальні числа; чотири містять «публічних вимірювань немає», і це чесний стан сфери у 2026 році. П'ять вендорів публікують п'ять різних назв для того, що насправді є трьома чи чотирма базовими формами. Останній стовпець існує, щоб ви могли зіставити будь-яку з цих назв із базовою формою, а решта статті розбирає кожну родину окремо.

Два стовпці, які ніхто в SERP не обговорює, це вартість токенів і бюджет затримки. Послідовний патерн і маршрутизація витрачають найменше обох; оркестратор-виконавці витрачають найбільше обох; паралелізація обмінює витрати токенів на реальний час. Обирайте патерн за ресурсом, який справді обмежує ваше завдання, а не за діаграмою, яка виглядає вражаюче.

Що таке патерни робочих процесів AI-агентів (і які 4 етапи робочого процесу AI)?

Патерни проєктування робочих процесів AI-агентів це багаторазові форми для організації викликів LLM, використання інструментів і логіки керування в систему. Сім, які повторюються в кожній класифікації вендорів: послідовний, маршрутизація, паралелізація, оркестратор-виконавці, рефлексія, ReAct і плануй-і-виконуй. Кожен по-різному обмінює вартість токенів, затримку та точність, тому правильний вибір залежить від структури завдання, а не від фреймворку, який вам трапився.

Типовий робочий процес AI-агента проходить чотири етапи по колу:

1. Планування: модель вирішує, що робити далі, з огляду на мету та зібрану історію.
2. Дія: вона викликає інструмент, що у 2026 році зазвичай означає MCP-сервер або виклик функції. Model Context Protocol (MCP) стандартизує цей шар інструментів між моделями.
3. Спостереження: результат інструменту повертається в контекст як нове повідомлення.
4. Рефлексія / цикл: модель оцінює, чи достатньо добрий результат, і повторює цикл або зупиняється.

Кожен патерн у цій статті це спосіб з'єднати ці чотири етапи. Послідовний фіксує порядок у коді. ReAct дає моделі обирати наступний етап на кожному ході. Оркестратор-виконавці розподіляють цикл між кількома моделями.

Перед каталогом важливе одне розмежування. Робочий процес це заздалегідь визначені шляхи коду; агент передає керування моделі. Anthropic проводить межу саме так у Building Effective Agents: «Робочі процеси дають передбачуваність і стабільність для добре визначених завдань, тоді як агенти кращі, коли потрібні гнучкість і ухвалення рішень моделлю в масштабі».

Якщо ви прийшли шукати класичні типи агентів в AI (простий рефлекторний, на основі моделі, на основі мети, навчальний), ця класифікація старіша за LLM; сім патернів вище це ті, які вирішують, чи вийде ваша збірка в продакшен.

Детерміновані патерни: послідовний, маршрутизація та паралелізація

Три патерни тримають керування у вашому коді, а не в моделі. Вони найдешевші у виконанні та найпростіші у налагодженні, а порада команди Claude від березня 2026 року звучить прямо щодо того, з чого починати: «Починайте з найпростішого патерну, який розв'язує вашу проблему. За замовчуванням обирайте послідовний».

Послідовний (ланцюжок промптів)

Один виклик живить наступний. Ви розбиваєте складне завдання на впорядковані кроки, і кожен крок отримує результат попереднього як вхід. Виграш у прозорості: можна перевірити кожен проміжний результат і закешувати кожен крок. Уникайте його, коли підзадачі незалежні, бо ви платите затримкою за впорядкування, яке вам не потрібне. Якщо стан має переживати кроки або сеанси, це проблема пам'яті, а не ланцюжка; розмежування описане в нашому гіді з пам'яті агентів. Єдине опубліковане схвалення це замовчування: жодне дослідження не вимірює вигоди від самого ланцюжка, бо це базова лінія, яку кожен інший патерн має перевершити ціною додаткових витрат.

from anthropic import Anthropic

client = Anthropic()

def chain(steps: list[str], context: str = "") -> str:
    for step in steps:
        msg = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=1024,
            messages=[{"role": "user", "content": f"{context}\n\n{step}"}],
        )
        context = msg.content[0].text
    return context

summary = chain([
    "Extract the five key claims from this report: {report}",
    "Rewrite those claims as bullets an engineer would trust.",
])

Маршрутизація (передача)

Дешевий класифікатор читає вхід і відправляє його спеціалізованому промпту або моделі. OpenAI формулює це в документації Agents SDK: «Агент сортування спрямовує розмову до спеціаліста, і цей спеціаліст стає активним агентом на решту ходу». Уникайте маршрутизації, коли класифікатор менш надійний, ніж простий запуск одного загального шляху, бо кожна хибна маршрутизація це тиха неправильна відповідь. Названий режим збою тут це втрата контексту під час передачі: спеціаліст бачить лише те, що пересилає маршрутизатор. Перенесення повного сліду це рішення з інженерії контексту, і помилки в ньому пояснюють, чому маршрутизовані системи здаються забудькуватими. Математика токенів усе одно на боці маршрутизації: класифікатор працює на малій моделі (gpt-4o-mini вище), тож маршрутизатор додає кілька сотень дешевих токенів на запит замість другого дорогого виклику.

from openai import OpenAI

client = OpenAI()
SPECIALISTS = {
    "billing": "You answer billing and refund questions.",
    "technical": "You debug API errors and integration issues.",
}

def route(question: str) -> str:
    triage = client.responses.create(
        model="gpt-4o-mini",
        input=f"Reply with exactly one of {list(SPECIALISTS)}: {question}",
    )
    key = triage.output_text.strip().lower()
    return client.responses.create(
        model="gpt-4o",
        instructions=SPECIALISTS.get(key, SPECIALISTS["technical"]),
        input=question,
    ).output_text

Паралелізація (розгалуження/злиття)

Незалежні підзадачі виконуються одночасно, потім крок злиття об'єднує їх. Anthropic ділить це на секціонування (розподіл роботи) і голосування (запуск того самого завдання кілька разів і порівняння). Саме цю форму Google Research виміряла на +80,9% проти одного агента на паралелізованому фінансовому міркуванні у січні 2026 року, саме тому що завдання чисто декомпонувалося. Уникайте її щойно крок n+1 залежить від результату кроку n; паралелізація ланцюжка залежностей просто швидше перевпорядковує неправильні відповіді. Затримка це друга половина виграшу: незалежні виклики йдуть паралельно, тож реальний час падає приблизно з кількістю виконавців, а сумарні витрати токенів лишаються плоскими.

from concurrent.futures import ThreadPoolExecutor
from anthropic import Anthropic

client = Anthropic()

def run(subtask: str) -> str:
    msg = client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=1024,
        messages=[{"role": "user", "content": subtask}],
    )
    return msg.content[0].text

def fan_out(subtasks: list[str]) -> list[str]:
    with ThreadPoolExecutor(max_workers=len(subtasks)) as pool:
        return list(pool.map(run, subtasks))

parts = fan_out([
    "Summarize Q1 revenue drivers in two sentences.",
    "Summarize Q1 churn drivers in two sentences.",
])
merged = run(f"Combine into one executive summary:\n{parts}")

ReAct проти Plan-and-Execute: який патерн міркування обрати?

ReAct чергує міркування з дією: модель думає, викликає інструмент, спостерігає результат і лише потім вирішує наступний крок. Плануй-і-виконуй записує повний план до запуску будь-якого інструменту, потім виконує кроки за порядком. ReAct адаптується до несподіванок під час виконання; плануй-і-виконуй платить за один великий виклик планування наперед і довіряє маршруту.

ReAct визначає наступний крок після кожного спостереження; плануй-і-виконуй фіксує весь маршрут до першого виклику інструменту.

ReAct походить від Yao et al. (arXiv 2210.03629, v1 жовтень 2022, v3 березень 2023), які повідомили про +34% абсолютного успіху на ALFWorld і +10% на WebShop проти базових ліній імітаційного навчання та навчання з підкріпленням, використовуючи лише один-два приклади в контексті. Це цикл за замовчуванням для більшості агентів, що використовують інструменти, і це прогалина в #3 результату SERP: документація Microsoft Learn з оркестрації на 7 133 слова взагалі оминає ReAct. Цей ритм «спостерігай-вирішуй» пояснює, чому ReAct краще працює з відкритими завданнями («шукай, доки не знайдеш X»), ніж будь-який попередній план: план мав би вгадати вміст сторінок до їх читання.

Плануй-і-виконуй походить від Wang et al., Plan-and-Solve Prompting (arXiv 2305.04091, ACL 2023), яка спершу складає план, що ділить завдання на підзадачі, а потім їх виконує. Стаття повідомляє про перевагу над zero-shot chain-of-thought на всіх десяти оцінених датасетах; ми не цитуємо єдиного числа, бо анотація статті жодного не публікує. Використовуйте його, коли маршрут передбачуваний і перепланування після кожного кроку витрачало б токени. Компроміс це крихкість: якщо крок три не вдається, цикл плануй-і-виконуй потребує явного хука перепланування, тоді як ReAct переплановує за своєю побудовою.

Рядок виміряних доказів це чесний індикатор. ReAct має статтю 2022 року з числами на рівні завдань; плануй-і-виконуй має огляд десяти датасетів без заголовного числа, і це одна з причин, чому його цитують частіше, ніж бенчмаркають.

from anthropic import Anthropic

client = Anthropic()

def react(question: str, tools: list, max_steps: int = 8) -> str:
    messages = [{"role": "user", "content": question}]
    for _ in range(max_steps):
        msg = client.messages.create(
            model="claude-sonnet-4-5",
            max_tokens=1024,
            tools=tools,
            messages=messages,
        )
        if msg.stop_reason == "end_turn":
            return msg.content[0].text
        messages.append({"role": "assistant", "content": msg.content})
        messages.append({"role": "user", "content": dispatch(msg.content)})
    return "Stopped: hit the iteration cap with no final answer."

Цей лічильник ітерацій не опціональний. Цикл ReAct без виходу спалює токени, доки не скінчиться бюджет; max_steps найдешевший запобіжник у цій статті. Плануй-і-виконуй потребує того самого запобіжника на рівень вище: обмежуйте перепланування, а не лише кроки, інакше невдалий план відтворюватиме себе нескінченно.

Патерни якості: рефлексія, оцінювач-оптимізатор і людина в контурі

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

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

def refine(task: str, score_fn, max_rounds: int = 4) -> str:
    best = generate(task)
    best_score = score_fn(best)
    for _ in range(max_rounds):
        critique = critic(task, best)
        candidate = generate(f"{task}\n\nCritique:\n{critique}")
        score = score_fn(candidate)
        if score <= best_score:
            break  # no improvement: stop spending tokens
        best, best_score = candidate, score
    return best

Людина в контурі це контрольний шар, а не восьмий патерн. Вона обгортає будь-який із семи: людина схвалює перед виконанням незворотного кроку. Лише 2 з 6 топ-результатів SERP узагалі висвітлюють це. Розміщуйте шлюз на незворотних діях, реальних витратах і всьому, що покидає вашу систему як зовнішня комунікація. Все інше має виконуватися без нагляду або не виконуватися. Сам шлюз має бути простим кодом, а не ще одним LLM: черга схвалень, поріг витрат, список дозволених доменів. Доручати моделі вирішувати, чи має людина подивитися, означає знищувати сенс.

Чи варта багатоагентність 15× токенів? Що насправді кажуть бенчмарки

Оркестратор-виконавці це сьомий патерн: провідний агент декомпонує завдання, доручає частини агентам-виконавцям і об'єднує повернуте. «Багатоагентність» це цей патерн, доведений до крайності, а не окрема форма, тож питання насправді в тому, коли оркестратор виправдовує свої накладні витрати.

Коли використовувати багатоагентну систему замість одного агента? Лише коли один агент застрягає нижче приблизно 85% точності на завданні. Це емпіричне правило циркулювало на r/AI_Agents (2026-04-23) поруч із дослідженням Google Research, і воно збігається з виміряними даними: понад цією планкою додані агенти додають вартість і підсилення помилок, не додаючи точності.

Ось усі опубліковані числа, які ми змогли верифікувати, пліч-о-пліч:

Одне застереження, перш ніж переходити за посиланнями: усі числа Google Research вище походять із допису в блозі від 2026-01-28, а стаття за ним (arXiv 2512.08296) відтоді переглянута, тож її поточна версія повідомляє про 260 конфігурацій і R² = 0,373 замість 180 і 0,513 у блозі. Напрямок тримається в обох випадках; точні числа залежать від версії, яку ви читаєте.

Два з цих рядків регулярно цитують неправильно, тож ось арифметика. Показник Anthropic 15× виміряний проти чат-взаємодії, а її одноагентний показник це 4×. Тож багатоагентна система коштує приблизно 15 / 4 = 3,75× токенів одного агента, а не 15×. А підсилення помилок Google Research 17,2× для незалежних агентів проти 4,4× для централізованих означає, що оркестратор містить приблизно 17,2 / 4,4 = 3,9× менше підсилення помилок, ніж пускання агентів без нагляду.

Читаючи звіт Anthropic поруч із числами Google Research, наш висновок такий: можливість декомпозиції, а не кількість агентів, це вирішальна змінна. Дослідницьке завдання Anthropic чисто розпалося на паралельні підпошуки, тож більше агентів допомогло. Послідовні планувальні завдання Google не розпалися, тож більше агентів заважали одне одному.

Це збігається з тим, що кажуть практики, коли системи доходять до продакшену. На r/AI_Agents гілка під назвою «Multi agent systems are a total nightmare in production» (2026-04-23, 56 балів, 68 коментарів) почалася від автора, який запустив 20+ клієнтських систем: «Ті, що справді лишаються працювати… майже соромно прості», і «кожного разу, коли один агент говорить з іншим, ви втрачаєте контекст. Це як гра в зіпсований телефон». Верхній коментар концентрує весь розділ: «спробуйте розв'язати проблему одним агентом. Якщо цей агент має >85% точності, багатоагентна система не додасть жодної цінності».

Перш ніж додавати агента, спробуйте дешеві виправлення, які виміряла Anthropic: один покращений опис інструменту дав 40% скорочення часу виконання завдання, а паралельні виклики інструментів скоротили час дослідження на цілих 90%. Обидва б'ють другого агента за вартістю. Якщо ви все ж переходите до багатоагентності в реальному інструменті, субагенти Claude Code це оркестратор-виконавці, яких можна інспектувати рядок за рядком.

Один патерн, п'ять назв: таблиця відповідностей фреймворків

Ті самі чотири форми з'являються під різними назвами в документації кожного вендора, і назви не переносяться між фреймворками. «Magentic» і «group chat» від Microsoft не означають нічого в OpenAI SDK, доки ви їх не перекладете, і цей податок на переклад реальна вартість, яку ця таблиця прибирає.

П'ять вендорів, п'ять словників, три або чотири реальні форми. Практична вартість виявляється, коли ви змінюєте фреймворки: команда, що переходить з Microsoft Agent Framework на OpenAI SDK, має перемапувати «magentic» на agents-as-tools, а «group chat» на граф передач, перш ніж перенесеться хоч один рядок коду. Таксономія Google Cloud з одинадцятьма назвами найдовша, список Anthropic із сімома назвами найцитованіший, а три назви з блогу Claude це ті, які ви впровадите першими. Читайте форму, потім читайте SDK. Заголовки стовпців це сама документація: Anthropic, блог Claude, OpenAI Agents SDK, Vercel AI SDK, Microsoft Learn і Google Cloud. Коли ви бачите форми, вибір фреймворку окреме рішення; наш огляд найкращих фреймворків AI-агентів 2026 і порівняння LangGraph проти CrewAI проти OpenAI Agents SDK покривають це.

Коли робочий процес з AI-агентом узагалі не потрібен?

Часто не потрібен. Найбільш підтримана драбинка рішень на r/AI_Agents (2026-03-09) каже прямо: «Якщо працюють оператори if…then, використовуйте їх. Потім, якщо працюють традиційні робочі процеси, використовуйте їх. Інакше використовуйте агентний AI». Два з трьох топ-результатів SERP це хмарна документація, яка структурно не може сказати вам будувати менше. Ми можемо. Дані в цій статті вказують у той самий бік: два найбільші виміряні виграші (+80,9% і +90,2%) обидва прийшли з завдань, які чисто декомпонувалися, а найбільша виміряна втрата (−70%) прийшла з примушування агентів до завдання, яке ні.

Режими збою мають назви, і кожен тепер має число:

• Втрата контексту під час передач: кожне повідомлення між агентами губить стан (скарга «зіпсований телефон» на r/AI_Agents, 2026-04-23).
• Підсилення помилок: 17,2× для незалежних агентів проти 4,4× централізованих (Google Research, 2026-01-28).
• Некеровані цикли рефлексії: обмежуйте ітерації та зупиняйтеся за відсутності покращення, як у коді вище.
• Деградація послідовних завдань: на 39–70% гірше, коли ви паралелізуєте роботу, яка не декомпонується (Google Research, 2026-01-28).
• Роздування вартості: приблизно 15× токенів чату для багатоагентної системи (Anthropic, 2025-06-13).

Кожен із цих режимів збою має обмежувач, який можна написати за десять рядків коду, і обмежувач завжди дешевший за агента, якого ви збиралися додати.

Волден Ян із Cognition зробив той самий аргумент з боку будівельника в Don't Build Multi-Agents (2025-06-12): «Діліться контекстом і діліться повними слідами агента, а не лише окремими повідомленнями», і «Дії несуть неявні рішення, а конфліктні рішення несуть погані результати». Порівняння з r/AI_Agents те, до якого ми повертаємося: «багатоагентність починає виглядати як мікросервіси. потужно, коли межі реальні, боляче, коли вони вигадані».

Як Techsy обирає патерни

Драбинка нижче це наше прочитання висновків Google Research і Anthropic плюс гілки практиків, а не наш власний виміряний результат. Ми проходимо її зверху донизу і зупиняємося на першому рядку, який підходить:

З даних у цій статті випливають три речі. Починайте послідовно, бо Anthropic так каже, і ніщо в SERP цього не спростовує. Паралелізуйте лише те, що декомпонується, бо та сама зміна координації, виміряна на +80,9%, також виміряна на −70%. І ставтеся до другого агента як до останнього засобу, бо рахунок за токени реальний, а підсилення помилок виміряне. Наскрізна думка: додавання агентів це хід масштабування, а не якості; бенчмарки винагороджують його лише там, де робота розпадається, а гілки практиків підтверджують це всюди індя. Якщо хочете другу думку про архітектуру, перш ніж будувати, отримайте безплатну консультацію.

Поширені запитання

Які 7 патернів AI-агентів?

Сім це послідовний (ланцюжок промптів), маршрутизація (передача), паралелізація (розгалуження/злиття), оркестратор-виконавці, рефлексія (оцінювач-оптимізатор), ReAct і плануй-і-виконуй. Вони повторюються під різними назвами в кожній класифікації вендорів, від Anthropic до Google Cloud. Людину в контурі обговорюють поруч із ними, але це контрольний шар, який обгортає будь-який із семи, а не восьмий патерн.

Які 4 етапи робочого процесу AI-агента?

Планування, дія, спостереження, рефлексія. Модель планує наступний крок, діє через виклик інструменту, спостерігає, як результат інструменту входить у контекст, потім оцінює, чи досягнута мета, і повторює цикл або зупиняється. Кожен патерн у цій статті це спосіб з'єднати ці чотири етапи.

У чому різниця між робочим процесом AI і AI-агентом?

Робочий процес іде заздалегідь визначеними шляхами коду; агент дозволяє моделі керувати власним потоком керування. Правило Anthropic: робочі процеси для передбачуваності на добре визначених завданнях, агенти для гнучкості, коли потрібні рішення на основі моделі в масштабі. Більшість продакшен-систем це робочі процеси з кількома агентними кроками всередині.

ReAct чи плануй-і-виконуй: що використовувати?

Використовуйте ReAct, коли наступний крок залежить від того, що повернув останній інструмент, і маршрут може змінитися під час виконання. Використовуйте плануй-і-виконуй, коли маршрут передбачуваний наперед і перепланування після кожного кроку витрачало б токени. ReAct виміряв +34% на ALFWorld (Yao et al., 2022); плануй-і-виконуй перевершив zero-shot CoT на десяти датасетах (Wang et al., 2023).

Чи потрібен фреймворк на кшталт LangGraph, щоб використовувати ці патерни?

Ні. Кожен блок коду в цій статті це звичайний виклик SDK, і патерни старші за фреймворки, які їх називають. Фреймворк виправдовує себе на збереженні стану, повторних спробах і трасуванні, а не на самому патерні. Якщо обираєте, наше порівняння фреймворків покриває компроміси.

Як зупинити цикл рефлексії від нескінченного виконання?

Два запобіжники, обидва в коді: жорсткий лічильник ітерацій (ми використовуємо 4 раунди) і зупинка за відсутності покращення, яка спрацьовує щойно переписана критиком версія не набирає більше балів, ніж поточна чернетка. Не довіряйте промпту завершити цикл; модель не має уявлення про вартість речей.

Коли одного агента достатньо?

Коли він долає приблизно 85% точності на завданні. Ця евристика, що циркулювала на r/AI_Agents (2026-04-23) поруч із дослідженням Google Research, збігається з бенчмарками: понад цією планкою додаткові агенти додають вартість і підсилення помилок, не додаючи точності. Виміряйте базову лінію одного агента, перш ніж проєктувати щось більше.

Де знайти приклади патернів робочих процесів AI-агентів із кодом?

П'ять блоків Python вище покривають послідовний, маршрутизацію, паралелізацію, ReAct і рефлексію, усі як звичайні виклики SDK, які можна взяти напряму. Для прикладів у стилі вендорів Vercel AI SDK постачає робочий TypeScript на кожен патерн, а документація OpenAI Agents SDK покриває передачі та agents-as-tools. Посилання на обидва є в списку джерел нижче.

Джерела

• Anthropic, Building Effective Agents (2024-12-19)
• Anthropic, How we built our multi-agent research system (2025-06-13)
• Google Research, Towards a science of scaling agent systems (2026-01-28); стаття: arXiv 2512.08296
• Yao та ін., ReAct: Synergizing Reasoning and Acting in Language Models (v3 2023-03-10)
• Wang та ін., Plan-and-Solve Prompting (ACL 2023)
• Claude від Anthropic, Common workflow patterns for AI agents (2026-03-05)
• OpenAI Agents SDK, Orchestrating multiple agents
• Vercel AI SDK, Workflow Patterns
• Microsoft Learn, AI Agent Orchestration Patterns (оновлено 2026-05-12)
• Google Cloud, Choose a design pattern for your agentic AI system (2026-05-28)
• Cognition (Волден Ян), Don't Build Multi-Agents (2025-06-12)
• r/AI_Agents, Multi agent systems are a total nightmare in production (2026-04-23); Wait, are workflows actually better than multi-agent systems? (2026-03-09)