Коротко: агент працює циклом із чотирьох фаз — оцінити стан, обрати інструмент, отримати результат, вирішити наступний крок. Модель у цій схемі не має доступу до даних: вона бачить лише описи доступних операцій і те, що ці операції повернули. Уся безпека будується саме на цій межі.
Цикл: чотири фази
Кожен крок агента — це один прохід циклу. Кроків може бути два, а може бути двадцять; кількість наперед невідома й залежить від даних.
- Оцінка стану. Агент має мету, історію попередніх кроків і перелік доступних інструментів. На підставі цього він визначає, чи мета досягнута.
- Вибір інструмента. Якщо не досягнута, агент обирає операцію з переліку й формує параметри до неї. Наприклад: «отримати прострочені рахунки» з порогом і датою.
- Виконання. Шар інтеграції перевіряє параметри, автентифікується в Business Central і виконує запит. Business Central застосовує дозволи облікового запису й повертає результат або відмову.
- Інтерпретація. Агент бачить, що повернулося, додає це до історії й повертається до фази 1.
Найважливіше в цій схемі — фаза 3. Модель не виконує запит сама: вона лише формує намір. Виконує шар інтеграції, і саме він вирішує, чи такий виклик взагалі допустимий. Це не деталь реалізації, а основа всієї моделі безпеки.
Що агент бачить замість бази
Поширена помилка — уявляти, що агенту «дали доступ до ERP». Насправді він отримує щось значно вужче: перелік описаних операцій із визначеними параметрами.
Один інструмент виглядає приблизно так: назва — «отримати прострочену заборгованість»; опис — що саме він повертає й коли ним варто користуватися; параметри — мінімальна сума, кількість днів прострочення, код компанії. Усе. Агент не може попросити «виконати довільний запит», бо такої операції в переліку немає.
Це має два наслідки, які варто розуміти до початку проєкту.
Перший: можливості агента дорівнюють переліку інструментів. Хочете, щоб він умів щось нове, — треба зробити нову операцію. Це не недолік, а те, що робить систему передбачуваною й придатною до перевірки: перелік можна роздрукувати й прочитати.
Другий: якість описів впливає на поведінку. Погано описаний інструмент викликається не вчасно або з невдалими параметрами. Це проблема коректності, а не безпеки, але вона реальна й на неї йде помітна частина роботи з налагодження.
Наскрізний приклад
Мета: «підготуй нагадування по клієнтах із простроченням понад 30 днів і сумою понад €5 000, крім тих, у кого є відкрита претензія».
| Крок | Що робить агент | Що повертається |
|---|---|---|
| 1 | Викликає «отримати прострочену заборгованість» з порогами | 14 клієнтів, 31 документ |
| 2 | Для кожного клієнта викликає «перевірити відкриті претензії» | У двох є претензії |
| 3 | Виключає цих двох, лишається 12 | — |
| 4 | Викликає «отримати відкриті замовлення» по 12 клієнтах | У п'яти є замовлення |
| 5 | Групує документи по клієнтах, формує тексти | 12 чернеток |
| 6 | Позначає п'ятьох як таких, де варто притримати відвантаження | — |
| 7 | Зупиняється: далі за правилами вирішує людина | Результат на перегляд |
Зверніть увагу на крок 2. Агент не знав наперед, скільки буде клієнтів, тому й кількість викликів визначилася під час виконання. Саме це відрізняє його від потоку Power Automate, де послідовність задана заздалегідь.
І зверніть увагу на крок 7. Зупинка тут не тому, що агент «вирішив бути обережним», а тому, що операції «надіслати нагадування» в його переліку інструментів просто немає.
Пам'ять і стан
Усередині одного завдання агент тримає історію кроків: що викликав, що отримав, що з цього вже враховано. Це його робоча пам'ять, і вона обмежена — при довгих ланцюжках ранні кроки доводиться згортати в стислий вигляд.
Практичний наслідок: дуже довгі завдання менш надійні за серію коротких. Агент, який обробляє двісті клієнтів в одному проході, поводиться гірше за агента, якого запускають двісті разів по одному клієнту. Це впливає на те, як проєктують сценарій, і це одна з причин, чому широкий перший обсяг — погана ідея.
Між запусками агент за замовчуванням не пам'ятає нічого. Якщо потрібно, щоб він знав про попередні дії — скажімо, не надсилати нагадування двічі за тиждень, — цю пам'ять треба зробити явно: або записом у Business Central, або окремим сховищем стану. Це проєктне рішення, а не властивість моделі.
Коли агент зупиняється
Чотири нормальні причини зупинки, і всі чотири мають бути передбачені явно:
- Мета досягнута — результат готовий.
- Досягнуто точки, де вирішує людина — за проєктом процесу.
- Потрібної операції немає в переліку — агент повідомляє, що не може продовжити.
- Вичерпано ліміт кроків — запобіжник від нескінченного циклу.
Останній пункт обов'язковий. Агент, який не може досягти мети, здатен крутитися, пробуючи варіації того самого виклику. Ліміт кроків перетворює цю ситуацію з проблеми на подію в журналі.
Що відбувається при помилці
Тут проходить межа між системою, придатною до продуктиву, і демонстрацією.
Відмова через дозволи. Business Central повертає відмову, агент її бачить і має повідомити, що операція недоступна. Правильна поведінка — сказати про це, а не спробувати обхідний шлях.
Порожній результат. Найнебезпечніший випадок. Запит виконався, але нічого не повернув. Агент має розрізняти «даних немає» і «щось пішло не так», і в жодному разі не заповнювати пропуск правдоподібним припущенням. Це перевіряють окремим тестуванням, а не сподіваються.
Часткова невдача. З дванадцяти клієнтів по трьох виклик не вдався. Агент має завершити роботу по дев'яти й окремо повідомити про три, а не зупинятися повністю й не робити вигляд, що клієнтів було дев'ять.
Перевищення лімітів запитів. Хмарний Business Central обмежує інтенсивність звернень. Агент, який робить сотні дрібних викликів, впирається в це. Лікується проєктуванням операцій: одна, що повертає потрібне, замість двадцяти по шматку.
За чим стежити в продуктиві
Мінімальний набір метрик, який варто мати з першого дня:
- Скільки кроків у середньому займає завдання — різке зростання означає, що агент почав блукати.
- Частка завдань, що завершилися лімітом кроків.
- Частка відмов через дозволи — якщо вона не нульова, або перелік інструментів ширший за права, або хтось намагається використати агента не за призначенням.
- Скільки підготовлених результатів людина відхиляє. Це головна метрика якості: якщо відхиляють половину, агент створює роботу, а не знімає її.
Остання метрика важливіша за всі технічні. Агент, який працює бездоганно з погляду логів і чиї результати щоразу переробляють, — це невдалий проєкт із хорошим моніторингом.
Часті запитання
Чи має модель прямий доступ до нашої бази?
Ні. Модель формує намір викликати операцію, а виконує його шар інтеграції — він перевіряє параметри, автентифікується й звертається до Business Central, який застосовує дозволи облікового запису. Модель бачить лише те, що повернулося.
Скільки кроків робить агент за одне завдання?
Наперед невідомо: кількість залежить від даних. Типове вузьке завдання — від трьох до п'ятнадцяти кроків. Ліміт кроків задають обов'язково, інакше агент, який не може досягти мети, здатен крутитися, пробуючи варіації того самого виклику.
Чи пам'ятає агент попередні запуски?
За замовчуванням ні. Якщо потрібно, щоб він не повторював дії — наприклад, не надсилав нагадування двічі, — пам'ять роблять явно: записом у Business Central або окремим сховищем стану. Це проєктне рішення.
Що буде, якщо запит поверне порожній результат?
Правильно спроєктований агент розрізняє «даних немає» і «сталася помилка» й повідомляє про обидва випадки. Заповнення пропуску правдоподібним припущенням — найнебезпечніша поведінка у фінансовому контексті, і її перевіряють окремим тестуванням.
Чому довгі завдання менш надійні?
Робоча пам'ять агента обмежена. При довгих ланцюжках ранні кроки згортаються в стислий вигляд, і частина деталей втрачається. Серія коротких запусків працює стабільніше за один прохід по двохстах записах.
Як зрозуміти, що агент працює добре?
Головна метрика — скільки підготовлених ним результатів людина відхиляє. Якщо половину, агент створює роботу, а не знімає її, і технічні логи цього не покажуть.