Dlaczego agenci AI potrzebują dowodów, zanim ponowią próbę

Jak zapobiec temu, by brak odpowiedzi doprowadził do powtórzenia działania

Agent obsługi upoważniony do zlecenia jednego zwrotu wysyła żądanie, ale traci połączenie. Nie otrzymuje potwierdzenia, że operacja się powiodła, i próbuje ponownie zlecić zwrot. Jeśli pierwotne żądanie zostało zrealizowane, ponowienie działania przez agenta może doprowadzić do drugiego zwrotu.

To wyłącznie hipotetyczna sytuacja. Przykład ilustruje problem, którego nie da się rozwiązać samą poprawą dokładności modelu. Jak powinien postąpić agent, jeśli nie może ustalić, czy jego wcześniejsze działanie zmieniło stan środowiska?

Unite.AI analizowało niezawodność agentów wykraczającą poza same modele. W takich dyskusjach kwestie odzyskiwania sprawności systemu zasługują na osobne zasady. Zanim agent ponownie podejmie działanie mogące mieć istotne konsekwencje, powinien potwierdzić, co się wydarzyło, albo mieć ważną gwarancję, że nie dojdzie do powielenia skutków.

Brak odpowiedzi nie dowodzi, że działanie się nie powiodło

Brak odpowiedzi nie dowodzi, że działanie się nie powiodło. Nie wskazuje, czy błąd wystąpił przed jego wykonaniem, czy działanie zakończyło się bez potwierdzenia, ani czy proces nadal trwa.

To częsty problem w systemach rozproszonych, opisywany przez Amazon. Amazon wyjaśnia, dlaczego mechanizmy ponawiania prób wymagają konkretnych zabezpieczeń przed powtarzaniem skutków ubocznych. Agenci wprowadzają do ścieżki odzyskiwania sprawności systemu nowy podmiot podejmujący decyzje. Mogą podejmować dodatkowe decyzje dotyczące sposobu postępowania po wystąpieniu błędów.

Decyzje te mogą zmieniać sposób prowadzenia działalności. Na przykład ponowienie próby zwrotu innej kwoty w dolarach to nie tylko kolejne wykonanie tego samego żądania. Podobnie wybór innej usługi płatniczej, gdy pierwsza przestała odpowiadać, nie jest po prostu kolejnym wykonaniem tego samego żądania.

Zespoły muszą odróżniać zgodę na wykonanie działania od zgody na odzyskiwanie sprawności po wystąpieniu niepewnego wyniku. Pierwotna zgoda nie oznacza, że bezpiecznie jest wykonać działanie ponownie.

Najnowsze badania pozwalają ocenić ryzyko

Preprint z września 2026 r. „Where Does Exactly-Once Live?” przedstawia benchmark LIMBO i opisuje testy obejmujące 25 930 epizodów na dziewięciu modelach. Symulowane usługi testowano pod kątem utraconych potwierdzeń, opóźnionego przetwarzania i zduplikowanych dostarczeń.

Spośród 1279 epizodów, w których w głównym teście autorów wystąpił powielony skutek, agenci zgłosili pomyślne zakończenie w 90% przypadków. Agent może więc zgłosić sukces nawet wtedy, gdy przetwarzanie przebiegło nieprawidłowo.

Wyniki te pochodzą z kontrolowanych testów porównawczych i nie pozwalają oszacować częstości błędów w środowisku produkcyjnym. Usługi były symulowane, a część analiz miała charakter eksploracyjny. Zespoły powinny osobno oceniać wyniki działań agentów i ich komunikaty o pomyślnym wykonaniu.

W artykule wyjaśniono również, dlaczego sprawdzenie bieżącego stanu może nie wystarczyć. Żądanie, które jest nadal przetwarzane, może zostać zrealizowane już po sprawdzeniu. Nawet pusty komunikat o stanie nie oznacza, że żądanie ostatecznie nie zostanie zrealizowane.

Ponowienia prób dotyczą tego samego zamiaru

Usługa odbierająca żądanie może rozpoznawać ponowne próby wykonania tej samej operacji za pomocą klucza idempotencji. Jeśli mechanizm ten jest prawidłowo obsługiwany, zapewnia, że ponowne próby nie wywołują dodatkowych skutków. Klucz idempotencji musi pozostać niezmienny przy wszystkich ponowieniach.

Dokumentacja API Stripe przedstawia przykłady zarówno mechanizmów, jak i ograniczeń kluczy idempotencji. W przypadku API v1 klucze można usunąć po upływie co najmniej 24 godzin. Ponowne użycie usuniętego klucza spowoduje utworzenie nowego żądania. Stripe sprawdza również, czy parametry podane przez żądającego są zgodne z parametrami pierwotnego żądania.

W praktyce idempotencję należy zapewniać w warstwie integracyjnej, a nie wyłącznie w treści promptu. Przed wysłaniem operacji należy zapisać zatwierdzoną operację. Trzeba zachować jej identyfikator, dokładne parametry, identyfikator referencyjny dostawcy, jeśli ma zastosowanie, oraz status operacji.

W przypadku zwrotu należy zapisać powiązanie zatwierdzenia z pierwotną transakcją oraz wszelkie zwrócone przez dostawcę identyfikatory zwrotu. Wyszukanie dowolnego zwrotu na tę samą kwotę jest słabszym dowodem, ponieważ dwa prawidłowe żądania mogą opiewać na tę samą kwotę. Między złożeniem żądania zwrotu a jego pojawieniem się w wynikach wyszukiwania może też upłynąć pewien czas. Pierwotne żądanie może nadal być przetwarzane.

Po ponownym uruchomieniu agenta lub procesu roboczego warstwa wykonawcza powinna zachować jego tożsamość. Powinna odrzucić zmodyfikowane żądanie przesłane jako ta sama operacja. Taka zmiana stanowi nowe działanie i zgodnie z zasadami przepływu pracy wymaga nowej decyzji o zatwierdzeniu.

Same opisy narzędzi nie wystarczą

Oprócz opisów narzędzi należy sprawdzić, czy umowa dotycząca usługi odbierającej żądanie przewiduje obsługę idempotencji. Przetestuj jej implementację, aby potwierdzić, jakie gwarancje są faktycznie spełniane.

Traktuj niepewność jako stan operacyjny

Rysunek 1. Proponowana ścieżka odzyskiwania sprawności w przypadku działań mogących mieć istotne konsekwencje. Każde ponowienie próby wymaga również aktualnego upoważnienia.

Potwierdzenie wykonania oznacza, że przepływ pracy odnotuje wynik i będzie kontynuowany bez ponownego wykonywania działania. Potwierdzenie niewykonania pozwala na kolejną próbę tylko wtedy, gdy nie oczekuje już na realizację żadne pierwotne żądanie, a upoważnienie nadal obowiązuje.

Nierozstrzygnięty wynik wymaga rozważenia wielu dodatkowych kwestii. Jeśli istnieje wiarygodna gwarancja dostawcy, że działanie nie przyniesie podwójnych skutków, można zezwolić na ponowienie pierwotnego żądania z użyciem tego samego klucza. W przeciwnym razie należy wstrzymać wykonywanie zapisów i wyjaśnić sytuację, sprawdzając status, kontaktując się z pomocą techniczną dostawcy lub zwracając się do upoważnionego operatora. Niejednoznaczny wynik sprawdzenia nie uzasadnia wystarczająco zezwolenia na kolejną próbę.

Wstrzymanie działania może być uzasadnione także wtedy, gdy dostawca dokumentuje graniczne czasy przetwarzania i udostępniania wyników. Bez takich informacji sam upływ czasu nie potwierdzi, że działanie nie zostało wykonane. Trzeba określić, kto odpowiada za nierozwiązane sprawy i kiedy osoby te muszą je sprawdzić.

Odzyskiwanie sprawności po awarii może wymagać innego procesu biznesowego

Jeśli zwrot środków zostanie zrealizowany, ale późniejsze powiadomienie klienta się nie powiedzie, ponowne uruchomienie całego przepływu pracy może spowodować ponowny zwrot. Odzyskiwanie sprawności powinno skupiać się na dokończeniu niewykonanego kroku, z zachowaniem dowodów wykonanych już działań.

Jeśli konieczne są działania naprawcze dotyczące wcześniej wykonanych czynności, Microsoft udostępnia wskazówki dotyczące transakcji kompensacyjnych. Każda aplikacja określa właściwy sposób kompensowania błędów. Kompensacja niekoniecznie przywróci stan początkowy, a sama kompensacja również może się nie powieść.

Ponadto anulowanie transakcji może skutkować naliczeniem opłaty. Sprostowanie wiadomości nie daje pewności, że nikt nie zobaczył jej wcześniejszej wersji. Dlatego wszelkie działania naprawcze muszą wyraźnie określać, czego agent może się cofnąć, co może zmienić i do czego może się zobowiązać. Decyzje wykraczające poza te ograniczenia należy przekazać osobie mającej odpowiednie uprawnienia.

Przed wdrożeniem przetestuj ponowną próbę

Wybierz jedno narzędzie, którego działanie może mieć istotne konsekwencje, i przeprowadź staranne testy odzyskiwania sprawności w środowisku testowym. Po pomyślnym wykonaniu działania odrzuć odpowiedź na pierwotne żądanie. Opóźnij wykonanie pierwszego żądania do czasu sprawdzenia statusu. Podczas odzyskiwania sprawności uruchom ponownie proces roboczy. Przed ponowną próbą zaczekaj, aż upłynie okres przechowywania klucza. Przy kolejnych próbach zmień jeden parametr.

Oceniaj powstałe zapisy biznesowe, zamiast polegać wyłącznie na odpowiedziach narzędzi. Odnotowuj podwójne skutki, nierozstrzygnięte operacje, pominięte zadania, czas odzyskiwania sprawności i dodatkowe interwencje ręczne. Oblicz koszt poprawnie wykonanego zadania na podstawie łącznych kosztów przepływu pracy, w tym odwrócenia transakcji i środków zaradczych dla klientów.

Przetestuj również rzeczywiste, drugie żądanie podobne do pierwotnego. Upewnij się, że system nie tworzy duplikatów, a jednocześnie nie blokuje nowych zadań. Osobno oceń zapobieganie duplikatom i ostateczne ukończenie zadań. W przeciwnym razie agent, który przerywa każde zadanie, może sprawiać wrażenie bezpiecznego, choć nie przynosi niewielkiej wartości albo nie przynosi jej wcale.

Pytanie oceniające powinno być jasno sformułowane. Czy system potrafił wyjaśnić:

• Która operacja była autoryzowana?
• Jakie dowody potwierdzały jej wynik?
• Dlaczego kolejna próba była dozwolona?

Agent, który wstrzymuje działanie z powodu nierozstrzygniętej niepewności, może podczas demonstracji sprawiać wrażenie mniej skutecznego. Jednak w środowisku produkcyjnym wstrzymanie działania może pomóc zachować pierwotną intencję klienta. Przydatna wytrwałość oznacza, że system kończy autoryzowane zadania, nie wykonując ich po cichu wielokrotnie.