На складі однієї виробничої компанії замовлення на відсутні компоненти проходило через чотири системи та трьох співробітників. Кожен з них виконував схему: перевірка стану, оцінка порогу, внесення в ERP, відправка листа. Повторювана схема, жодних творчих рішень. Багатокроковий агент AI взяв на себе цей процес за шість тижнів пілоту. Не тому, що був «розумнішим» за команду, а тому, що вимагав точного проєктування циклу, а не готового SaaS-продукту.
У цьому й полягає суть багатокрокових агентів: немає магії, є архітектура.
Що відрізняє багатокрокового агента від простого чат-бота
Агент багатокроковий відрізняється від чат-бота трьома структурними властивостями, а не рівнем «інтелекту»:
Планування. Агент не відповідає на запитання — він генерує план кроків для досягнення мети. План може бути статичним (завжди ті самі кроки для певного типу завдань) або динамічним (модель сама вирішує про наступні кроки на основі результатів попередніх). Динамічне планування гнучкіше, але складніше для аудиту.
Діяльність через інструменти. Агент використовує інструменти (tool-use): читає з бази, записує запис, надсилає HTTP-запит, викликає функцію. Кожен інструмент — це визначений інтерфейс з обмеженим діапазоном. Агент, який має доступ лише до читання з CRM та запису до черги листів, не може випадково перезаписати дані клієнтів.
Цикл верифікації. Після кожного кроку агент перевіряє результат: чи API повернуло успіх, чи запис має очікуваний стан, чи наступний крок взагалі потрібен. Відсутність цього циклу — це агент, який «вистрілив» і припустив, що влучив. У виробничому середовищі це шлях до тихих помилок.
Архітектура циклу: плануй, дій, перевіряй
Більшість зрілих багатокрокових агентів реалізують варіант циклу ReAct (Reason + Act): модель генерує обґрунтування для наступного кроку, виконує його через інструмент, спостерігає результат і вирішує про наступний крок. Цикл триває до виконання кінцевої умови або досягнення ліміту кроків.
Ціль → План → [Крок → Верифікація → Рішення]* → Кінцевий результат
↕
Human-gate (для незворотних кроків)
Практичні наслідки цієї архітектури:
- Ліміт кроків є обов’язковим. Агент без ліміту може увійти в нескінченний цикл при неочікуваному результаті інструменту. Встановлюйте жорсткий ліміт (наприклад, 20 кроків для типових B2B-процесів) та обробляйте перевищення як ескалацію до людини.
- Проміжний стан має зберігатися. При тривалих завданнях (кілька хвилин) стан після кожного кроку потрапляє до сховища (Redis, база даних), а не лише в пам’ять сесії. Збій у середині процесу не повинен видаляти виконану роботу.
- Кожен крок має бути ідентифікованим. Лог містить: інструмент, вхідні аргументи, результат, timestamp. Це основа відповідності AI Act та аудитованості при DPIA.
Інструменти: як агент взаємодіє з бізнес-системами
Інструменти — це стандартизований інтерфейс між моделлю та зовнішніми системами. Кожен інструмент має: назву, опис (модель читає його при плануванні), схему вхідних даних та очікувану схему вихідних. Добре спроєктований інструмент є атомарним: робить одну річ, повертає чіткий результат успіху або помилки.
| Тип інструменту | Приклад | Ризик при поганому проєктуванні |
|---|---|---|
| Читання (read-only) | Отримати статус замовлення з ERP | Низький — відсутні побічні ефекти |
| Запис з верифікацією | Оновити поле статусу в CRM | Середній — потрібна валідація діапазону |
| Зовнішня дія | Надіслати лист / створити заявку | Високий — незворотні дії, вимагає human-gate |
| Інтеграція системи | Виклик API платежів / ERP | Високий — транзакції, вимагає ідемпотентності |
| Пошук знань | Запит до бази RAG / векторної БД | Низький — опосередкований вплив на якість відповідей |
Принцип мінімальних прав: агент отримує лише ті інструменти, які потрібні для конкретного завдання. Агент для обробки замовлень не потребує доступу до інструменту для надсилання комерційних пропозицій. Ізоляція — це питання як безпеки, так і якості планування: модель з меншим набором інструментів приймає точніші рішення.
Стандарт MCP (Model Context Protocol) стандартизує спосіб реєстрації інструментів та їх схем, що дозволяє повторно використовувати ті самі набори інструментів між агентами для різних завдань.
Guardrails та human-gate: де агент має зупинитися
#Guardrails — це умови, які перевіряються перед виконанням кожного кроку. Їх завдання — виявляти ситуації, коли агент збирається зробити щось поза межами дозволеного, потенційно шкідливе або незворотне.
Чотири рівні guardrails для багатокрокового агента:
- Валідація плану — чи кожен крок у згенерованому плані входить до дозволеного переліку інструментів? Крок, що посилається на інструмент поза allow-list, блокується перед виконанням.
- Валідація аргументів — чи аргументи, передані до інструменту, знаходяться в допустимому діапазоні? Агент, який намагається надіслати лист на адресу поза корпоративним доменом, отримує помилку і не продовжує.
- Human-gate для незворотних дій — видалення запису, надсилання зовнішнього повідомлення, підтвердження платежу. Агент зупиняється і чекає на явне підтвердження оператора. Підтвердження логується з timestamp та ідентифікатором користувача.
- Injection screening — вміст, отриманий із зовнішніх джерел (листи клієнтів, документи, форми), сканується перед передачею моделі. Prompt injection через вхідні дані — реальний вектор атаки для агентів з доступом до інструментів.
Human-gate — це не розкіш для «чутливих» процесів. Це архітектурна вимога для кожного агента з доступом до інструментів запису або дії. Детальний проєкт human-gate описано в статті про роль людини в циклі агента.
Обробка помилок та ескалація: коли агент не повинен продовжувати
Багатокроковий агент повинен мати чітко спроєктовану процедуру обробки помилок. Три сценарії вимагають окремих процедур:
Помилка інструменту (наприклад, timeout API, помилка 500). Агент повторює крок з backoff — максимум 2-3 спроби, потім ескалує до людської черги з повним логом стану. Не повторює нескінченно.
Неочікуваний результат — інструмент повернув щось, чого агент не може інтерпретувати в контексті плану (наприклад, поле статусу має значення поза очікуваним набором). Агент не вгадує — зупиняється і ескалує з контекстом: «На кроці 4 статус замовлення — X, план передбачав Y або Z».
Перевищення ліміту кроків — агент не знайшов шляху до мети в дозволеній кількості кроків. Ескалація з повним проміжним станом, щоб оператор міг прийняти рішення, а не починати з нуля.
Хороша ескалація — це не провал системи. Це спроєктований handoff до людини з контекстом, який скорочує час для прийняття рішення з хвилин до секунд.
Безпека даних та відповідність: PII, RODO та AI Act
#Багатокроковий агент обробляє дані, які часто містять PII. Кожен інструмент, який приймає або повертає персональні дані, проходить через маршрутизатор маскування перед передачею моделі. Модель ніколи не бачить сирого номера PESEL, номера рахунку чи електронної адреси — вона бачить токен-замінник. Дані розмасковуються лише при записі до цільової системи після верифікації інструментом.
Наслідки для проєктування:
- Лог кроку не містить PII. Він містить ідентифікатор сесії (анонімізований), ідентифікатор запису (наприклад, order_id), результат інструменту (успіх/помилка). Зміст обробленого документа не потрапляє до операційного логу.
- Self-hosting або data-residency. Для агентів, що обробляють персональні дані польських клієнтів, дані не повинні залишати ЄЕЗ без належної правової підстави. Власне LLM-інфраструктура усуває цю проблему. Варіанти описано в статті про локальні моделі LLM.
- AI Act та прозорість. Багатокроковий агент, що працює з клієнтами, повинен повідомляти, що клієнт має справу з автоматичною системою. Лог цього повідомлення входить до аудиторського сліду.
- DPIA при високому ризику. Агенти, що обробляють медичні, фінансові або кадрові дані (Додаток III AI Act), вимагають оцінки впливу на захист даних перед запуском у продакшн.
Впровадження безпечного багатокрокового агента з дотриманням цих вимог описано в статті AI Act та RODO 2026.
Впровадження крок за кроком: від пілоту до продакшну
Типовий графік впровадження багатокрокового агента для одного процесу в B2B-компанії виглядає так:
| Етап | Час | Що створюється |
|---|---|---|
| Вибір процесу та аудит даних | 1-2 тиж. | Перелік інструментів, схема кроків, інвентаризація PII |
| Пілот shadow mode | 2-3 тиж. | Агент працює паралельно з людиною, порівняння результатів |
| Пілот з human-gate | 2-4 тиж. | Агент виконує кроки, людина затверджує незворотні дії |
| Повна автономія в межах | від 6 тиж. | Моніторинг, golden set test, алерти ескалації |
Shadow mode — обов’язковий етап для кожного нового багатокрокового агента. Агент обробляє ті самі дані, що й людина, але його результат не застосовується — лише порівнюється. Розбіжності вказують на прогалини в проєктуванні інструментів або плануванні, перш ніж щось потрапить у продакшн.
Реальний бюджет пілоту залежить від складності процесу та кількості інтеграцій. Калькулятор орієнтовних витрат на проєкт AI можна знайти в калькуляторі ROI. Оцінку витрат на інференс (токени та інфраструктуру) надає калькулятор інференсу.
Спробуйте наживо
Опишіть процес, який хочете автоматизувати за допомогою агента, і модель спроєктує попередню архітектуру: кроки, інструменти, місця для human-gate та guardrails. (playground: PII маскуються, нульова ретенція):
FAQ
#Чим відрізняється багатокроковий агент від послідовності n8n?
#n8n — це оркестратор потоків, який добре підходить для відомих, сталих послідовностей кроків. Багатокроковий агент відрізняється тим, що план кроків генерує модель на основі мети та поточного стану. Для простого процесу з однаковими кроками n8n простіший і дешевший. Для процесу, що вимагає адаптації (різні шляхи залежно від результату кроку, обробка винятків), багатокроковий агент — правильний інструмент. На практиці часто поєднують обидва: n8n як зовнішній оркестратор, агент як модуль прийняття рішень для складних підзавдань.
Як довго може тривати одне завдання багатокрокового агента?
Залежить від кількості кроків та часу відповіді інструментів. Типові B2B-процеси (верифікація даних, підготовка документа, оновлення CRM) завершуються за 30 секунд до 3 хвилин. Процеси, що вимагають очікування зовнішньої події (відповідь клієнта, підтвердження платежу), можуть тривати години або дні — агент тоді зупиняється до появи сигналу, не блокує ресурси. Проміжний стан зберігається, агент відновлюється при події.
Чи може багатокроковий агент робити помилки, яких я не помічу?
Так, якщо немає циклу верифікації та моніторингу. Агент може виконати крок «технічно правильно» (API повернуло 200), але з помилковим бізнес-результатом (наприклад, статус встановлено на значення поза очікуваним діапазоном). Захист забезпечує комбінація: валідація схеми результатів кожного інструменту, golden set test щотижня та алерт на аномалії у вихідних даних. Архітектуру моніторингу описано в статті про моніторинг та KPI агента AI.
Коли багатокроковий агент не має сенсу?
Коли процес рідкісний (менше 20 повторень на місяць), вимагає глибокої експертної оцінки на кожному кроці або є високо нестандартизованим. Багатокроковий агент окупається там, де повторюваність висока, кроки можна визначити, а результат кроку можна верифікувати програмно. Для творчих або переговорних процесів краще підходить асистент, що підтримує людину, а не автономний агент. Оцінку відповідності процесу надає файндер автоматизації.
Як виглядає впровадження багатокрокового агента з Cashcrown?
#Починаємо з аудиту процесу та даних (інвентаризація інструментів, схема PII, опис кроків). Потім пілот shadow mode: агент працює паралельно з командою 2-3 тижні, розбіжності аналізуються. Далі етап з human-gate: агент автономний у безпечних кроках, для незворотних дій вимагає затвердження від оператора. Повна автономія лише після валідації показника помилок нижче порогу прийнятності. Зв’язок через контакт або оцінку готовності.