Esegui agenti in parallelo

Questa guida mostra come eseguire più agenti contemporaneamente senza che si sovrascrivano a vicenda.

L’unità di isolamento è lo spazio, non l’agente

Quando il lavoro inizia in uno spazio, Control Center predispone un checkout copy-on-write per ogni repo registrato sotto la radice dello spazio stesso, su un branch derivato dal modello di branch dello spazio di lavoro. Ogni agente nello spazio riceve poi la propria directory di lavoro overlay, ma gli overlay condividono la directory repos/ di quello spazio.

Quindi:

Due agenti in spazi diversi lavorano in checkout diversi, su branch diversi. Questo è isolamento reale.
Due agenti nello stesso spazio lavorano nello stesso checkout, sullo stesso branch. I loro percorsi overlay sono diversi, quindi anche il lock del percorso di invio (che serializza le esecuzioni solo quando richiedono la stessa identica directory di lavoro) non li serializza. Possono scrivere gli stessi file nello stesso momento.

La regola che ne segue: uno spazio per ogni attività parallela.

Esegui attività in parallelo — spazi separati

Apri uno spazio con l’agente A e inviagli un’attività.
Apri un secondo spazio con l’agente B e inviagli un’attività diversa.
Entrambi vengono inviati immediatamente, ciascuno nel checkout del proprio spazio sul proprio branch.

Questa è la ricetta da seguire ogni volta che gli agenti dovranno modificare file.

Collabora in un unico spazio — più menzioni

In un unico spazio, menziona con @ più di un agente:

@alice refactor the auth module. @bob review what alice lands.

Entrambi gli agenti vengono inviati in parallelo e confluiscono nello stesso spazio, con il tag del mittente. Poiché condividono il checkout dello spazio, usa questa modalità per la collaborazione — uno scrive, uno legge, oppure due agenti ragionano sullo stesso albero — non per due modifiche indipendenti.

Dirama da una pipeline

Il modello pr_review integrato è l’esempio fornito di fan-out: diversi nodi revisori vengono eseguiti contemporaneamente da un unico trigger e un nodo Consolidate (join) riunisce i loro rilievi in un unico report. Avvialo dalla schermata delle pipeline e ogni revisore viene inviato in parallelo.

L’editor delle pipeline nasconde la sentinella terminale e la ricollega in modo che attenda ogni sink attivo quando aggiungi o colleghi un passaggio, quindi i rami che disegni tu vengono davvero eseguiti.

Guardali in azione

Osservabilità → Dal vivo (piè di pagina della barra laterale → Osservabilità, poi la scheda Dal vivo) mostra l’elenco degli agenti di questo spazio di lavoro, aggiornato a ogni secondo: stato (in esecuzione / inattivo / in pausa / interrotto), che cosa sta facendo ciascuno, token e costo della sua ultima esecuzione e un comando di terminazione per un processo in esecuzione. Selezionando una riga si aggancia un pannello con la trascrizione dal vivo.

Impostazioni → Spazio di lavoro → Agenti mostra lo stesso elenco con un vocabolario di stato diverso, orientato all’attenzione e derivato dalla cronologia di esecuzione di ogni agente — in esecuzione, bloccato, non riuscito, inattivo, nessuna esecuzione — ordinato in modo che tutto ciò che richiede attenzione salga in cima. La scheda Log di ogni agente raccoglie la sua cronologia di esecuzione.

Entrambe le superfici hanno come ambito lo spazio di lavoro attivo.

Gestisci i conflitti

Tra spazi diversi, ogni spazio si trova sul proprio branch, quindi una collisione si manifesta come un normale conflitto di merge Git quando unisci la seconda pull request. Risolvilo come faresti con qualsiasi conflitto di merge.

All’interno di un unico spazio non ci sono confini di branch né lock: gli agenti scrivono gli stessi file dal vivo e lo sconfitto viene semplicemente sovrascritto. Se ti accorgi di voler far modificare due agenti in uno stesso spazio, suddividi invece il lavoro in due spazi.

Per ridurre le collisioni in entrambi i casi:

Assegna a ogni agente un ambito distinto: file diversi, moduli diversi.
Usa il grafo del codice per verificare che cosa tocca una modifica prima di inviarla. Vedi Cerca codice con il grafo del codice.
Revisiona e unisci prontamente la pull request di ogni agente.

Considerazioni sulle risorse

Ogni agente in esecuzione comporta:

Un checkout dello spazio: trascurabile su disco finché copy-on-write è disponibile; su Windows un git worktree. Un file system che non può eseguire un reflink fa fallire il provisioning invece di copiare.
Un processo sull’host del server
I token del modello, che si accumulano per ogni agente

I costi confluiscono in Osservabilità → Panoramica. Tieni presente che un normale turno interattivo non ha alcun limite di spesa; vedi Gestisci i costi per i due comandi che invece ne hanno uno.