Come usare Agent View in Claude Code senza perdere il controllo
Agent View raccoglie in una sola schermata più sessioni Claude Code: quelle che stanno lavorando, quelle che aspettano una risposta e quelle che hanno concluso. È utile quando hai attività davvero indipendenti e vuoi controllarle per eccezione, invece di lasciare aperti molti terminali e rileggere ogni conversazione.
La vista comune, però, non coordina da sola il lavoro. Se due incarichi modificano gli stessi file, prendono decisioni incompatibili o usano criteri di completamento diversi, eseguirli insieme rende il conflitto più veloce. Prima del comando claude agents serve quindi un piccolo control plane umano: chi possiede ogni task, quale superficie può toccare, quale prova deve restituire e quando deve fermarsi.
Agent View non è un coordinatore automatico
La documentazione Anthropic distingue quattro forme di parallelismo. Un subagent svolge un incarico laterale dentro una conversazione e restituisce il risultato al thread che lo ha chiamato. Agent View espone sessioni indipendenti che gestisci tu. Un agent team coordina più sessioni con una lista condivisa, mentre un worktree separa materialmente le modifiche Git.
Queste superfici non sono sinonimi. Agent View è adatto quando puoi descrivere più risultati indipendenti e vuoi sapere a colpo d'occhio chi lavora, chi aspetta e chi ha terminato. Non è la scelta giusta quando i task devono negoziare continuamente la stessa decisione o scrivere sugli stessi file.
Prima di parallelizzare, prova a completare questa frase per ogni coppia di incarichi: “Il task A può concludersi correttamente anche se non conosce il risultato del task B”. Se la risposta è no, hai una dipendenza. Risolvila in sequenza, assegna un ordine oppure crea un contratto di handoff esplicito.
Separa i task prima del dispatch
Dividere “migliora il progetto” in cinque righe non crea cinque task indipendenti. Una separazione utile segue superfici e decisioni, non il numero desiderato di sessioni.
Considera un esempio sintetico:
sessione A: riprodurre un bug e produrre un caso di test, senza correggerlo;
sessione B: documentare il flusso interessato, in sola lettura;
sessione C: controllare una dipendenza in un modulo distinto;
sessione D: preparare una proposta di correzione dopo aver ricevuto il test di A.
Le prime tre possono partire insieme se non scrivono sugli stessi file. La quarta dipende dalla prova della prima e va avviata dopo. La distinzione non è “ricerca contro codice”, ma input disponibile, autorità e proprietà dei file.
Segna inoltre quali task sono soltanto diagnostici. Una richiesta di analisi non autorizza automaticamente una modifica. Se una sessione deve produrre un report, scrivi chiaramente read-only; se deve cambiare codice, elenca i percorsi consentiti e il comando di verifica atteso.
Scrivi un contratto di dispatch
Prima di inviare il prompt, completa cinque campi.
Campo | Domanda | Esempio sintetico |
|---|---|---|
Outcome | Quale artefatto deve esistere? | test che riproduce il difetto |
Input | Quali file o prove può usare? | log sanificato e modulo X |
Scope | Che cosa può leggere o modificare? | sola cartella |
Prova | Come dimostra il risultato? | test rosso prima, verde dopo la futura correzione |
Stop | Quando deve fermarsi? | conflitto di requisito o file fuori scope |
Un prompt come “indaga il problema e sistemalo” nasconde almeno tre decisioni: che cosa conta come problema, quali modifiche sono ammesse e quale prova chiude il lavoro. Il contratto le rende verificabili prima del consumo parallelo.
Usa nomi che descrivono l'outcome, non il modello o l'ordine di avvio. riproduci-timeout-upload è più leggibile di agente-3. Quando la vista contiene molte righe, il nome deve permetterti di capire lo stato senza aprire il transcript.
Leggi gli stati come richieste operative
Agent View mostra se una sessione sta lavorando, richiede input o ha finito. Questi stati non sono giudizi di qualità; sono inviti ad azioni diverse.
In lavoro: non aggiungere nuove istruzioni solo perché la riga è attiva. Intervieni se cambia un requisito o compare un rischio.
Serve input: rispondi alla domanda più piccola che sblocca il task. Se la risposta amplia lo scope, aggiorna anche il contratto.
Conclusa: leggi artefatto, diff e prova. Non dedurre il completamento dal testo finale.
Ferma o interrotta: conserva ciò che è valido e determina se la ripresa è sicura prima di rilanciare.
La tentazione più comune è trasformare la console in una chat di microgestione. Ogni messaggio aggiunto mentre la sessione lavora può cambiare priorità o introdurre un secondo obiettivo. Se il contratto è ancora valido, lascia lavorare la sessione e usa lo stato per decidere quando guardare, non per occupare ogni intervallo.
Entra nella sessione soltanto quando serve
La vista rapida permette di leggere e rispondere senza abbandonare Agent View; l'attach apre invece la conversazione completa. Entra quando devi valutare un piano, leggere una prova complessa o cambiare esplicitamente il mandato. Per una risposta binaria o un riferimento mancante, resta nella vista d'insieme.
Prima dell'attach, scrivi il motivo: “verificare se il nuovo file è dentro lo scope” oppure “decidere tra due alternative con impatto sul contratto”. Dopo l'intervento, registra la decisione nel luogo che governa il progetto. Una scelta importante lasciata soltanto nel transcript di una sessione è difficile da ritrovare e non diventa automaticamente nota alle altre.
Se scopri che due sessioni hanno bisogno della stessa decisione, fermale al confine sicuro. Risolvi una volta la decisione, aggiorna entrambi gli incarichi e poi riprendi. Due risposte improvvisate a domande equivalenti sono una fonte tipica di divergenza.
Riconcilia consegne e file condivisi
La chiusura avviene in quattro passaggi: Osserva, Decidi, Allega, Riconcilia.
Osserva: raccogli stato, artefatto, diff e comandi eseguiti.
Decidi: accetta, respingi o richiedi una correzione con un motivo preciso.
Allega: collega la prova al task, non soltanto alla conversazione.
Riconcilia: verifica conflitti fra risultati e stato reale del repository.
Anche con worktree separati, due modifiche possono essere logicamente incompatibili. Una può cambiare una firma mentre l'altra documenta quella precedente. Una può introdurre un test che l'altra non ha mai eseguito. Prima di unire il lavoro, costruisci una tabella con file toccati, assunzioni cambiate, test e dipendenze.
Non usare il numero di sessioni concluse come misura di progresso. Cinque righe verdi con una decisione irrisolta sono meno utili di una sola consegna integrata e provata.
Chiudi con una ricevuta
Per ogni sessione conserva almeno:
outcome richiesto e risultato effettivo;
file letti o modificati;
commit o diff, se esistono;
test eseguiti e relativo esito;
assunzioni non verificate;
decisioni richieste;
prossima azione e owner.
Se la sessione ha soltanto analizzato, la ricevuta deve dirlo. Se un test è passato localmente, non presentarlo come CI verde o deploy riuscito. Se una modifica dipende da un'altra sessione, la chiusura resta parziale fino alla riconciliazione.
Nel percorso per costruire il tuo Second Brain con l'AI la continuità non dipende dal numero di agenti, ma dai file che conservano incarichi, decisioni, prove e stato. Agent View può rendere più leggibile l'esecuzione; il sistema di lavoro stabilisce che cosa significa davvero “finito”.
Domande frequenti
Agent View coordina automaticamente le sessioni fra loro?
No. Ti offre una vista e controlli comuni sulle sessioni. Dipendenze, proprietà dei file e criteri di accettazione vanno progettati prima del dispatch.
Quando è meglio usare un subagent?
Quando un incarico laterale deve tornare dentro la stessa conversazione e non richiede una sessione che monitori direttamente. Agent View è più adatto a task indipendenti che vuoi seguire separatamente.
I worktree eliminano tutti i conflitti?
Isolano le modifiche fisiche ai file mentre il lavoro procede. Non eliminano conflitti logici, decisioni incompatibili o dipendenze fra risultati.
Una sessione `done` è pronta per il merge?
Non necessariamente. Controlla diff, test, assunzioni e integrazione. Lo stato indica che la sessione ha terminato il proprio turno, non che il progetto ha superato tutti i gate.
