Sessioni

Una sessione è un branch Git e una sandbox in cui lavora l’agente.

Una sessione è una singola unità di lavoro dell’agente. Beeuni crea un branch Git e prepara una sandbox per la sessione. L’ID della sessione, il nome del branch e l’ID della sandbox hanno lo stesso valore.

Stato

Nella pratica, una sessione può trovarsi in 4 stati.

Il database definisce altri 3 valori (queued, branching, completed). Al momento Beeuni non li assegna alle sessioni.

Arresto, ripresa e arresto automatico per inattività

Puoi arrestare una sessione manualmente. Riprendendola, riottieni la stessa sandbox, con lo stesso filesystem e la stessa identità di runtime. Si azzerano solo i processi in esecuzione e la memoria. La conversazione di harness standard rimane associata alla sessione.

Beeuni arresta anche le sessioni inattive:

• Dopo 15 minuti di inattività, per una sessione normale o un’esecuzione di un trigger.
• Dopo 2 minuti di inattività, per una sessione worker avviata da un’altra sessione.

Un turno dell’agente in corso impedisce l’arresto. Il processo di manutenzione viene eseguito ogni 5 minuti. Di conseguenza, un arresto automatico normale avviene circa 15–20 minuti dopo il turno nel terminale.

Un turno in attesa di una persona non svolge alcun lavoro: l’agente ha posto una domanda o chiede il permesso di usare uno strumento. In questi casi, Beeuni mantiene attivo il computer per un massimo di 2 ore dal momento in cui rileva per la prima volta l’attesa. In un’esecuzione di un trigger o di una pianificazione, nessuno riceve la richiesta e il limite è di 30 minuti. Poi Beeuni termina il turno e arresta il computer. Invia un messaggio per continuare. Una chiamata al modello o la pagina della sessione aperta contano come attività e prolungano il funzionamento del computer come di consueto.

La pagina di una sessione che stai usando la mantiene attiva. Conta come in uso quando la scheda è visibile e hai fatto clic, digitato, scorrimento o interagito con essa negli ultimi 10 minuti, e solo se puoi avviare sessioni nel progetto. Una scheda lasciata aperta senza interazioni smette di contare dopo 10 minuti, quindi la sessione si arresta circa 15–20 minuti dopo. La scheda aperta di un utente con accesso in sola lettura non mantiene mai attiva la sessione. La sola pagina mantiene attiva una sessione per un massimo di 2 ore dall’ultimo turno dell’agente; un nuovo messaggio avvia un turno e azzera il limite.

Cosa viene conservato con l’arresto e cosa si perde con l’eliminazione

L’arresto e la ripresa conservano l’identità e il filesystem della sandbox. L’eliminazione distrugge la sandbox. Git è l’unico registro permanente: il lavoro che l’agente salva con un commit e invia al repository sopravvive; tutto il resto viene perso.

Etichette

Un’etichetta classifica una sessione: bug, customer: eu, worker. Apri il menu ⋯ della sessione e scegli Modifica etichette. Il filtro Etichette nell’elenco delle sessioni mostra solo quelle che hanno tutte le etichette selezionate. Le etichette sono testo libero, da 1 a 64 caratteri, con un massimo di 20 per sessione.

Anche agenti e script possono impostare etichette: beeuni sessions new --label worker, beeuni sessions update --label needs-review (all’interno di una sessione, senza un ID, applica l’etichetta a quella sessione) oppure labels nell’API e nell’SDK. Una sessione include anche un oggetto metadata a testo libero per le tue chiavi personalizzate: consulta Sessioni SDK.

Runtime

Una sessione esegue un solo harness: harness standard o harness sperimentale. Consulta Harness. Beeuni memorizza l’agente e il modello selezionati all’avvio della sessione. Una sessione in esecuzione mantiene il proprio harness finché non viene riavviata o ripresa.

Accesso alla sessione

Una sessione è privata per chi l’ha creata. Il proprietario apre Accesso alla sessione e sceglie una delle 3 opzioni.

Chiunque abbia accesso può leggere la conversazione e proseguirla.

Una sessione condivisa usa chiavi condivise. Una volta condivisa, la sessione usa solo le chiavi dei provider condivise con l’intero progetto, mai le chiavi personali di qualcuno né la sua connessione ChatGPT. Se il modello era eseguito con le tue chiavi personali, la condivisione lo fa passare alle chiavi del progetto per quel provider. Se il progetto non condivide alcuna chiave che consenta di eseguire il modello, la condivisione viene rifiutata e la sessione rimane privata. Consulta Chiavi dei provider e accesso dei membri.

Solo il proprietario può modificare questa impostazione. Un responsabile del progetto che non ha creato la sessione può aprirla se è stata condivisa con lui e può arrestarla, riavviarla o eliminarla. Non può modificare l’elenco delle persone che possono aprirla. Condividere una sessione con un responsabile non significa cedergli il controllo dell’elenco degli accessi.

Un tipo di sessione non ha un proprietario umano: quelle create da un trigger, che vengono eseguite con l’identità dell’agente del trigger. A gestirle sono i responsabili del progetto. Imposta la policy per tutte direttamente sul trigger, in Accesso alla sessione: il salvataggio aggiorna anche le sessioni già create da quel trigger.

Gli amministratori possono aprire tutte le sessioni

Il proprietario di un account può consentire ai proprietari e agli amministratori dell’account di aprire tutte le sessioni dell’account, comprese quelle che i membri mantengono private. Attiva l’opzione in Account → Impostazioni → Sicurezza → Gli amministratori possono aprire tutte le sessioni. Per impostazione predefinita è disattivata.

• Solo il proprietario dell’account può modificare l’impostazione. Gli amministratori vedono l’interruttore, ma non possono attivarlo o disattivarlo; così nessun amministratore può concedersi l’accesso al lavoro di tutti.
• Gli amministratori trovano queste sessioni nella pagina Sessioni del progetto. La barra laterale continua a mostrare solo le sessioni avviate da te o condivise con te.
• L’accesso è completo. Un amministratore può aprire e leggere la sessione e proseguirla, proprio come una sessione condivisa con l’intero progetto.
• I membri ne sono informati. Quando l’opzione è attiva, la finestra di dialogo Accesso alla sessione indica che i proprietari e gli amministratori possono aprire tutte le sessioni.
• Tutto viene registrato. Ogni modifica dell’impostazione viene registrata come iam.session_oversight.enable o iam.session_oversight.disable, e ogni sessione aperta da un amministratore tramite questa opzione come project.admin_oversight_session_read (al massimo una volta per amministratore e sessione ogni ora).
• I token di agenti e sandbox non ottengono mai questo accesso, nemmeno se avviati da un amministratore.

Trova una sessione per proprietario o accesso

La pagina Sessioni del progetto mostra il proprietario e le impostazioni di accesso di ogni sessione nella rispettiva riga: l’avatar e il nome del proprietario (Tu per le tue sessioni), seguiti da un’icona che indica chi può aprirla: un lucchetto per Solo il proprietario, un’icona con persone per Persone specifiche e un globo per Intero progetto.

Apri Filtro nella pagina Sessioni per restringere l’elenco:

• Proprietario — una voce per persona, con il relativo conteggio.
• Accesso — Solo il proprietario, Persone specifiche o Intero progetto.
• Raggruppamento → Proprietario — una sezione per persona, con le tue sessioni per prime.

I filtri si combinano con Stato, Origine e la ricerca. Reimposta li cancella tutti.

Condividere un’anteprima

Puoi condividere l’anteprima live di una sessione tramite un link pubblico, in modalità di sola visualizzazione o interattiva. La creazione del link spetta al proprietario della sessione, per lo stesso motivo: il link non richiede autenticazione, quindi chiunque abbia l’URL può leggere la sessione senza accedere. Un responsabile del progetto può visualizzare e revocare i link di una sessione anche senza esserne proprietario: la revoca può solo rimuovere l’accesso.

Per l’enumerazione completa degli stati, le variabili d’ambiente iniettate e gli endpoint del daemon, consulta Runtime. Per scoprire come una sessione sceglie il proprio agente, consulta Agenti. Per le sessioni avviate da una pianificazione o da un webhook, consulta Trigger. Per integrare il lavoro delle sessioni nel branch predefinito, consulta Richieste di modifica.