Ingegneria del ciclo Claude Code: quattro modalità di automazione del lavoro oltre i prompt singoli
L’articolo illustra quattro modelli di loop di Claude Code: a turni, basati su obiettivi, pianificati e proattivi, con trigger, verifiche, permessi, budget e condizioni di arresto.
Ingegneria del ciclo Claude Code: quattro modalità di automazione del lavoro oltre i prompt singoli
Non dichiarare mai completata una modifica UI basandoti esclusivamente sul successo dell'editor.
- Avvia il server di sviluppo e apri la pagina modificata.
- Interagisci con il componente modificato per confermare lo stato previsto.
- Se necessario, acquisisci screenshot di confronto prima/dopo.
- Controlla la console del browser per eventuali nuovi errori o avvisi.
- Esegui un'analisi delle prestazioni e rivedi le metriche Core Web Vitals.
Se uno qualsiasi dei controlli fallisce, correggi il problema e riparti dal punto 1.
Il concetto chiave non riguarda la formulazione in sé, ma il fatto che questa abilità consente a Claude di ottenere le stesse prove a cui avrebbe accesso un revisore umano.
I controlli quantitativi sono particolarmente efficaci:
- Zero errori in console
- Tutti i test superati
- Punteggio Lighthouse sopra la soglia
- Nessuna differenza visiva al di fuori delle aree specificate
- Tempi di risposta inferiori al limite
- Completamento di un numero specifico di criteri di accettazione
Più il processo di verifica è quantificabile, minore sarà la frequenza degli interventi manuali.
2. Meccanismo a Ciclo Basato sugli Obiettivi (/goal)
Il ciclo basato sugli obiettivi è particolarmente utile quando un singolo tentativo potrebbe non essere sufficiente, ma è possibile descrivere chiaramente il punto di arrivo.
Claude Code non lascia che l'agente operativo decida da solo se il risultato è "abbastanza buono", ma utilizza un valutatore indipendente dopo ogni ciclo di operazioni.
Condizioni di Attivazione
L'utente avvia un obiettivo nella sessione corrente.
Condizioni di Arresto
Il ciclo termina quando:
- Il valutatore conferma che le condizioni sono soddisfatte, oppure
- Viene raggiunto il limite di tentativi configurato.
Scenari di Applicazione Ottimali
Il ciclo basato sugli obiettivi è adatto per attività con un risultato verificabile, come:
- Superare tutti i test di autenticazione
- Raggiungere un punteggio di prestazioni specifico
- Migrare tutti i punti di chiamata alla nuova API
- Svuotare la coda dei problemi contrassegnati
- Mantenere ogni file entro un intervallo di dimensioni preimpostato
- Completare tutti i criteri di accettazione nel documento di progettazione
Sintassi di Base
L'esempio ufficiale di Anthropic è il seguente:
/goal Portare il punteggio Lighthouse della homepage ad almeno 90, fermandosi dopo 5 tentativi.
Un altro esempio pratico:
/goal Tutti i test nella directory test/auth superati e il passaggio lint senza errori
Secondo l'attuale documentazione di Claude Code, il comando /goal richiede Claude Code versione 2.1.139 o successiva.
Come il Valutatore Modifica il Meccanismo del Ciclo
Dopo che Claude completa un ciclo di operazioni, un modello valutatore leggero e veloce verifica se la condizione è stata soddisfatta.
Se la condizione non è soddisfatta, inizia automaticamente un nuovo ciclo; se è soddisfatta, l'obiettivo corrente viene cancellato e il controllo della sessione viene restituito all'utente.
Questa separazione è importante perché il modello di lavoro non dovrebbe essere l'unico giudice del proprio output.
Una condizione di completamento efficace dovrebbe avere:
- Osservabilità
- Specificità
- Difficoltà di essere soddisfatta accidentalmente
- Correlazione con i risultati reali dell'utente o del sistema
- Un numero massimo di tentativi o altri limiti rigidi
Obiettivi Deboli vs Obiettivi Forti
Obiettivo debole:
/goal Migliorare la homepage
Il termine "migliorare" non definisce un punto finale misurabile.
Obiettivo forte:
/goal Aumentare il punteggio delle prestazioni Lighthouse su mobile ad almeno 90,
mantenendo l'accessibilità a 95 o superiore, e fermarsi dopo 5 tentativi
Obiettivo debole:
/goal Correggere i test
Obiettivo forte:
/goal Tutti i test nella directory test/payments superati, senza test saltati,
e il comando npm run lint esce con codice 0
Il modello non dovrebbe dover indovinare cosa significhi successo.
/goal Non Modifica le Autorizzazioni
L'obiettivo si estende su più turni, ma non approva automaticamente tutte le chiamate agli strumenti.
In modalità di autorizzazione predefinita, Claude potrebbe comunque mettere in pausa per confermare i comandi non ancora consentiti.
Per gli obiettivi non supervisionati, Anthropic consiglia di combinare /goal con la modalità automatica, quando disponibile e appropriato. Questo dovrebbe essere fatto dopo aver esaminato gli strumenti consentiti, i confini del repository e i potenziali effetti collaterali.
3. Cicli Basati sul Tempo: /loop e /schedule
Alcuni lavori non vengono attivati dal completamento del turno precedente, ma dal tempo.
Il compito rimane simile, ma l'input cambia:
- Arriva un nuovo messaggio Slack.
- Una richiesta pull riceve una recensione.
- Lo stato CI passa da superato a fallito.
- Viene rilasciata una nuova versione di una dipendenza.
- Il dashboard operativo segnala un nuovo incidente.
Condizioni di Attivazione
Ogni esecuzione viene avviata da un intervallo di tempo o una pianificazione configurata.
Condizioni di Arresto
Il ciclo locale si arresta quando si annulla, si chiude l'ambiente o il lavoro di monitoraggio viene completato.
Le routine cloud continuano a essere eseguite in base alla loro configurazione fino a quando non vengono messe in pausa o disabilitate.
Scenari di Utilizzo Ottimali
I cicli basati sul tempo sono adatti per:
- Monitoraggio delle richieste pull.
- Riepiloghi giornalieri o settimanali.
- Smistamento periodico dei problemi.
- Controlli delle dipendenze.
- Esecuzioni periodiche dei test.
- Controlli di deriva della documentazione.
- Sistemi di monitoraggio che non forniscono attivazione basata su eventi.
Ciclo a Intervallo Locale
L'esempio ufficiale usa /loop:
/loop 5m Controlla le mie richieste pull, gestisci i commenti di revisione e correggi i CI falliti
Questo prompt viene rieseguito all'intervallo configurato.
Il ciclo locale dipende dalla macchina e dalla sessione correnti. Se il computer viene spento o il processo si arresta, anche il ciclo si arresta.
Pianificazione Cloud
Per i lavori che devono continuare anche dopo aver chiuso il portatile, Claude Code può utilizzare /schedule per creare routine cloud.
Una routine attiva potrebbe iniziare in questo modo:
/schedule Ogni ora: Controlla i nuovi rapporti di bug in #project-feedback
Le routine di Claude Code vengono eseguite sull'infrastruttura cloud gestita da Anthropic e possono essere attivate da:
- Pianificazioni periodiche.
- Pianificazioni una tantum future.
- Chiamate API.
- Eventi GitHub supportati.
Al momento della scrittura, le routine sono in fase di anteprima di ricerca, quindi comportamento, limiti e interfaccia API potrebbero cambiare. La disponibilità dipende anche dal piano Claude pertinente, dalle policy organizzative e dall'abilitazione di Claude Code basato sul web.
Scegliere l'Intervallo con Attenzione
Un errore comune è eseguire cicli con una frequenza molto superiore al tasso di cambiamento del sistema esterno.
Se i nuovi problemi vengono segnalati solo poche volte al giorno, controllare la coda dei problemi ogni minuto non è utile. Ciò aumenta l'utilizzo dei token, le chiamate agli strumenti e —
senza aggiungere valore, influisce sui risultati.
Abbina l'intervallo di polling alla frequenza di cambiamento prevista:
| Modello di Cambiamento Esterno | Frequenza di Polling Iniziale Ragionevole |
|---|---|
| Stato CI dopo push attivi | Ogni 5–10 minuti |
| Canale di feedback del team | Ogni 30–60 minuti |
| Riepilogo Slack giornaliero | Una volta al mattino |
| Aggiornamenti dipendenze | Giornaliero o settimanale |
| Deriva documentazione | Notturno o settimanale |
Queste sono raccomandazioni di partenza, non regole universali. Quando i sistemi esterni lo supportano, l'attivazione basata su eventi è generalmente preferibile al polling.
4. Ciclo Attivo
Il ciclo attivo è una combinazione degli elementi di base precedenti.
Funziona senza supervisione, rispondendo a lavori pianificati o in arrivo e portando ogni elemento di attività attraverso un processo definito.
Trigger
Un'attività pianificata, una richiesta API, un evento GitHub, un messaggio, un problema o un altro segnale esterno avvia il lavoro.
Condizione di arresto
Ogni attività indipendente termina dopo aver raggiunto il suo obiettivo.
Le routine circostanti continuano a ricevere lavoro futuro finché qualcuno non le disabilita.
Casi d'uso ottimali
Il ciclo attivo è ideale per flussi di lavoro ripetitivi e ben definiti:
- Classificazione dei bug report.
- Classificazione dei problemi.
- Aggiornamento delle dipendenze.
- Migrazioni di routine.
- Revisioni del codice ripetitive.
- Indagine sugli allarmi.
- Verifica della distribuzione.
- Manutenzione del backlog.
Un esempio completo di pattern attivo
L'esempio di Anthropic combina diverse funzionalità di Claude Code:
/schedulecontrolla i nuovi report./goaldefinisce cosa deve essere completato in una singola esecuzione.- Le skill descrivono come ogni attività deve essere verificata.
- I flussi di lavoro dinamici coordinano più agenti.
- La modalità automatica riduce le sospensioni interattive per le autorizzazioni.
Le istruzioni combinate potrebbero essere simili a:
/schedule ogni ora: controlla i bug report in #project-feedback.
/goal: non fermarti fino a quando ogni report trovato in questa esecuzione
non è stato classificato, elaborato e risposto.
Quando correggi un bug, usa il flusso di lavoro in alberi di lavoro paralleli
per esplorare tre soluzioni, con una revisione indipendente.
Non si tratta più di un semplice prompt ripetuto. È un piccolo sistema operativo per un flusso di lavoro ristretto.
Flussi di lavoro dinamici
I flussi di lavoro dinamici sono script per coordinare sotto-agenti su larga scala.
Claude scrive uno script di orchestrazione JavaScript, e l'ambiente di esecuzione lo esegue in background. I risultati intermedi possono essere conservati nelle variabili dello script senza riempire il contesto principale della conversazione.
Anthropic posiziona i flussi di lavoro dinamici per le seguenti attività:
- Revisionare molti file per lo stesso problema.
- Migrare centinaia di file.
- Eseguire percorsi di ricerca indipendenti.
- Confrontare più soluzioni proposte.
- Revisionare ogni file modificato e generare un report finale.
La documentazione attuale specifica che i flussi di lavoro dinamici richiedono Claude Code versione 2.1.154 o successiva. Possono coordinare decine o centinaia di agenti, quindi prima di eseguire attività di produzione su larga scala, è opportuno testarli su piccola scala.
Il vero cambiamento: verifica e condizioni di arresto
Attività pianificate, orchestrazione, cicli di feedback e code di lavoro non sono concetti ingegneristici nuovi.
La vera svolta è che l'agente di codifica ora può partecipare più attivamente al ciclo:
- Leggere lo stato corrente
- Selezionare strumenti
- Apportare modifiche
- Interpretare gli errori
- Confrontare i risultati con gli obiettivi
- Provare un altro approccio
- Passare a un livello superiore solo quando il sistema non può operare in sicurezza
I prompt non sono scomparsi. Sono diventati un componente integrato di un sistema di controllo più ampio.
Oggi le domande di progettazione più importanti sono diventate:
- Cosa significa "completato"?
- Chi decide se la condizione è soddisfatta?
- Quali controlli sono deterministici?
- Quali prove può verificare l'agente?
- Qual è il numero massimo di tentativi?
- Qual è il budget di token o costo?
- Come rilevare la mancanza di progressi?
- Quali operazioni richiedono approvazione umana?
- Cosa fare dopo un fallimento dell'esecuzione?
Un prompt ben scritto non può compensare una condizione di arresto mancante.
La verifica è il miglioramento di maggiore impatto
Anthropic sottolinea ripetutamente la verifica: permettere a Claude di controllare e misurare il proprio output.
Se a un ingegnere umano viene chiesto di costruire una pagina senza accesso al browser, lavora alla cieca. La situazione è simile per un agente.
Gli strumenti di verifica utili includono:
- Suite di test
- Type checker
- Linter
- Comandi di build
- Automazione del browser
- Screenshot e confronto visivo
- Tracciamento delle prestazioni
- Query al database
- Asserzioni delle risposte API
- Scanner di sicurezza
- Analisi statica
- Script di accettazione riproducibili
Dare priorità ai controlli deterministici quando possibile
Uno script che restituisce un codice di uscita 0 o 1 è generalmente più economico e affidabile che chiedere al modello di ragionare da zero se un requisito è soddisfatto.
Ad esempio:
npm test
npm run lint
npm run typecheck
Uno script di verifica combinato potrebbe essere:
#!/usr/bin/env bash
set -euo pipefail
npm run typecheck
npm run lint
npm test
Claude può eseguire questo script dopo ogni modifica. Il ciclo non ha bisogno di reinterpretare l'intero processo di accettazione ogni volta.
Utilizzare un secondo agente per la revisione
Anthropic suggerisce anche di utilizzare un revisore con un nuovo contesto.
L'agente implementatore ha già visto il proprio ragionamento e potrebbe ripetere le stesse ipotesi. Un revisore indipendente è meno vincolato a quel percorso e può esaminare i risultati da un'altra prospettiva.
Per modifiche di alto valore, il sistema può utilizzare:
- Un agente per l'implementazione
- Un agente per verificare la correttezza
- Un agente per verificare la sicurezza
- Una suite di test deterministica come controllo finale
Non è meglio avere più agenti. Aggiungili solo quando il valore della revisione giustifica il costo aggiuntivo.
La pericolosità dei cicli senza barriere di sicurezza
I cicli che possono continuare indefinitamente sono sia potenti che pericolosi.
Esistono tre principali modalità di guasto.
1. Costi fuori controllo
Ogni ciclo può consumare token di input, token di output, chiamate a strumenti e utilizzo di modelli a pagamento.
Senza un limite di cicli o di budget, un ciclo aperto può continuare a consumare risorse producendo pochissimo valore aggiunto.
Claude Agent SDK supporta sia:
max_turns/maxTurnsmax_budget_usd/maxBudgetUsd
La documentazione ufficiale dell'SDK afferma:
Per impostazione predefinita, nessuno dei due limiti è impostato.
Per gli agenti in produzione, limiti espliciti sono una base ragionevole.
2. Progressi fittizi
L'agente potrebbe modificare ripetutamente lo stesso file senza produrre nuovi test superati o miglioramenti misurabili.
Anche se il sistema continua a provare diverse varianti della stessa soluzione fallita, i log potrebbero sembrare attivi.
Segnali utili di mancanza di progressi includono:
- Gli stessi test falliscono costantemente per più cicli consecutivi.
- Nessun nuovo criterio di accettazione viene soddisfatto.
- Lo stesso file viene ripristinato o riscritto ripetutamente.
- Il punteggio rimane invariato.
- La dimensione della coda non diminuisce.
- L'agente torna a soluzioni già rifiutate in precedenza.
Quando i progressi si bloccano, un ciclo robusto dovrebbe fermarsi o passare a un livello superiore.
3. Fiducia crescente in una soluzione sbagliata
L'iterazione può rendere una soluzione difettosa più complessa, non più corretta.
L'agente potrebbe aggiungere strati attorno a presupposti errati, generando codice che sembra sempre più completo mentre si allontana dal comportamento atteso.
Revisioni indipendenti, test deterministici e chiari percorsi di rollback aiutano a prevenire tali fallimenti.
Tre barriere che ogni ciclo dovrebbe avere
Un ciclo pratico dovrebbe includere almeno tre tipi di barriere.
1. Condizione di completamento verificabile dalla macchina
Lo stato di completamento dovrebbe essere osservabile tramite test, script, valutatori o stato esterno.
Esempi:
- Tutti i test superati.
- La coda è vuota.
- La pull request è stata unita.
- Il punteggio è almeno 90.
- Tutti gli elementi della checklist sono contrassegnati come completati.
- Nessun problema ad alta gravità irrisolto.
2. Limiti rigidi
Imposta almeno un limite massimo:
- Numero massimo di cicli.
- Numero massimo di tentativi.
- Durata massima.
- Utilizzo massimo di token.
- Costo massimo in valuta.
- Numero massimo di file modificati.
- Numero massimo di agenti paralleli.
Un limite trasforma un fallimento infinito in un fallimento finito.
3. Rilevamento di assenza di progressi
Ferma quando il sistema non progredisce più verso l'obiettivo.
Ad esempio:
Se dopo tre tentativi consecutivi non vengono prodotti nuovi test superati
e vengono modificati gli stessi file, ferma l'esecuzione e segnala l'ostacolo.
Un'implementazione di produzione può tracciarlo tramite script o stato del flusso di lavoro, non solo tramite istruzioni.
Gestione dell'utilizzo dei token
I cicli dovrebbero essere progettati per allocare le risorse di ragionamento sugli elementi di maggior valore.
Anthropic raccomanda le seguenti misure di controllo dei costi.
Utilizzare i primitivi più semplici
I compiti semplici non richiedono flussi di lavoro multi-agente.
Inizia in questo modo:
- Operazioni a turni regolari.
- Moduli di competenze verificabili in modo ripetibile.
- Usa
/goalquando servono più turni. - Usa
/loopo/schedulequando il lavoro deve essere attivato in base al tempo. - Usa flussi di lavoro attivi solo quando il flusso di attività è periodico e ben definito.
Usa modelli piccoli per il lavoro ordinario
I modelli veloci ed economici possono gestire:
- Scoperta di file.
- Classificazione semplice.
- Modifiche ripetitive.
- Formattazione.
- Esecuzione di controlli deterministici.
- Riepilogo di risultati strutturati.
Riserva i modelli più potenti per:
- Decisioni architetturali.
- Individuazione di errori ambigui.
- Giudizi di sicurezza.
- Revisioni avversarie.
- Soluzioni di conflitti di valutazione.
Prima sperimenta, poi espandi
I flussi di lavoro dinamici possono creare un gran numero di agenti.
Esegui prima su scala ridotta:
- Prima elabora dieci file, poi estendi a cinquecento.
- Prima risolvi una categoria di problemi, poi estendi a tutto.
L'intero arretrato.
- Prima un repository, poi ogni repository.
- Prima un giorno di messaggi, poi un mese di messaggi.
La sperimentazione rivela il consumo di token, i colli di bottiglia degli strumenti, i guasti comuni e le fasi di controllo mancanti.
Sostituisci il ragionamento con gli script
Quando il processo è deterministico, scrivi il codice una volta e lascia che Claude lo esegua.
Ad esempio:
- Analizza i log.
- Controlla il numero di file.
- Confronta la struttura dell'output.
- Compila moduli noti.
- Trova file che corrispondono a regole.
- Testa un elenco di URL.
- Calcola soglie di prestazioni.
Evita il polling eccessivo
I cicli basati sul tempo dovrebbero riflettere la velocità di cambiamento del sistema sottostante.
Intervalli troppo brevi aumentano i costi senza portare a risultati migliori.
Controlla l'utilizzo durante l'esecuzione
Anthropic fornisce diversi comandi per controllare il consumo:
/usage
Questo comando mostra l'utilizzo recente in aree come competenze, sotto-agenti e integrazioni MCP.
Eseguire /goal senza argomenti mostra i turni e il consumo di token dell'obiettivo corrente, mentre /workflows mostra l'utilizzo dell'agente del flusso di lavoro e fornisce controlli per fermare gli agenti.
La disponibilità può variare in base alla versione di Claude Code e alle funzionalità abilitate.
Permessi e sicurezza
L'automazione non va confusa con l'accesso illimitato.
Claude Code supporta modalità di autorizzazione che controllano quali strumenti e comandi possono essere eseguiti.
Per il lavoro autonomo su macchine di sviluppo, Anthropic consiglia di mantenere regole esplicite di autorizzazione o di utilizzare una modalità che approva automaticamente un numero limitato di operazioni comuni, pur controllando i comandi ad alto rischio.
Le modalità che aggirano i permessi dovrebbero essere utilizzate solo in ambienti isolati, ad esempio:
- Contenitori monouso.
- Lavoratori CI in sandbox.
- Macchine virtuali temporanee.
- Ambienti senza credenziali sensibili o dati montati importanti.
Un ciclo attivo in grado di modificare file, eseguire comandi shell, accedere a sistemi esterni e creare richieste pull dovrebbe anche avere:
- Permessi di repository ristretti.
- Accesso alla rete il più limitato possibile.
- Un elenco di strumenti consentiti e verificabili.
- Punti di controllo del versionamento.
- Credenziali indipendenti e con ambito limitato.
- Approvazione umana per distribuzioni in produzione o operazioni distruttive.
L'obiettivo non è eliminare tutte le decisioni umane, ma mantenere le persone per le decisioni che richiedono davvero giudizio.
Come scegliere il ciclo giusto
Fai riferimento al seguente processo decisionale.
Scegli un ciclo basato sui turni quando:
- Stai ancora esplorando il problema.
- Il passo successivo dipende dal giudizio umano.
- Il compito è piccolo e irregolare.
- I criteri di completamento sono soggettivi.
- Le modifiche errate sono facili da controllare manualmente.
Scegli un ciclo basato sugli obiettivi quando:
- Il risultato ha criteri di accettazione misurabili.
- L'agente potrebbe aver bisogno di più tentativi.
- Ogni tentativo può essere verificato.
- Puoi impostare limiti rigidi di turni o costi.
- Il lavoro appartiene a una sessione attiva.
Scegli un ciclo basato sul tempo quando:
- Lo stesso compito si ripete.
- Solo l'input cambia.
- È necessario controllare periodicamente i sistemi esterni.
- Usare un programma è più semplice dell'integrazione di eventi.
- Puoi tollerare il ritardo del polling.
Scegli un ciclo attivo quando:
- Il lavoro arriva continuamente.
- Ogni elemento segue un flusso stabile.
- I risultati possono essere controllati.
- Il flusso di lavoro può essere eseguito con permessi limitati.
- I fallimenti possono essere escalation, non nascosti.
- I budget di token e strumenti sono già stati testati.
Il primo ciclo pratico
Anthropic consiglia di iniziare con un'attività in cui sei attualmente un collo di bottiglia.
Fai tre domande.
1. Posso scrivere un controllo di verifica?
Esempi:
- Un comando di test.
- Un'interazione del browser.
- Una soglia di punteggio.
- Un controllo della dimensione della coda.
- Un confronto di modelli.
- Una regola di differenza visiva.
2. L'obiettivo è sufficientemente chiaro?
Un obiettivo utile descrive uno stato, non solo un'attività.
Scrittura migliore:
Tutti i test di pagamento superati e nessun errore TypeScript rimasto.
Scrittura debole:
Continua a migliorare il modulo di pagamento.
3. Il lavoro arriva a un ritmo prevedibile?
Se l'attività arriva ogni ora, ogni giorno, ogni settimana o dopo un evento noto, potrebbe essere adatta a un ciclo o una routine.
Se una qualsiasi risposta è sì, hai un candidato per il primo ciclo.
Esempio: dal prompt manuale al ciclo sicuro
Immagina un team che ripara ripetutamente i controlli delle richieste pull falliti.
Fase 1: Modalità a turni
Controlla le PR correnti, ripara i test CI falliti e spiega le modifiche.
Gli sviluppatori eseguono manualmente questa operazione a ogni variazione del CI.
Fase 2: Aggiungi verifica
Crea una competenza in grado di:
- Leggere i risultati CI.
- Riprodurre i fallimenti in locale.
- Eseguire i test pertinenti.
- Controllare la suite di test completa.
- Rivedere le differenze finali.
Fase 3: Aggiungi obiettivo
/goal Tutti i controlli CI necessari superati, fermati dopo 4 tentativi
La sessione può continuare per più tentativi di riparazione.
Fase 4: Aggiungi ciclo temporale locale
/loop 10m Controlla le PR, gestisci nuovi commenti di revisione,
e ripara eventuali controlli obbligatori falliti.
L'agente controlla i cambiamenti esterni.
Fase 5: Sposta in una routine
Crea una routine cloud attivata da eventi di richiesta pull o da un programma.
Limitata a:
- Repository pertinenti.
- Un ramo funzionale.
- Richieste pull in bozza.
- Un insieme definito di comandi.
- Spesa o dimensione massima dell'esecuzione.
L'evoluzione è graduale. Ogni fase aggiunge automazione solo dopo che la fase precedente ha avuto controlli affidabili.
Errori comuni
Usare un ciclo per compiti poco chiari
"Migliorare il codebase" potrebbe continuare all'infinito.
Dividilo in risultati osservabili.
Lasciare che l'agente di lavoro sia l'unico giudice
Usa test, script o valutatori indipendenti.
Aggiungere complessità multi-agente troppo presto
Un singolo agente con un potente validatore può essere migliore di un grande flusso di lavoro scarsamente coordinato.
Pianificare il lavoro troppo frequentemente
Il polling ogni minuto non è intrinsecamente più reattivo.
Ignorare i limiti di costo o di turni
I cicli senza limiti superiori possono portare a costosi fallimenti.
Trattare le istruzioni del prompt come controlli di sicurezza rigidi
Usa permessi, hook, sandbox e ambienti isolati per l'esecuzione deterministica.
Riparare manualmente ogni fallimento
Quando lo stesso errore si ripete, migliora la competenza, la regola, il validatore o il flusso di lavoro che lo ha prodotto.
Domande frequenti
Cosa significa ingegneria dei cicli in Claude Code?
L'ingegneria dei cicli è la progettazione di flussi di lavoro di agenti ripetuti fino al raggiungimento di una condizione di arresto. Si concentra su trigger, verifica, limiti, permessi ed escalation, non solo sulla formulazione del prompt.
La formulazione di un prompt.
Quali sono i quattro tipi di ciclo di Claude Code?
Anthropic classifica i cicli in basati sui turni, basati sugli obiettivi, basati sul tempo e attivi.
La loro principale differenza risiede nel meccanismo che attiva un nuovo ciclo e nel soggetto o fattore che decide quando il lavoro deve fermarsi.
Qual è lo scopo di /goal in Claude Code?
/goal imposta una condizione di completamento per la sessione corrente. Dopo ogni round, un valutatore indipendente verifica se la condizione è soddisfatta; in caso contrario, avvia un nuovo round, fino al raggiungimento dell'obiettivo o del limite configurato.
Qual è la differenza tra /loop e /schedule?
/loop esegue un prompt ripetutamente a intervalli sulla macchina locale, quindi il ciclo si arresta quando la macchina o la sessione si fermano. /schedule crea invece un'attività cloud che può continuare a funzionare sull'infrastruttura gestita da Anthropic, anche quando il laptop è spento.
I cicli di Claude Code possono essere infiniti?
Se al flusso di lavoro mancano dei confini, il ciclo potrebbe durare più del previsto. Prima di consentire l'esecuzione senza supervisione, è necessario definire una condizione di completamento quantificabile, un tetto massimo hard di round o costi, e una regola di arresto in caso di assenza di progressi.
Ho bisogno di più agenti per creare un ciclo?
No. Una normale sessione di Claude Code con abilità di verifica riutilizzabili può essere sufficiente. I flussi di lavoro dinamici e i multi-agenti sono più utili quando il richiede elaborazione parallela su larga scala o revisioni indipendenti.
Come ridurre i costi di un ciclo di agenti?
Utilizza il tipo di ciclo più semplice, scegli modelli più piccoli per lavori ordinari, sperimenta su carichi di lavoro ridotti, sostituisci il ragionamento deterministico con script, riduci i polling non necessari e imposta limiti chiari di round o budget.
I cicli autonomi di Claude Code sono sicuri?
Possono essere eseguiti in modo responsabile, purché autorizzazioni, repository, credenziali, budget, condizioni di arresto e percorsi di escalation siano rigorosamente controllati. Non utilizzare modalità che bypassano le autorizzazioni su macchine normali contenenti dati sensibili o di valore.
Strumenti correlati
- Claude Code: l'ambiente di codifica agentivo di Anthropic per leggere repository, modificare file, eseguire comandi e automatizzare attività di sviluppo.
- Claude Agent SDK: un kit di sviluppo software per incorporare il ciclo agenti con uso di strumenti di Claude Code in applicazioni personalizzate.
- Claude Code Skills: istruzioni procedurali, script e risorse riutilizzabili memorizzate in
SKILL.md. - Dynamic Workflows: strumenti di orchestrazione basati su script per coordinare numerosi sotto-agenti in attività complesse.
- Claude Code Hooks: automazione deterministica del ciclo di vita per validare, bloccare o rispondere alle operazioni degli strumenti.
- Model Context Protocol: uno standard aperto per connettere agenti AI a strumenti e fonti dati esterni.
- Chrome DevTools MCP: un server MCP per il debug del browser, utile per cicli di validazione frontend.
Link correlati
- Cicli Ingegnerizzati: Guida introduttiva ai cicli: la definizione ufficiale di Anthropic delle quattro modalità di ciclo e dei loro casi d'uso raccomandati.
- Fai lavorare Claude in modo continuativo: Documentazione ufficiale sulla sintassi
/goal, comportamento di valutazione, controllo dello stato e requisiti. - Esecuzione programmata dei prompt: Documentazione per prompt periodici locali e attività pianificate di Claude Code.
- Routine di automazione del lavoro: Guida ufficiale alle routine cloud attivate da pianificazioni, API ed eventi GitHub.
- Principi del ciclo agente: Documentazione tecnica su chiamate di strumenti, round, autorizzazioni, contesto e limiti di budget.
- Flussi di lavoro dinamici con sotto-agenti: Architettura ufficiale dei flussi di lavoro, limiti, esempi e soluzioni per il controllo dei costi.
- Guidare Claude Code: Guida di Anthropic alla selezione di competenze, hook, regole, sotto-agenti e altre modalità di controllo.
- Pagina originale della comunità BAAI: Articolo cinese ripubblicato fornito come riferimento iniziale.
Punti chiave
I cicli di Claude Code non sono semplici ripetizioni di prompt, ma sistemi controllati dalla cooperazione di trigger, strumenti, validazione, autorizzazioni, budget e condizioni di arresto.
I cicli basati su round lasciano il controllo umano in ogni fase successiva; i cicli di obiettivo delegano la condizione di completamento a un valutatore; i cicli programmati delegano il trigger. I cicli autonomi combinano questi elementi di base in flussi di lavoro senza supervisione eseguibili più volte.
I miglioramenti più significativi di solito non consistono nell'aumentare il numero di agenti, ma nel dotare gli agenti esistenti di meccanismi affidabili di autocontrollo, criteri di completamento chiaramente definiti e la capacità di fermarsi tempestivamente quando i progressi o il budget si esauriscono.
Un ciclo utile non è quello che può funzionare per sempre – ma quello che può dimostrare quando dovrebbe fermarsi.