Recupero dagli errori negli agenti IA: quando riprendere, annullare o fermarsi

Il fallimento di una chiamata non equivale al fallimento dell’attività

Un agente potrebbe dover consultare informazioni, modificare un record e poi comunicare il risultato. Se la risposta di uno strumento non arriva nel mezzo di questo flusso, non basta decidere se ripetere l’ultima chiamata. È possibile che l’azione non sia mai arrivata al sistema esterno; che sia stata eseguita, ma che la conferma sia andata persa; oppure che la modifica sia stata applicata solo in parte. Ogni caso richiede una decisione diversa.

In questa guida, recuperarsi significa riallineare l’obiettivo e l’avanzamento registrati dall’agente con lo stato verificabile dell’ambiente, quindi scegliere se proseguire in sicurezza o fermarsi in modo esplicito. L’unità di analisi è un’attività composta da più passaggi, non una singola richiesta. Ripetere una chiamata può rientrare nel recupero, ma non lo definisce.

La raccomandazione centrale è semplice: prima di ripetere un’azione dal risultato incerto, verifica che cosa è successo al di fuori dell’agente. Se non esiste un modo affidabile per accertarlo, non trasformare l’incertezza in una seconda modifica. Limita le azioni successive e inoltra il caso a una persona quando il costo di un errore è superiore a quello dell’attesa.

Mappa degli errori: per prima cosa, classifica ciò che sai

Un errore esplicito non dimostra sempre che il sistema esterno sia rimasto invariato. Allo stesso modo, un timeout indica soltanto che l’agente non ha ricevuto una risposta in tempo; da solo non dimostra se l’operazione sia stata completata. Per questo, classifica l’episodio in base alle prove disponibili, non all’etichetta dell’errore ricevuto dall’agente.

Distingui cinque situazioni. In caso di errore confermato, la risposta consente di concludere che l’azione non è stata eseguita. In caso di esito ambiguo, la richiesta potrebbe essere arrivata, ma non c’è una conferma affidabile. In caso di risposta non valida, esiste una risposta, ma il formato o il contenuto non consentono di usarla in sicurezza. In caso di stato esterno inatteso, il sistema comunica qualcosa che non coincide con le ipotesi del piano. In caso di interruzione tra passaggi, l’attività si è arrestata dopo uno o più effetti confermati, ma prima che il flusso fosse completato.

Queste categorie orientano la verifica successiva, ma non determinano una risposta automatica. Se l’errore è confermato e l’operazione può essere ripetuta in sicurezza, un nuovo tentativo potrebbe essere ragionevole. Se l’esito è ambiguo, cerca prima prove nel sistema interessato. Se la risposta non è valida o lo stato osservato contraddice il piano, sospendi le azioni dipendenti finché la discrepanza non è chiarita.

Prima di proseguire: conserva ciò che serve per ricostruire l’attività

Un checkpoint, o punto di controllo, è utile se permette di ricostruire che cosa l’agente intendeva fare e che cosa sa di ciascun passaggio. Non è necessario salvare tutto il ragionamento o ogni dato disponibile. È opportuno conservare le informazioni operative essenziali: identificativo dell’attività, obiettivo, vincoli rilevanti, ordine dei passaggi, strumento e operazione richiesti, parametri necessari a identificare l’operazione, risultato ricevuto, stato della conferma e ultima osservazione dell’ambiente.

Registra ciascun passaggio con una condizione esplicita, per esempio: in sospeso, richiesto, confermato, fallito con prove oppure esito sconosciuto. Evita di condensare questi stati in una nota unica come «azione completata», perché potrebbe cancellare la distinzione tra intenzione e conferma. Se il sistema esterno offre un modo per consultare l’oggetto modificato, conserva la chiave necessaria a trovarlo e annota quando è stato osservato l’ultima volta.

Il checkpoint non dimostra che il mondo esterno sia ancora nello stesso stato. È un’istantanea di ciò che il processo ha salvato; tra l’interruzione e la ripresa, un’altra persona o un altro sistema potrebbe aver modificato il record. Quando ripristini il checkpoint, convalida di nuovo le condizioni necessarie prima di apportare altre modifiche. La documentazione Microsoft sui checkpoint dei workflow descrive il salvataggio e il ripristino dei checkpoint; in un’implementazione specifica, il team deve verificare quale stato viene conservato e in che modo viene ricostituito.

La progettazione deve preservare anche i limiti dell’attività: quale risultato conta come successo, quali operazioni non devono essere ripetute e quali condizioni impongono un’escalation. Senza questi limiti, un agente può ricostruire i passaggi tecnici e tuttavia proseguire in una direzione che non è più sicura.

Albero decisionale: riprendere, verificare, riformulare, compensare o fermarsi

La decisione può essere espressa come un breve processo. Per prima cosa, individua l’ultimo passaggio confermato e il primo il cui esito è incerto. Poi chiediti se esiste una consultazione affidabile che riveli lo stato esterno. Se sì, consulta il sistema prima di agire. Se no, valuta l’impatto potenziale di una ripetizione e l’esistenza di un modo sicuro per risolvere l’incertezza. Se non esiste nemmeno quello, fermati e chiedi l’intervento di una persona.

Riprendere significa continuare da un punto noto, senza eseguire di nuovo i passaggi già confermati. È appropriato quando lo stato salvato è sufficiente, le condizioni rilevanti sono ancora valide e i passaggi in sospeso sono sicuri. Verificare significa consultare l’ambiente per capire che cosa è successo, non inviare di nuovo lo stesso comando. Riformulare significa cambiare piano perché lo stato attuale non soddisfa più le ipotesi iniziali. Compensare significa eseguire un’azione diversa per controbilanciare un effetto precedente. Fermarsi significa non apportare altre modifiche finché non si ottiene una decisione o una prova sufficiente.

La guida AWS sui checkpoint per i sistemi agentici avverte che riprendere senza garanzie di idempotenza può duplicare gli effetti o corrompere i dati. Questa avvertenza sottolinea una distinzione pratica: salvare lo stato dell’esecuzione aiuta a ricostruire il flusso, ma non rende automaticamente sicura la ripetizione di un’operazione.

Effetti parziali: annullare non significa sempre tornare allo stato precedente

In un’attività composta, alcuni passaggi potrebbero essere completati prima che quello successivo fallisca. Se l’agente aggiorna un record e poi non riesce a inviare una notifica, ripetere l’intero flusso potrebbe applicare di nuovo la modifica, creare record duplicati o inviare messaggi ripetuti. Il recupero deve partire dagli effetti confermati e decidere separatamente che cosa fare con ciascuno di essi.

Quando un’operazione è reversibile, definisci in anticipo che cosa significa annullarla e come verificare che l’annullamento abbia avuto effetto. Non presumere che «annullare» elimini ogni traccia o che il sistema consenta di ripristinare esattamente lo stato precedente. In alcuni processi, la risposta appropriata è un’azione compensativa: per esempio, correggere un record con una nuova operazione invece di cancellare la cronologia dell’operazione. Anche la compensazione può fallire e richiede quindi una conferma e limiti propri.

Il modello saga, descritto da AWS per flussi composti da più passaggi, distingue il recupero in avanti — proseguire o riprovare — dal recupero all’indietro, realizzato tramite transazioni compensative. È un riferimento utile per strutturare processi distribuiti, ma non implica che ogni effetto di un agente disponga di una compensazione disponibile o sicura. La scelta dipende dalle regole del sistema e dall’impatto dell’azione.

Se un’azione non può essere annullata in modo affidabile, l’agente deve trattarla come un limite di rischio. Può registrare l’effetto, impedire altri passaggi che lo aggraverebbero e chiedere una revisione. Non dovrebbe improvvisare una compensazione che non è stata definita per quel caso.

Limiti ed escalation: segnali che indicano di fermare l’agente

Una politica di recupero ha bisogno di condizioni di arresto esplicite. Tra i segnali pratici figurano: impossibilità di consultare lo stato che determina se un’azione sia avvenuta; osservazione di modifiche incompatibili con il piano; risposte non valide ripetute; accumulo di tentativi senza progressi confermati; superamento dell’impatto o dell’ambito autorizzati; oppure mancanza di una compensazione affidabile per un effetto indesiderato. Sono criteri di progettazione proposti, non garanzie automatiche di sicurezza.

Definisci anche chi riceve il caso, quali informazioni gli servono e quali azioni può autorizzare. Un’escalation utile dovrebbe includere l’obiettivo dell’attività, i passaggi confermati, il punto incerto, le verifiche effettuate, gli effetti esterni osservati e l’opzione che l’agente avrebbe scelto. Evita di presentare come fatto una causa che non è stato possibile determinare.

Fermarsi non deve significare abbandonare l’attività senza avviso. L’agente può conservare il checkpoint, contrassegnare l’attività come bloccata e comunicare chiaramente che cosa resta da verificare. Se l’interfaccia offre un’opzione per riprendere, questa deve ricontrollare le condizioni pertinenti, non presumere che l’ambiente sia rimasto invariato.

Verifica il recupero con interruzioni controllate

Non basta testare il percorso senza errori o controllare che il processo possa ripristinare un checkpoint. Simula interruzioni in punti diversi: prima di inviare un’operazione, dopo averla inviata ma prima di ricevere una risposta, dopo la conferma di un effetto e prima del passaggio successivo, e dopo aver osservato una modifica inattesa. Aggiungi risposte tardive, non valide o duplicate se possono verificarsi nell’ambiente valutato.

Per ogni scenario, definisci in anticipo il comportamento atteso: che cosa deve essere conservato, quale verifica va effettuata, quando è sicuro riprendere e quale condizione impone un’escalation. Poi confronta il risultato effettivo con quel criterio. La valutazione deve considerare sia gli errori dovuti a un eccesso di iniziativa — per esempio, un duplicato — sia quelli dovuti a un’eccessiva cautela — per esempio, un’attività interrotta che si sarebbe potuta riprendere in sicurezza.

Come metriche di monitoraggio, valuta la quota di attività completate correttamente, gli effetti duplicati, gli stati incoerenti, le attività bloccate, il tempo necessario a risolvere un’ambiguità e la quota di escalation appropriate. Interpreta le metriche tenendo conto della gravità di ciascun caso: un basso tasso di duplicati non dimostra che un’operazione irreversibile sia sicura.

Usa i risultati per modificare checkpoint, verifiche, limiti ai tentativi e condizioni di arresto. Quando le prove lo consentono, tieni distinti gli errori dell’agente, dello strumento e del sistema esterno; quando non è possibile distinguerli, registra la causa come indeterminata invece di attribuirla arbitrariamente.

Che cosa non risolve questa guida

Questa guida riguarda il recupero di un’attività agentica che attraversa più passaggi e può modificare sistemi esterni. Non sostituisce la progettazione dei nuovi tentativi di un’API, le garanzie di idempotenza di una specifica richiesta né il recupero dell’infrastruttura. Questi aspetti restano importanti: un protocollo a livello di attività può basarsi su di essi, ma non può dedurne le garanzie se non sono documentate.

Qui l’idempotenza è una proprietà da verificare per la specifica operazione prima di presumere che sia sicuro ripeterla; non basta etichettare come idempotente l’intera attività. Allo stesso modo, un checkpoint consente di conservare e ripristinare informazioni sul workflow, ma non conferma da solo che il sistema esterno abbia applicato una modifica. La tesi sull’architettura multiagente tollerante ai guasti è un precedente con un ambito diverso: studia il controllo di un robot mobile e non costituisce una ricetta diretta per agenti collegati a servizi aziendali.

Come criterio pratico conclusivo, chiediti nell’ordine: che cosa è confermato? Che cosa si può verificare al di fuori dell’agente? Quali effetti si sono già verificati? Quali passaggi sono ancora validi? Esiste una compensazione sicura? Quale condizione impone di fermarsi? Se una risposta essenziale è sconosciuta e agire potrebbe aggravare l’esito, conserva lo stato, fermati e inoltra il caso.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.