Come impedire agli agenti AI di bloccarsi in loop infiniti su task lunghi

Chiunque abbia provato ad assegnare a un agente AI un task che va oltre il refactoring locale di una singola funzione conosce questo problema. I primi 15 minuti vanno benissimo. Dopo la seconda ora, l'agente inizia a riscrivere il proprio codice per la terza volta, perde il contesto, brucia token, e finisce per bloccarsi. Le sessioni di chat normali e i timer semplici non aiutano in questo caso.

Lo sviluppatore huangruiteng ha pubblicato su GitHub un progetto chiamato LoopX — un piano di controllo locale per agenti AI a lunga esecuzione. Il progetto non cerca di sostituire il motore sottostante come Claude Code, Codex CLI o Cursor. Invece, si occupa di gestione dello stato, limiti e punti decisionali.

Perché è necessario un livello di controllo separato

Quando un task si estende per giorni o settimane, i requisiti cambiano, i risultati della verifica diventano obsoleti e gli agenti devono passarsi il lavoro l'un l'altro. In una situazione del genere, la memoria della chat standard si trasforma rapidamente in caos.

LoopX propone di trattare il lavoro degli agenti come una bacheca Kanban. Le card memorizzano il contesto, i diritti di accesso, le evidenze raccolte e le istruzioni di continuazione.

objective / issue / project
   │
   ▼
LoopX state: objective + gates + todos + scope + evidence + quota
   │
   ├─ нужен человек? ─────────▶ задать точечный вопрос и ждать
   │
   ├─ есть безопасный фолбэк? ▶ запустить один ограниченный шаг
   │
   ▼
Codex / Claude Code / Cursor / shell исполняют один шаг
   │
   ▼
запись артефактов + передача + следующий todo ─▶ квота решает, когда следующий запуск

Nel sistema non esiste un agente principale. Gli esecutori registrati sono trattati come pari. Chi prende esattamente il prossimo passo viene deciso dalle richieste di task, dai timeout dei lease e dalle regole di trasferimento del ruolo.

Cosa c'è dentro e come funziona

Il core di LoopX è scritto in Python 3.11+ e non ha dipendenze runtime esterne — vengono usati solo moduli della libreria standard.

L'intero meccanismo è costruito attorno alla risposta di semplici domande:

• Qual è l'obiettivo corrente e il scope di autorità?
• Cosa esattamente deve essere fatto dopo, e chi è responsabile?
• Dove è richiesta una decisione umana diretta (user gate)?
• Quali fatti e risultati del lavoro sono cambiati dall'ultima esecuzione?
• Possiamo continuare il ciclo da una prospettiva di budget e quota?

Il progetto non dà all'agente piena autonomia quando esegue azioni pericolose. La pubblicazione del codice, la scrittura in produzione e la conferma finale dei risultati rimangono sempre a carico dell'essere umano.

Test su task reali

Il repository include diversi esempi di lavoro che coprono centinaia di ore di tempo reale trascorso. Non si tratta di spinning continuo della rete neurale, ma della durata totale del progetto con molte esecuzioni brevi, interlacciate e verifiche.

Il primo caso è la correzione di bug nel progetto open-source OpenViking. LoopX ha preservato il contesto del repository, la cronologia dei commit e i requisiti di revisione per 200 ore di lavoro sulla PR.

Il secondo caso è l'automazione di esperimenti ML. Ipotesi, risultati delle esecuzioni, ipotesi scartate e punti di stop sono stati tutti preservati in un singolo grafo decisionale.

Quick start

Avrai bisogno di Python 3.11, bash, curl e tar per eseguirlo. Clonare il repository tramite git non è necessario se non hai intenzione di modificare LoopX stesso.

L'installazione viene fatta con un singolo comando:

curl -fsSL https://raw.githubusercontent.com/huangruiteng/loopx/main/scripts/install-from-github.sh | bash
export PATH="$HOME/.local/bin:$PATH"
loopx doctor

Dopo di che, naviga nella cartella del tuo progetto e connetti l'ambiente:

cd /path/to/your-project
loopx connect
loopx status

Se il progetto è nuovo, puoi avviare un goal tramite l'helper interattivo:

loopx start-goal --guided --project . --goal-text "Опишите вашу долгосрочную задачу"

Lo strumento creerà una directory .loopx/ nella cartella del progetto. Questa, insieme a .local/ e .codex/goals/, dovrebbe essere aggiunta a .gitignore subito.

Sono fornite integrazioni pronte all'uso per connettersi con agenti popolari:

• Claude Code: viene installato un adapter speciale, dopo di che il comando /loopx <task> e il /loop standard diventano disponibili.
• Codex CLI: l'agente esegue il polling degli stati tramite loopx doctor ed esegue uno specifico /goal <task_body>.
• Script personalizzati: è sufficiente chiamare una sequenza di comandi CLI per i controlli di quota (loopx quota should-run), prendere un task (loopx todo claim) e aggiornare lo stato (loopx todo update).

Chi dovrebbe provarlo

LoopX è in una fase iniziale (versione 0.4.x), ma offre già un approccio funzionante al problema della conservazione del contesto.

Lo strumento è utile se:

• Esegui agenti su task di ricerca o benchmark che durano più giorni.
• Vuoi organizzare una catena di più agenti (ad esempio, uno scrive il codice, il secondo fa la review).
• Sei stanco di script auto-autonomi che prosciugano il tuo bilancio API in tentativi infiniti di correggere lo stesso test.

Se i tuoi task sono limitati alla generazione di piccole funzioni on-demand in chat, LoopX sarà eccessivo.