Архітектура AI-агентів: коли будувати workflow, а коли справді потрібен агент

«Нам потрібен AI-агент» — один із найчастіших запитів, які ми чуємо. Часто бізнесу насправді потрібен надійний workflow з одним-двома викликами LLM у правильних місцях. Іноді — справді агент. Помилка коштує дорого в обидва боки: переускладнений агент повільний, дорогий і непередбачуваний; надто слабкий workflow ламається на кожному випадку, якого не передбачили. У гайді — будівельні блоки, патерни з них і як обирати.

Workflow проти агентів

Відома стаття Anthropic Building effective agents проводить корисну межу:

Workflow — системи, де LLM та інструменти оркеструються через заздалегідь визначені шляхи в коді. Кроки визначаєте ви; модель заповнює «розумні» частини.
Агенти — системи, де LLM динамічно керує власним процесом і використанням інструментів, вирішуючи, що робити далі, залежно від результатів.

Головна порада статті — починати з найпростішого рішення й додавати складність лише тоді, коли вона доведено покращує результат. Це збігається з нашим досвідом: більшість продакшен-систем, які ми будуємо, — це workflow з агентом усередині одного чітко обмеженого кроку.

Будівельний блок: доповнена LLM

Кожен патерн починається з одного виклику LLM, доповненого:

Пошуком (retrieval) — релевантними документами з вашої бази знань; див. RAG для бізнесу.
Інструментами — функціями, які модель може викликати: пошук, запити до БД, API; див. проєктування інструментів для агентів.
Пам'яттю — релевантними фактами з попередніх взаємодій.

Багато задач розв'язуються одним добре побудованим доповненим викликом. Спробуйте спершу це і виміряйте результат за допомогою evals, перш ніж будувати щось більше.

Патерни workflow

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

Розбийте задачу на послідовні кроки, кожен з яких — виклик LLM, що обробляє попередній результат. Між кроками додайте програмні перевірки («шлюзи»).

Приклад: згенерувати опис товару → перевірити довжину й заборонені твердження в коді → перекласти українською → звірити термінологію з глосарієм.

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

Маршрутизація (routing)

Класифікуйте вхідні дані й відправте їх у спеціалізований промпт, модель або пайплайн.

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

Коли використовувати: вхідні дані розпадаються на чіткі категорії, які краще обробляти окремо.

Паралелізація

Запустіть кілька викликів LLM одночасно й агрегуйте результати в коді. Два варіанти:

Секціонування: незалежні підзадачі паралельно, наприклад перевірка договору на п'ять типів ризиків одночасно.
Голосування: та сама задача кілька разів з вибором більшості або найобережнішого результату, наприклад відправка контенту на перевірку, якщо його позначила хоч одна з трьох перевірок.

Коли використовувати: підзадачі незалежні або потрібна вища впевненість.

Orchestrator-workers

Центральна LLM динамічно розбиває задачу на підзадачі, делегує їх викликам-виконавцям і синтезує результати. На відміну від паралелізації, підзадачі заздалегідь невідомі.

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

Evaluator-optimizer

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

Приклад: переклад із нюансами, резюме, що мусить містити певні факти, код, що має пройти тести.

Коли використовувати: є чіткі критерії оцінки, а ітерації вимірно покращують результат.

Автономні агенти

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

def run_agent(task: str, tools: dict, max_steps: int = 20) -> str:
    messages = [{"role": "user", "content": task}]
    for step in range(max_steps):
        response = llm(messages=messages, tools=list(tools.values()))
        messages.append({"role": "assistant", "content": response.content})
        if response.stop_reason != "tool_use":
            return response.text  # модель вирішила, що закінчила
        results = []
        for call in response.tool_calls:
            try:
                output = tools[call.name].run(**call.input)
            except Exception as e:
                output = f"Error: {e}"  # нехай модель побачить і відновиться
            results.append(tool_result(call.id, output))
        messages.append({"role": "user", "content": results})
    raise StepLimitExceeded(task)

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

Як обрати

Запитання	Якщо так	Якщо ні
Чи можна заздалегідь записати кроки?	Workflow	Розгляньте агента
Чи дорога або незворотна помилкова дія?	Workflow або агент із погодженням людини	Агент може підійти
Чи критична затримка (до 2–3 с)?	Один виклик або короткий ланцюжок	Агенти прийнятні
Чи великий обсяг і тонка маржа?	Workflow з маршрутизацією на малі моделі	Вартість агента може бути прийнятною
Чи можна автоматично перевірити успіх?	Агент або evaluator-optimizer можуть самі виправлятися	Залишайте людину в циклі

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

Продакшен-аспекти агентів

Умови зупинки

Агентам потрібні явні ліміти: максимум кроків, токенів, часу і витрат на задачу. Коли ліміт досягнуто, повертайте корисний частковий результат або ескалюйте людині — не падайте мовчки.

Контрольні точки з людиною

Для дій з реальними наслідками — надсилання листів, повернення коштів, зміна записів — вимагайте підтвердження. Це також найефективніший захист від prompt injection; див. безпека AI-агентів.

Зростання контексту

Кожен крок додає в контекст результати інструментів. Довготривалим агентам потрібні стиснення, підсумовування, зовнішня пам'ять або субагенти зі свіжим контекстом. Це тема контекстної інженерії.

Спостережуваність

Агента неможливо дебажити за фінальною відповіддю. Трасуйте кожен крок: рішення моделі, виклики інструментів з аргументами, результати, токени й затримку. Див. спостережуваність LLM.

Оцінювання

Оцінюйте і результат (чи правильно виконано задачу?), і траєкторію (скільки кроків, скільки помилок інструментів, чи були спроби небезпечних дій?). Агент, що дає правильну відповідь за 40 кроків замість 6, — це проблема вартості й затримки.

Фреймворки: використовувати чи ні?

Фреймворки на кшталт LangGraph, OpenAI Agents SDK, Claude Agent SDK, Spring AI чи LangChain4j пришвидшують прототипування й дають корисну інфраструктуру: виклик інструментів, керування станом, трасування. Водночас вони додають шари абстракції, що можуть приховувати, які саме промпти й виклики надсилаються. Наша порада:

Спершу зрозумійте «сирий» API — побудуйте один цикл агента вручну.
Беріть фреймворк, коли потрібні його можливості (персистентність, human-in-the-loop, трасування), а не за замовчуванням.
Переконайтеся, що бачите точні промпти й виклики інструментів, які надсилає фреймворк.

Для Java-команд природний вибір — Spring AI; для TypeScript більшість потреб покриває Vercel AI SDK. Якщо відкрити ваші бізнес-системи як інструменти через Model Context Protocol, їх можна буде повторно використовувати з різними фреймворками й клієнтами.

Розібраний приклад: обробка рахунків

Вимога: заносити вхідні рахунки постачальників в ERP.

Версія 1 (workflow): видобути поля через structured output → перевірити суми й податкові номери в коді → знайти постачальника в ERP за кодом ЄДРПОУ → створити чернетку рахунку. Винятки потрапляють у чергу до людини. Це покриває переважну більшість рахунків.
Версія 2 (гібрид): для винятків — невідомий постачальник, невідповідність замовленню, незвична валюта — агент з інструментами лише на читання (пошук постачальників, пошук замовлень, читання умов договору) розслідує і пропонує рішення, яке погоджує людина.

Агент запускається лише на складних випадках, з інструментами на читання і з погодженням людини. Саме таку форму мають більшість успішних бізнес-агентів. Детальніше про видобування — у статті обробка документів з LLM.

FAQ

Чат-бот з RAG — це агент? Зазвичай ні: це доповнена LLM у фіксованому workflow «знайти — відповісти». Агентом він стає, коли модель сама вирішує, коли й скільки разів шукати та які інструменти використовувати.

Чи потрібні нам кілька агентів? Спочатку — рідко. Мультиагентні системи допомагають у широких задачах, що добре паралеляться, і споживають значно більше токенів; див. мультиагентні системи.

Як протестувати агента до продакшену? Зберіть набір сценаріїв з очікуваними кінцевими станами, запускайте їх у пісочниці з моками чи staging-інструментами й оцінюйте і результати, і траєкторії.

Яку модель використовувати агенту? Агенти виграють від найсильнішої моделі, яку ви можете собі дозволити, для планування й вибору інструментів; підзадачі можна маршрутизувати на дешевші моделі.

Джерела

Anthropic (2024). Building effective agents.
Yao et al. (2022). ReAct: Synergizing Reasoning and Acting in Language Models.
Schick et al. (2023). Toolformer: Language Models Can Teach Themselves to Use Tools.
Anthropic. Tool use with Claude.
OpenAI. A practical guide to building agents.