Proposte e convalida
Panoramica
Quando ElevenAgents Architect completa una modifica, te la presenta come una proposta: un branch che contiene la modifica, test che dimostrano che funziona e una proposta di merge che richiede di unire quel branch in main. Questa pagina spiega come funziona ogni parte, dove trovarla e come una proposta passa da una conversazione al traffico live.
Cos’è una proposta
Una proposta si basa sul modello di versioning esistente:
La proposta di merge è una proposta di merge standard di ElevenAgents, dello stesso tipo che un membro del team apre manualmente. Non è un tipo di oggetto separato.
Una proposta di merge riguarda esattamente un branch di origine e uno di destinazione, quindi una proposta contiene una soluzione candidata. Per confrontare alternative, chiedi ad Architect di inserire ciascuna nel proprio branch. Ogni branch avrà quindi la sua proposta e potrai dividere il traffico tra questi come esperimento.
Architect agisce per tuo conto, quindi una proposta di merge che apre viene registrata a tuo nome come autore. Nessun campo indica che è stata creata da Architect. Menzionalo nella descrizione della proposta se il tuo team desidera saperlo.
Come viene creata una proposta
Architect crea una proposta quando gli chiedi di correggere o migliorare qualcosa, oppure quando gli fornisci un test non riuscito, un risultato di Spotlight o un ticket di triage. La sequenza completa, con gli strumenti chiamati da Architect a ogni passaggio, è nell’esempio pratico. In breve:
- Architect indaga, crea un branch e prepara la modifica nella tua bozza su quel branch.
- Architect scrive test e simulazioni per la modifica e li esegue nella conversazione prima di mostrarti il risultato.
- Architect apre la finestra di dialogo di pubblicazione. Esamini il diff e selezioni Pubblica, salvando la modifica come nuova versione sul branch.
- Architect apre una proposta di merge in
main, scrivendone la descrizione in base ai commit e alle esecuzioni di test effettivi del branch. - Architect ti propone di inviare una piccola quota di traffico live al branch mentre la proposta viene esaminata. È necessaria la tua approvazione.
Puoi interrompere il processo in qualsiasi passaggio. Un branch con una versione pubblicata ma senza proposta di merge è comunque utile: puoi testarlo personalmente o aprire una proposta in seguito.
Convalida nella conversazione
Architect scrive ed esegue i test durante la creazione della modifica, non come passaggio separato che avvii in seguito. Per una correzione, un approccio utile consiste nel mostrare che i nuovi test non riescono senza la modifica e riescono con essa. Architect può eseguire gli stessi test sia sul branch originale sia sulla bozza che contiene la modifica.
Architect non esegue automaticamente questo controllo prima e dopo per ogni modifica. Chiedilo quando è importante, ad esempio: “Mostrami la nuova simulazione che non riesce su main e riesce sul branch, poi apri una proposta.”
Un test riesce quando ogni condizione di successo è soddisfatta. Per un test LLM, la risposta dell’agente soddisfa i criteri di successo. Per un test di chiamata a strumenti, viene chiamato lo strumento previsto con i parametri previsti. Per una simulazione, la conversazione simulata soddisfa le condizioni di successo. Per verificare risultati instabili, chiedi ad Architect di eseguire i test più volte. Può ripetere ogni test fino a 50 volte e riportare la percentuale di riuscita.
Consulta Testing per sapere come viene definito ciascun tipo di test.
Dove trovare le proposte
Apri l’agente, poi vai su Controllo versione > Proposte. Puoi filtrare l’elenco per stato, autore (Creato da) e revisore (In attesa di revisione da, Revisionato da). Una proposta aperta da Architect nella tua conversazione viene elencata con te come autore.
Architect restituisce anche un link alla proposta nella conversazione non appena la crea.
Anatomia di una proposta
La pagina di una proposta mostra i branch di origine e destinazione, il relativo stato, se può essere unita e quanto il branch di origine è indietro o avanti rispetto alla destinazione. Include queste schede:
Panoramica
Modifiche
Esecuzioni dei test
Conversazioni
La descrizione, una timeline delle attività con i commit sul branch di origine, le revisioni e i commenti, oltre a una casella per i commenti. La barra laterale mostra i revisori, i revisori consigliati e gli eventuali ticket di triage collegati.
Una descrizione scritta da Architect include sempre tre sezioni: Riepilogo (ogni modifica significativa e il motivo), Test (quali test sono stati eseguiti e i relativi risultati, oppure l’indicazione che non ne è stato eseguito nessuno) e Come eseguire la revisione (su cosa concentrarsi e un test da eseguire o una conversazione da provare).
Revisione e merge
Stati
Una proposta di merge ha uno di questi stati:
Mentre una proposta è aperta, l’ultima revisione di ogni revisore è Approvata oppure Modifiche richieste. Non esistono stati separati “testato” o “pronto per la revisione”. I risultati dei test vengono invece mostrati nella scheda Esecuzioni dei test.
Revisioni e commenti vengono visualizzati nella timeline delle attività della scheda Panoramica, insieme a ogni nuova versione salvata sul branch di origine.
Chi può approvare ed eseguire il merge
- Chiunque abbia accesso come editor all’agente può revisionare una proposta, tranne il suo autore. Poiché Architect agisce per tuo conto, non puoi approvare una proposta aperta da Architect nella tua conversazione. Deve farlo un membro del team.
- Una proposta può essere unita quando ha almeno un’approvazione da una persona diversa dall’autore e l’ultima revisione di nessun revisore è Modifiche richieste. Gli amministratori del workspace possono eseguire il merge senza approvazione.
- Il merge in un branch protetto richiede autorizzazioni di amministratore oppure l’approvazione di un amministratore.
Architect non può approvare, commentare, unire o chiudere una proposta di merge. Questi passaggi vengono sempre eseguiti da persone. Consulta Proposte di merge per le regole complete di revisione.
Architect può unire direttamente un branch, senza una proposta, quando glielo chiedi e il tuo ruolo consente
il merge. Nella modalità Approvazione richiesta chiede prima. Nella modalità Approvazione automatica no. Usa
la protezione dei branch su main se ogni modifica deve passare da una proposta revisionata.
Cosa accade durante il merge
Dopo il merge non è previsto un passaggio di pubblicazione separato. Il merge crea una nuova versione sul branch di destinazione e quella versione gestisce immediatamente il traffico live per la quota di traffico che riceve la destinazione. Quando la destinazione è main e non è impostata alcuna divisione del traffico, questo significa tutti gli utenti.
Il merge inoltre:
- Sposta sul branch di destinazione l’eventuale quota di traffico live del branch di origine.
- Archivia il branch di origine per impostazione predefinita.
- Chiude tutte le altre proposte aperte dallo stesso branch.
- Risolve il ticket di triage collegato, se presente.
Rilascio graduale
Prima che una proposta venga unita, puoi inviare una quota di traffico live al suo branch affinché utenti reali utilizzino la modifica.
Avvia la divisione
Chiedi ad Architect, ad esempio: “Invia il 5% del traffico a questo branch.” Architect ti indica la divisione
risultante completa, inclusa la quota di main, e chiede l’approvazione prima di applicarla. Puoi
anche impostarla autonomamente: in Controllo versione > Branch, seleziona Distribuisci sul branch.
Osserva i risultati
Apri la scheda Conversazioni della proposta per leggere le conversazioni sul branch oppure chiedi ad Architect
di confrontare i risultati del branch con quelli di main.
Promuovi o annulla
Per promuovere la modifica, unisci la proposta. La quota di traffico del branch viene spostata in main insieme a essa. Per annullare,
chiedi ad Architect di impostare la quota del branch su 0% oppure modifica personalmente la distribuzione. Il
traffico live torna immediatamente a main.
Le quote di traffico devono sempre totalizzare il 100% e il routing è deterministico per ogni conversazione. Modificare la quota di un branch protetto, incluso sottrarre traffico a un main protetto, richiede un amministratore. Consulta Distribuzione del traffico.
Proposte proattive
Architect produce proposte quando glielo chiedi oppure quando gli fornisci un test non riuscito, un risultato di Spotlight, un avviso o un ticket di triage. Non analizza ancora i tuoi agenti a intervalli programmati né apre proposte autonomamente.
L’attuale percorso proattivo è Spotlight, seguito da un passaggio di consegne. Spotlight monitora continuamente le conversazioni del tuo agente. Produce un riepilogo settimanale con analisi suggerite, genera avvisi in tempo reale e consiglia modifiche alla configurazione. Per trasformare un risultato di Spotlight in una proposta:
Scegli un risultato
Apri il riepilogo settimanale ed esamina i Passaggi successivi suggeriti oppure apri un avviso in tempo reale.
Passalo a ElevenAgents Architect
Seleziona Apri in Architect su un suggerimento, Analizza con Architect sul riepilogo oppure Indaga con Architect su un avviso. Architect riceve il risultato e viene istruito a verificarlo rispetto a conversazioni reali e a identificare quale branch è interessato prima di suggerire una modifica.
I ticket di triage funzionano allo stesso modo. Il tuo agente live può segnalare problemi da revisionare durante le conversazioni e Discuti con Architect su un ticket avvia un’indagine sul ticket.
Le automazioni programmate, con report inviati a una casella di posta di Architect, sono in fase di sviluppo. La scheda Posta in arrivo nella pagina Architect è un segnaposto per queste funzionalità.