Come prevenire i loop fuori controllo (Parte 1)
Ti svegli, controlli la dashboard del fornitore di modelli e vedi migliaia di dollari in chiamate API dalla notte prima. Un loop. Ha continuato a girare mentre dormivi.
I sondaggi ai team di ingegneria mostrano che la maggior parte l'ha visto. Superamento medio intorno a 7.200$. Alcuni oltre 20.000$. Per startup in fase early, un singolo loop ne ha messe alcune fuori mercato.
La buona notizia: sono per lo più prevenibili. Questa guida spiega le cause e come fermarli.
Cos'è un loop fuori controllo?
Un loop fuori controllo è qualsiasi workflow autonomo che resta bloccato in un ciclo ripetitivo di chiamate API senza un'uscita integrata. Ogni ciclo genera più chiamate, più token, più costo. Essendo autonomo, può girare per ore o giorni.
Tipi comuni:
- Loop di retry – la chiamata allo strumento fallisce, l'agente riprova per sempre
- Loop di riavvio workflow – il workflow fallisce, l'agente riavvia da zero, ripete
- Loop di agenti annidati – l'agente primario genera un secondario, il secondario ne genera un altro, cascata
- Loop di allucinazione – il modello inventa una chiamata a strumento o richiesta e continua a cercare di soddisfarla
- Loop di overflow contesto – il contesto cresce ogni ciclo fino al limite, il workflow riavvia, ripete
Tutti bruciano il tuo budget senza fornire valore.
Perché avvengono
La maggior parte dei loop condivide la stessa causa: i team costruiscono solo per il percorso felice.
Passi la maggior parte del tempo a testare il caso in cui tutto funziona. L'utente invia una richiesta chiara, gli strumenti funzionano, il modello restituisce un buon output, il workflow si completa. Non dedichi abbastanza tempo ai casi limite: e se uno strumento fallisce? E se il modello restituisce spazzatura? E se l'API fa timeout? E se l'agente non può completare la richiesta?
I team aggiungono logica di retry ma non limiti rigidi, circuit breaker o condizioni di uscita. Assumono che il workflow alla fine avrà successo. Questa assunzione è come partono i loop.
Il loop da 10k$ del post precedente è avvenuto perché i retry erano limitati per chiamata ma non per workflow. Quando 10 retry fallivano, l'agente riavviava l'intero workflow. Nessuno aveva aggiunto quella protezione.
Passo 1: Limiti rigidi di retry a ogni livello
La logica di retry causa la maggior parte dei loop fuori controllo. I limiti rigidi li fermano.
La maggior parte dei team limita i retry solo per chiamata a strumento. Ti servono limiti a quattro livelli:
- Per chiamata a strumento: max 3 retry. Dopo 3 fallimenti, la chiamata fallisce e il workflow va alla gestione degli errori—niente più retry.
- Per azione: max 2 retry. Se l'agente non può completare l'azione dopo 2 tentativi, escalation a umano.
- Per workflow: max 1 riavvio. Se il workflow fallisce una volta, permetti un riavvio. Se fallisce di nuovo, stop.
- Globale: cap totale retry per ora o giorno. Raggiunto il cap, disabilita i retry per il resto del periodo.
Applica questi a livello infrastrutturale, prima che le chiamate arrivino al fornitore. Se sono solo nel codice dell'agente, un bug o risposta malformata possono bypassarli. ClawFirewall applica i limiti di retry al gateway API così nemmeno il codice dell'agente buggato può superarli.
Passo 2: Circuit breaker per ogni workflow
Un circuit breaker ferma un workflow quando supera una soglia. Quando scatta: workflow fermo, niente più chiamate API, escalation. Non riavviare finché qualcuno non ha verificato.
Imposta breaker per:
- Tasso di errore – es. >20% errori su 10 minuti
- Volume di retry – es. >10 retry in 5 minuti
- Uso di token – es. 2x media per una singola esecuzione
- Spend – es. 10x costo medio o 50% del budget giornaliero
- Volume di chiamate API – es. 5x chiamate medie per minuto
Anche se qualcosa bypassa i limiti di retry, un breaker può fermare il loop prima che bruci il budget. ClawFirewall include circuit breaker configurabili out of the box.