De ce agenții IA au nevoie de dovezi înainte să încerce din nou

Cum să împiedicăm transformarea unui răspuns pierdut într-o acțiune duplicată

Un agent de asistență autorizat să efectueze o singură rambursare trimite solicitarea, dar pierde conexiunea. Agentul nu primește nicio confirmare a reușitei și încearcă să trimită din nou solicitarea de rambursare. Dacă solicitarea inițială a fost procesată cu succes, acțiunea repetată a agentului poate duce la o a doua rambursare.

Acesta este un scenariu pur ipotetic. Exemplul ilustrează o problemă care nu poate fi rezolvată doar prin acuratețea modelului. Ce acțiuni ar trebui să întreprindă un agent dacă nu poate stabili dacă acțiunea sa anterioară a modificat starea mediului?

Unite.AI a analizat fiabilitatea agenților dincolo de modelele folosite. Problemele legate de recuperare merită reguli proprii în cadrul acestor discuții. Înainte de a repeta o acțiune cu consecințe, agentul ar trebui să confirme ce s-a întâmplat sau să beneficieze de o garanție validă împotriva efectelor duplicate.

Un răspuns care nu a fost returnat nu dovedește că acțiunea a eșuat

Faptul că nu a fost returnat niciun răspuns nu dovedește că o acțiune a eșuat. Nu indică dacă a apărut o eroare înainte de execuție, dacă acțiunea s-a încheiat fără confirmare sau dacă procesul este încă în desfășurare.

Aceasta este o problemă frecventă în sistemele distribuite, descrisă de Amazon. Amazon explică de ce mecanismele de reîncercare au nevoie de măsuri de protecție specifice împotriva efectelor secundare repetate. Agenții adaugă o nouă entitate decizională pe calea de recuperare a sistemului dumneavoastră. Ei pot lua decizii suplimentare cu privire la modul de recuperare în urma erorilor.

Aceste decizii pot schimba modul în care se desfășoară activitatea. De exemplu, reîncercarea unei rambursări cu o sumă diferită nu este doar o nouă repetare a aceleiași solicitări. În mod similar, alegerea unui al doilea serviciu de plată după ce primul nu a mai răspuns nu este pur și simplu o nouă repetare a aceleiași solicitări.

Echipele trebuie să facă distincția între acordarea permisiunii de a executa o acțiune și acordarea permisiunii de a gestiona un rezultat necunoscut. Aprobarea inițială nu înseamnă că este sigur să se execute din nou acțiunea.

Cercetări recente evaluează riscul

Un preprint din septembrie 2026, „Unde are loc execuția exact o singură dată?”, a introdus benchmarkul LIMBO și a testat 25.930 de episoade pe nouă modele. Serviciile simulate au fost testate în condiții de confirmări de primire pierdute, procesare întârziată și livrări duplicate.

Dintre cele 1.279 de episoade în care s-a produs un efect duplicat în testul principal al autorilor, agenții au raportat finalizarea cu succes în 90% dintre cazuri. Prin urmare, un agent poate raporta succesul chiar și atunci când procesarea s-a desfășurat incorect.

Aceste rezultate se bazează pe benchmarkuri controlate și nu estimează ratele de eșec din producție. Serviciile au fost simulate, iar mai multe analize au avut caracter exploratoriu. Echipele ar trebui să evalueze rezultatele acțiunilor agenților separat de rapoartele acestora privind executarea cu succes.

Lucrarea explică și de ce verificarea stării curente poate fi insuficientă. O solicitare aflată încă în curs de procesare poate produce efecte după verificare. Nici măcar un răspuns cu un câmp de stare gol nu înseamnă că solicitarea nu va produce efecte în cele din urmă.

Încercările repetate trebuie să corespundă aceleiași intenții

Un serviciu care primește solicitări dispune de o metodă de recunoaștere a încercărilor repetate de efectuare a unei operațiuni: cheia de idempotență. Dacă este implementată corespunzător, această metodă garantează că încercările repetate nu generează efecte suplimentare. Cheia de idempotență trebuie să rămână neschimbată la toate reîncercările.

Documentația API-ului Stripe oferă exemple atât privind mecanismele, cât și limitările cheilor de idempotență. Pentru API v1, cheile pot fi șterse după cel puțin 24 de ore. Utilizarea din nou a unei chei eliminate va genera o nouă solicitare. Stripe verifică, de asemenea, dacă parametrii furnizați de solicitant corespund celor din solicitarea inițială.

În practică, idempotența trebuie implementată în stratul de integrare, nu doar într-un prompt. Înainte de a trimite o operațiune, înregistrați operațiunea aprobată. Stocați identificatorul acesteia, parametrii exacți, referința furnizorului, dacă este cazul, și starea operațiunii.

În cazul unei rambursări, păstrați legătura dintre aprobare și tranzacția inițială, precum și orice identificatori ai rambursării returnați de furnizor. Căutarea oricărei rambursări cu aceeași sumă constituie o dovadă mai puțin convingătoare, deoarece două solicitări legitime pot avea aceeași sumă. De asemenea, poate exista o întârziere între solicitarea unei rambursări și apariția acesteia în rezultatele căutării. Solicitarea inițială ar putea fi încă în curs de procesare.

Când un agent sau un proces de execuție repornește, stratul de execuție ar trebui să păstreze identitatea respectivei operațiuni. Ar trebui să respingă o solicitare modificată, trimisă ca și cum ar fi aceeași operațiune. O astfel de modificare reprezintă o acțiune nouă, care necesită o nouă decizie de aprobare în conformitate cu regulile fluxului de lucru.

Descrierile instrumentelor nu sunt suficiente

Pe lângă descrierile instrumentelor, verificați contractul serviciului destinatar pentru a confirma dacă acceptă idempotența. Testați implementarea acestuia pentru a verifica ce garanții sunt oferite efectiv.

Tratați incertitudinea ca pe o stare operațională

Figura 1. O cale de recuperare propusă pentru acțiunile cu consecințe. Fiecare reîncercare necesită, de asemenea, o autorizare valabilă în acel moment.

Confirmarea finalizării înseamnă că fluxul de lucru va documenta rezultatul și va continua fără a repeta acțiunea. Confirmarea neexecutării permite o nouă încercare numai dacă nu există nicio solicitare inițială încă în așteptare și autorizarea este încă valabilă.

Un rezultat neclar impune luarea în considerare a multor altor aspecte. Dacă există o garanție validă, susținută de furnizor, că nu se vor produce efecte duplicate, puteți permite reîncercarea solicitării inițiale folosind aceeași cheie. În caz contrar, suspendați operațiunile de scriere și clarificați situația printr-o interogare de stare, apelând la asistența furnizorului sau la un operator autorizat. O verificare neconcludentă nu oferă motive suficiente pentru a autoriza o nouă încercare.

Suspendarea poate fi justificată și atunci când furnizorul documentează limitele de procesare și de vizibilitate. În lipsa acestor limite, simpla trecere a timpului nu va confirma că acțiunea nu a fost executată. Trebuie să stabiliți cine răspunde de cazurile care rămân nerezolvate și când trebuie persoanele respective să le revizuiască.

Revenirea după o eroare poate necesita un proces de afaceri diferit

Dacă rambursarea este efectuată cu succes, dar notificarea ulterioară a clientului eșuează, repetarea întregului flux de lucru ar putea duce la repetarea rambursării. Procesul de recuperare ar trebui să se concentreze pe finalizarea etapei rămase, păstrând totodată dovezile activităților deja încheiate.

Dacă sunt necesare acțiuni corective pentru acțiuni finalizate anterior, Microsoft oferă îndrumări privind tranzacțiile compensatorii. Fiecare aplicație stabilește modalitatea corectă de a compensa erorile. Este posibil ca măsurile compensatorii să nu readucă neapărat lucrurile la starea inițială, iar acestea pot eșua la rândul lor.

În plus, anularea unei tranzacții poate duce la perceperea unei taxe. Corectarea unui mesaj nu poate garanta că nimeni nu a văzut o versiune anterioară. Prin urmare, orice activitate de recuperare trebuie să limiteze explicit ceea ce agentul poate anula, modifica sau angaja. Deciziile care depășesc aceste limite trebuie înaintate unei persoane care deține autoritatea necesară.

Testați a doua încercare înainte de implementare

Alegeți un instrument cu consecințe semnificative și efectuați teste deliberate de recuperare într-un mediu de testare. După executarea cu succes, eliminați răspunsul la solicitarea inițială. Amânați executarea primei solicitări până după verificarea stării. În timpul recuperării, reporniți lucrătorul. Așteptați să expire perioada de păstrare a cheii înainte de a încerca din nou. Modificați un singur parametru în timpul încercărilor repetate.

Evaluați înregistrările de afaceri rezultate, în loc să vă bazați doar pe răspunsurile instrumentelor. Înregistrați efectele duplicate, operațiunile nerezolvate, activitățile omise, timpul de recuperare și intervențiile manuale suplimentare. Calculați costul fiecărei sarcini finalizate corect folosind costurile totale ale fluxului de lucru, inclusiv anulările tranzacțiilor și măsurile reparatorii pentru clienți.

În plus, testați o solicitare secundară reală, similară celei inițiale. Asigurați-vă că sistemul evită crearea de duplicate fără să împiedice activitățile noi. Evaluați separat prevenirea duplicatelor și finalizarea ulterioară a sarcinilor. În caz contrar, un agent care încheie toate sarcinile ar putea părea sigur, deși oferă puțină valoare sau nu oferă deloc.

Întrebarea de evaluare trebuie formulată clar. A putut sistemul să explice:

• Ce operațiune a fost autorizată?
• Ce dovezi existau pentru a demonstra rezultatul acesteia?
• De ce era permisă o nouă încercare?

Un agent care se oprește din cauza unei incertitudini nerezolvate poate părea mai puțin eficient în timpul demonstrațiilor. Totuși, în mediile de producție, suspendarea poate proteja intenția inițială a clientului. Persistența utilă presupune ca sistemul să finalizeze sarcinile autorizate fără să le execute pe ascuns de mai multe ori.