Vai al contenuto
kenjtecJournal
Cerca nel Journal

Quando l’agente IA si blocca: durable-harness di Vercel riparte dallo stato del lavoro

Riprendere è più di una chat salvata. Il nostro esempio di esportazione spiega i checkpoint, gli effetti collaterali incerti e il punto in cui la ripetizione sicura raggiunge il suo limite.

Tobias aspetta con una busta; tra una cassa e la busta c’è un piccolo cancello aperto con una bandierina rossa. Illustrazione creata con l’IA.

Un agente scrive un report, crea un file e poi invia un messaggio. A quel punto il processo si interrompe. Al riavvio, la chat dice: “Sto inviando il risultato adesso.” Il messaggio è partito? Il file va creato di nuovo? Una cronologia della conversazione fluida non risponde a queste domande.

Il 19 ottobre 2026 Vercel ha pubblicato durable-harness. Il progetto registra i passaggi e i risultati dell’agente in modo che il lavoro possa essere ripreso, e tratta gli strumenti interrotti in modo diverso a seconda della loro proprietà di ripetibilità. Il rilascio è un’occasione per riflettere con più attenzione sullo stato del lavoro. L’esempio di questo articolo è un nostro modello, non un test che abbiamo eseguito sul progetto.

Intenzione, chiamata e risultato sono tre cose diverse

Un’intenzione descrive ciò che dovrebbe accadere dopo. Una chiamata avviata mostra che il lavoro è cominciato. Solo un risultato salvato documenta ciò che il tuo processo ne sa. Se questi livelli si confondono, un riavvio può facilmente produrre lavoro duplicato o saltare qualcosa che non è mai stato completato.

Per il report, quindi, la voce “Esportazione completata” non basta. Serve un riferimento all’input utilizzato e al file effettivamente creato. Se il documento di origine cambia, un’esportazione precedente può esistere ancora ma non essere più il risultato corretto. Il riutilizzo comincia con un’attribuzione chiara.

Step: export-17
Input: bericht-v3
State: completed
Result: bericht-v3.pdf
Next step: notification

Questa è una scheda di controllo leggibile, non un formato API. Mostra la differenza essenziale tra un nome di file citato in una conversazione e un risultato tracciabile di un passaggio specifico. In un processo reale, il file corrispondente dovrebbe esistere in modo verificabile.

Un riavvio sicuro conosce gli stati incerti

Considera tre punti in cui il processo potrebbe interrompersi. Prima dell’esportazione, non esiste ancora alcun risultato. Dopo l’esportazione ma prima del messaggio, il file può essere riutilizzato. Mentre il messaggio viene inviato, la situazione è più difficile: il destinatario potrebbe averlo già ricevuto mentre la conferma manca dal tuo log.

Lo stato locale “nessuna conferma salvata” quindi non dimostra “non inviato”. Ripetere ciecamente il passaggio potrebbe trasformare l’incertezza in un messaggio duplicato. Un processo sensato contrassegna questo passaggio come incerto e verifica presso il servizio esterno, a condizione che il servizio offra un’adeguata interrogazione dello stato.

È proprio qui che le azioni si differenziano. Rileggere un file esistente normalmente non cambia nulla per il destinatario. Un altro messaggio, ordine o pagamento, invece, può innescare un nuovo effetto. Un log durevole non risolve queste differenze al posto del sistema esterno.

L’idempotenza è una proprietà dell’operazione

Un’operazione ripetibile dovrebbe essere identificabile in modo tale che la stessa richiesta non crei accidentalmente un nuovo job. Se un servizio supporta una chiave pensata per questo scopo, la stessa operazione logica deve mantenere la stessa chiave. Una chiave generata da capo a ogni riavvio perderebbe proprio questa relazione.

Se e come questo funzioni in modo affidabile dipende dal contratto effettivo del servizio. Un framework per agenti non può rendere un’azione ripetibile in sicurezza solo assegnandole un’etichetta rassicurante. Né l’“esattamente una volta” è una conseguenza gratuita del fatto che i log vengano salvati in modo durevole.

Un piccolo test di interruzione spiega più di un’esecuzione riuscita

Nel tuo ambiente di sviluppo si presta un esercizio innocuo: per prima cosa sostituisci il passaggio di invio con un log locale, interrompi il processo nei tre punti menzionati e osserva quali stati esistono al riavvio. Annota in anticipo quali passaggi possono essere ripetuti e quali richiedono una verifica. Non usare pagamenti o messaggi reali per questa prima indagine.

L’intuizione non sta in un tasso di successo inventato. Sta nel saper indicare i confini di stato nel tuo processo. Durable-harness è un approccio tecnico concreto in questa direzione. Un buon riavvio, però, comincia sempre con la stessa domanda: che cosa è dimostrabilmente accaduto, e dove ancora non lo sappiamo?

Fonti e stato

Ricerca e documentazione aggiornate al 25 ottobre 2026. Rendere durevole ogni harness.

Amburgo è il nostro punto di partenza.

L’utilità viaggia con te.

IA pratica da Amburgo, spiegata per tutti.

Articoli salvati