Salta ai contenuti

Invia agenti revisori

Questa guida mostra come inviare agenti revisori per revisionare le pull request.

  1. Apri la PR e vai nella sua scheda Panoramica
  2. Apri il menu a comparsa ⋯ e scegli Ask AI

Questa azione avvia la pipeline pr_review preconfigurata, che apre lo spazio di revisione della PR e invia i revisori previsti dal livello di revisione dello spazio di lavoro — tre per impostazione predefinita (gli agenti preconfigurati qa, architect e engineer) — poi fa consolidare il tutto all’agente lead. Su questo percorso i ruoli non li scegli tu. Per controllare quali ruoli vengono eseguiti e quali file esamina ciascuno, usa lo strumento MCP o un passaggio di pipeline descritti di seguito.

Chiamalo dall’interno di uno spazio di revisione esistente:

dispatch_reviewers(
space_id: "...",
workspace_id: "...",
reviewers: [
{role: "reviewer"},
{role: "security", scope: "src/auth/**"}
]
)

space_id, workspace_id e reviewers sono tutti obbligatori. Ogni specifica di revisore accetta un role, più un scope facoltativo con glob di file e un prompt_override che sostituisce il brief predefinito. Una concurrency facoltativa (1–8) limita gli invii paralleli; se la ometti, si applica l’impostazione review_concurrency dello spazio di lavoro (valore predefinito 3, impostabile in Impostazioni → Spazio di lavoro → Generale).

Lo strumento restituisce subito gli elenchi dispatched e unmatched. Ogni revisore inviato viene aggiunto allo spazio come partecipante, annunciato con un messaggio di sistema e inviato con il proprio brief. I rilievi arrivano in quello spazio come messaggi review_node.

Apri Impostazioni → Spazio di lavoro → Modelli di pipeline, apri un modello, poi:

  1. Aggiungi un nodo Reviewer (prompt) dalla palette
  2. Scegli l’agente da inviare e scrivi il prompt del revisore, usando i segnaposto {{key}} per gli output a monte (ad esempio {{repo_local_path}}, {{pr_number}})
  3. Imposta la chiave di output (predefinita reviewer_findings) così i passaggi a valle possono leggere i rilievi

Il passaggio invia l’agente e resta sospeso finché quell’esecuzione non termina. Il motore poi raccoglie il payload submit_output dell’esecuzione nello stato della pipeline, sotto la chiave di output del nodo. (La descrizione nella palette dice ancora che il passaggio attende una chiamata complete_task — quello strumento non esiste; ignora la stringa.)

Per fare fan-out, collega diversi nodi revisori allo stesso passaggio a monte, poi consolida i loro output con un nodo Consolidate (join).

L’editor ricollega il terminale nascosto a ogni destinazione raggiungibile, così un nodo che aggiungi dopo il nodo Step preconfigurato viene comunque eseguito. I nodi in fan-out collegati allo stesso passaggio a monte vengono eseguiti in parallelo.

Per far scattare da sola una pipeline di revisione:

  1. Apri il modello in Impostazioni → Spazio di lavoro → Modelli di pipeline
  2. Trascina PR pubblicata o PR esterna aperta dalla sezione Trigger della libreria nodi sul canvas (oppure prendile dal riquadro fantasma Aggiungi un trigger)
  3. Seleziona il nuovo nodo e attiva l’interruttore Attivato nel suo ispettore, poi abilita il modello

Qui contano due eventi, e non sono intercambiabili:

Evento Quando scatta Chiavi del payload
PullRequestPublished Una PR viene aperta tramite Control Center — la superficie di composizione, oppure un agente che chiama pr_lifecycle.publish pr_id, workspace_id, repo_owner, repo_name
ExternalPrDetected Il servizio di polling delle PR trova una PR aperta direttamente su GitHub repo_owner, repo_name, pr_number, pr_title, author

Una PR aperta su github.com non genera mai PullRequestPublished, quindi un modello collegato solo a quell’evento non la vedrà. Nota anche che PullRequestPublished non porta con sé alcun pr_number: un passaggio il cui script o prompt fa riferimento a {{pr_number}} deve riceverlo da ExternalPrDetected, oppure da un’esecuzione manuale che lo fornisce.

Checkpoint: dopo aver abilitato il modello, apri Pipelines e verifica che compaia un’esecuzione per la prossima PR corrispondente. Un modello lasciato disabilitato fa scattare il proprio trigger nel vuoto: il motore rifiuta un modello disabilitato e termina senza avviare alcuna esecuzione.

dispatch_reviewers assegna un punteggio a ogni agente dello spazio di lavoro rispetto a ciascuna etichetta di ruolo richiesta, senza distinguere maiuscole e minuscole:

Corrispondenza Punteggio
Una skill che contiene l’etichetta di ruolo +3
Un titolo che contiene l’etichetta di ruolo +2
Il nome di un agente che contiene l’etichetta di ruolo +1

I punteggi si sommano e vince il totale più alto (in caso di parità, il primo candidato trovato). Se nessun candidato supera lo zero, la specifica compare nell’elenco unmatched dello strumento invece di essere inviata: così un ruolo che nessuno soddisfa viene segnalato, mai saltato in silenzio.

Una PR ha esattamente uno spazio di revisione, non uno per revisore. Viene creato in modo idempotente da pr.ensureSpace, collegato alla PR tramite un ReviewSpaceAssociation e predisposto rispetto all’head ref della PR. Ogni revisore inviato entra in quello spazio e vi pubblica i propri rilievi review_node: è questo che rende confrontabili i rilievi e permette all’agente lead di raggiungere un consenso tra loro.

Ogni revisore inviato riceve il proprio AgentRunLog. Segui l’avanzamento in:

  • Lo spazio di revisione, dove i rilievi arrivano in tempo reale
  • La scheda Revisione della PR, che mostra la barra di stato della revisione e il verdetto
  • Osservabilità → Dal vivo (/workspaces/:id/observability), l’elenco degli agenti con lo stato di ogni esecuzione, il tempo trascorso in diretta, un pannello a scomparsa con la trascrizione e un comando di terminazione. Non esiste una scorciatoia da tastiera: raggiungila dal piè di pagina della barra laterale.