Чому ШІ-агентам потрібні докази, перш ніж повторювати дію

Як не допустити, щоб втрачена відповідь призвела до повторної дії

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

Це суто гіпотетична ситуація. Цей приклад ілюструє проблему, яку неможливо розв’язати лише завдяки точності моделі. Що має робити агент, якщо він не може визначити, чи змінила його попередня дія стан середовища?

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

Відсутність відповіді не означає, що дію не виконано

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

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

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

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

Нещодавнє дослідження оцінює ризик

Препринт за вересень 2026 року під назвою «Де реалізується принцип одноразового виконання?» представив тестовий набір LIMBO і перевірив 25 930 епізодів на дев’яти моделях. У симульованих сервісах випробовували втрату підтверджень, затримки обробки та дублювання доставлення.

У 90% із 1 279 епізодів, у яких у головному тесті авторів виник дубльований ефект, агенти повідомили про успішне виконання. Отже, агент може звітувати про успіх навіть тоді, коли обробка відбулася некоректно.

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

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

Повторні спроби мають стосуватися того самого наміру

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

Документація API Stripe містить приклади як можливостей, так і обмежень ключів ідемпотентності. Для API v1 ключі можна видаляти не раніше ніж через 24 години. Повторне використання видаленого ключа призведе до створення нового запиту. Stripe також перевіряє, чи збігаються параметри, надані ініціатором запиту, з параметрами початкового запиту.

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

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

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

Описів інструментів недостатньо

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

Вважайте невизначеність робочим станом

Рисунок 1. Запропонований механізм відновлення для дій, що можуть мати значні наслідки. Для кожної повторної спроби також потрібне чинне дозволення.

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

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

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

Для відновлення після збою може знадобитися інший бізнес-процес

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

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

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

Перевірте повторну спробу до розгортання

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

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

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

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

• Яку операцію було дозволено виконати?
• Які докази підтверджували її результат?
• Чому можна було зробити ще одну спробу?

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