Passa al contenuto principale

Task in background, /loop e pianificazione

Avanzato

Non tutto è una modifica rapida. Claude Code può eseguire lavoro che sopravvive a un singolo prompt: comandi lunghi in background, loop ricorrenti ed esecuzioni pianificate.

What you'll learn
  • Distinguere i tre meccanismi: task in background, /loop e routine pianificate
  • Avviare un comando lungo senza bloccare la sessione — e sapere perché controllarlo in un ciclo serrato è la mossa sbagliata
  • Scegliere quello giusto con una sola domanda: il lavoro sopravvive al prompt, alla sessione o a nessuno dei due?
  • Scrivere istruzioni per un'esecuzione pianificata che siano autosufficienti, perché ogni esecuzione parte da zero
  • Mettere dei guardrail sotto tutto ciò che agisce senza supervisione

Task in background​

Avvia un comando di lunga durata (un dev server, un test watcher, una build) senza bloccare la sessione. Claude continua a lavorare e viene avvisato quando il task produce output o termina. Usalo per tutto ciò che di solito metteresti in background con & — ma in forma gestita, così Claude può leggere l'output più tardi.

Niente attesa attiva

Avvia il task in background e prosegui; lascia che sia la notifica di completamento a riportarti indietro, invece di controllarlo in un ciclo serrato.

Loop ricorrenti (/loop)​

/loop esegue un prompt o un comando a intervalli ricorrenti all'interno di una sessione — ad es. "ogni 5 minuti, controlla lo stato del deploy". Gli dai un intervallo, oppure lasci che Claude decida il ritmo da sé. Ottimo per tenere d'occhio una run di CI o interrogare un job esterno di cui l'harness non può altrimenti avvisarti.

Controlla un deploy ogni cinque minuti, nella sessione

/loop 5m check the deploy status and tell me the moment it goes green or fails

Se ometti l'intervallo, Claude regola il ritmo da solo invece di seguire il tuo orologio.

Agenti cloud pianificati​

Per il lavoro che deve avvenire a orari fissi, in modo continuativo — "ogni mattina riassumi le nuove issue", "ogni ora cerca novità e aggiorna la documentazione" — usa task / routine pianificati (in stile cron). Ogni esecuzione parte da zero, quindi le sue istruzioni devono essere autosufficienti.

Scegliere fra i tre​

EsigenzaUsa
Eseguire un comando lungo e continuare a lavorareTask in background
Controllare qualcosa ogni N minuti in questa sessione/loop
Fare qualcosa a orari fissi, a tempo indeterminatoRoutine pianificata
Guided walkthrough1 of 4
  1. Un prompt, ma non la sessione? Task in background. Il prompt, ripetuto, dentro questa sessione? /loop. La sessione stessa, a orari fissi, a tempo indeterminato? Routine pianificata.
L'autonomia richiede guardrail

Tutto ciò che agisce senza supervisione secondo una pianificazione dovrebbe essere ben circoscritto e reversibile. Abbinalo a permessi rigorosi e leggi Hardening Autonomous Runs.

Check yourself

0/3
  1. Vuoi un riepilogo delle nuove issue ogni mattina, in modo continuativo. Quale meccanismo è adatto?
  2. Perché le istruzioni di una routine pianificata devono essere autosufficienti?
  3. Hai avviato in background un test watcher di lunga durata. Cosa NON devi fare adesso?
Key takeaways
  • Tre meccanismi, una sola domanda: il lavoro sopravvive al prompt (task in background), si ripete dentro la sessione (/loop) o sopravvive del tutto alla sessione (routine pianificata)?
  • I task in background sono gestiti, non semplicemente messi in background con & — Claude può leggerne l'output più tardi e viene avvisato quando terminano.
  • Niente attesa attiva. Avvialo, prosegui, lascia che la notifica di completamento ti riporti da lui.
  • /loop accetta un intervallo, oppure regola il ritmo da sé se lo ometti.
  • Ogni esecuzione pianificata parte da zero, quindi le sue istruzioni devono reggersi da sole.
  • L'autonomia senza supervisione richiede permessi rigorosi e un ambito reversibile: l'abbinamento non è facoltativo.

Prossimi passi​