Il rapporto dei test può essere pronto prima che tu apra Open WebUI

Alle 8:30 di lunedì, uno sviluppatore apre i risultati dei test notturni. Tre attività sono in rosso. La prima ha perso la connessione al database di prova, la seconda ha avuto un timeout intermittente e la terza è fallita su un’asserzione del codice cambiato venerdì. Separare i casi richiede più tempo che leggere gli indicatori rossi. Un agente programmato potrebbe lasciare in chat un breve rapporto con l’asserzione fallita e il frammento di log in cima.

Open WebUI, un’interfaccia di chat per modelli e strumenti IA che puoi ospitare in proprio, ha aggiunto gli agenti di programmazione alle automazioni pianificate nella versione 0.13.3. GitHub data il rilascio all’8 novembre 2026 alle 23:48 UTC. Un’automazione può salvare un terminale, una directory di lavoro e un agente disponibile in quel terminale, poi consegnare i risultati in chat. Il calendario può avviare un compito in un ambiente preciso, rendendo pratico il rapporto mattutino. Note di Open WebUI v0.13.3

Il primo compito da pianificare è un rapporto verificabile da una persona in pochi minuti. Usa l’automazione per raccogliere prove e lascia la decisione seguente al responsabile del progetto. Quando il rapporto è utile e ripetibile, hai un riferimento per decidere se concedere un altro permesso.

L’automazione ricorda dove lavora l’agente

Le automazioni di Open WebUI supportavano già richieste ricorrenti. Un’esecuzione avvia una chat attraverso il flusso normale, quindi impostazioni del modello, strumenti, filtri e memoria applicabile possono incidere. La versione 0.13.3 aggiunge un modo per scegliere un agente di programmazione rilevato in un terminale. Con il terminale selezionato, il selettore mostra combinazioni nel formato agente/modello. Cambiare terminale o cartella può cambiare le combinazioni. Prima di partire, Open WebUI verifica che terminale e agente salvati siano disponibili. Se uno manca, l’esecuzione fallisce e chi la possiede può esaminare il registro. Documentazione delle automazioni di Open WebUI

Il pianificatore apre una chat con le impostazioni di esecuzione salvate. Illustrazione originale di Telli.sh basata sulle note di Open WebUI v0.13.3.

La directory di lavoro risponde a una domanda comune con conseguenze costose. Quale copia deve leggere l’agente se due progetti hanno file simili o se sul disco ci sono un ramo di funzionalità e uno di rilascio? Un percorso esplicito fa partire il compito dove volevi e dà a chi revisiona un riferimento. Resta una directory di partenza. Permessi di lettura e scrittura, file accessibili, variabili d’ambiente, rete e comportamento dell’agente stabiliscono che altro può raggiungere.

Anche i risultati hanno una destinazione definita. Le automazioni con agenti di programmazione inviano l’uscita in chat. Le note le distinguono dalle automazioni dei modelli ordinari, che possono usare canali come destinazione. Cronologia e chat bastano a una persona per leggere il rapporto. Un gruppo che vuole un avviso condiviso deve ancora decidere quali informazioni condividere, dove e chi può vedere il log. Anche un’esecuzione fallita dovrebbe avere un responsabile che sappia dove guardare. Note di Open WebUI v0.13.3

Dai al primo compito un input piccolo e ispezionabile

Per il rapporto del lunedì, parti da copie del riepilogo notturno, un ID di commit generato automaticamente e pochi log di errori. Un esportatore di artefatti CI o una copia manuale in una directory temporanea danno all’agente un input stabile. Ogni file deve permettere di attribuire l’errore a un’attività e a un commit. Togli segreti evidenti e log estranei prima di copiare. Il rapporto funziona meglio se l’input ha un nome convenzionale e un orario verificabile senza chiedere all’agente di dedurre il file più recente.

Chiedi tre risultati distinti in una risposta. Il primo è un elenco breve dei fallimenti da esaminare. Il secondo riguarda i problemi ambientali o ancora da chiarire. Il terzo contiene un link o un percorso alla fonte per ciascun elemento. Usa un formato compatto per confrontare il risultato con la vista CI originale. Un compito che apre sei copie dello stesso ticket perché il test compare in sei esecuzioni della matrice trasforma una lettura breve in una revisione più grande.

Una richiesta utile dice che cosa va conservato nell’uscita. Questo esempio usa dati di prova con un record di commit e un riepilogo esportato. Directory e file sono illustrativi.

Leggi il riepilogo esportato dei test e gli estratti relativi ai fallimenti nella cartella assegnata. Comincia con ID dell’esecuzione, commit e orario indicati nell’input. Raggruppa i fallimenti ripetuti nella matrice. Per ciascun fallimento distinto indica nome del test, estratto utile più breve e percorso di origine. Distingui i fallimenti espliciti dalle possibili cause. Se il riepilogo manca, è superato o incompleto, spiega quale input manca e fermati. Lascia i file come li hai trovati.

Istruzioni così riducono l’ambiguità. Il terminale deve avere permessi coerenti con la richiesta. Se il lavoro legge solo file, fornisci una vista in sola lettura o una copia temporanea senza credenziali del repository. Un test fallito può stampare testo arbitrario da un sorgente, una dipendenza o un dato di prova. Quel testo va conservato come evidenza. Conta ancora di più quando il compito parte prima che si svegli chi lo gestisce.

Lo stesso assetto può aiutare per un secondo compito ricorrente. Un responsabile tecnico può dare all’agente un inventario datato delle dipendenze e avvisi raccolti separatamente, poi chiedere possibili corrispondenze di versione con i record pertinenti. È utile un elenco da rivedere con pacchetto, versione e fonte esatti. Uno scanner fidato può continuare a fare le corrispondenze deterministiche. Chi revisiona può stabilire se la dipendenza è in un percorso raggiungibile. File stabili aiutano a riprodurre il rapporto se le spiegazioni cambiano.

Una configurazione breve mostra dove sta il lavoro

Open WebUI documenta un interruttore globale Automations e un permesso separato per utenti non amministratori. Controlla che l’istanza esegua v0.13.3 o una versione successiva compatibile, che la funzione sia attiva e che l’account abbia accesso. Il terminale deve essere collegato e permesso nel contesto delle automazioni. Può apparire nell’editor dei modelli ed essere escluso dalle automazioni per la configurazione del contesto. Questo può spiegare un compito riuscito in chat normale e fallito all’orario previsto. Automations di Open WebUI · Connessione a Open Terminal

1. Prepara dati di prova. Metti in uno spazio temporaneo un’esecuzione riuscita, un errore rappresentativo e un manifesto con commit e orario. Tieni piccoli gli input e lascia fuori chiavi di produzione, configurazione cloud e file personali.
2. Apri Automations e crea un compito. Usa i campi per titolo, richiesta, modello e pianificazione. Nell’editor scegli un terminale, inserisci la directory esatta e seleziona l’agente previsto. Aspetta che l’ambiente mostri gli agenti disponibili nella cartella.
3. Esegui il compito una volta dall’editor. Apri la chat e il registro risultanti. Controlla commit, file, rimozione dei duplicati e permessi. Confronta con l’artefatto originale e verifica che l’albero dei sorgenti resti pulito.
4. Prova un caso negativo. Togli il manifesto da dati di prova separati o usa un input deliberatamente superato. Il rapporto deve rendere visibile l’evidenza mancante. Verifica che un terminale non disponibile per le automazioni appaia come esecuzione fallita nella cronologia.
5. Imposta l’orario ricorrente e rivedi i primi risultati. Confronta l’orario con la conclusione dell’esportazione CI. Se parte presto e legge l’esecuzione di ieri, il problema è di pianificazione anche se il testo sembra attuale. Sospendi il compito se cambia il formato dell’input o i rapporti cominciano a divergere.

Tratta dati di prova e richiesta come una coppia. Se rinomini la cartella, cambi la convenzione dei rami o sposti un test, aggiorna anche i dati. Così il compito non perde in silenzio ciò che usa per raggruppare i risultati. Quando qualcuno aggiorna la richiesta, salva l’esempio precedente e confronta i due risultati sullo stesso input. Migliorare il manifesto è spesso la correzione meno costosa, specie se due compiti devono concordare su quale sia l’ultima esecuzione.

Scegliere un terminale significa delimitarne i permessi

Un’interfaccia ospitata in proprio può collegarsi a un modello o agente di un altro fornitore. Esamina il fornitore scelto, i dati che riceve e le credenziali a disposizione. Una copia in un contenitore o spazio temporaneo dà all’operatore un posto dove limitare il compito. La sola directory iniziale serve a poco se lo stesso utente accede al resto della macchina o l’agente ha una credenziale di scrittura sul repository. La documentazione descrive contesti separati di utilizzo del terminale, compreso quello delle automazioni, così l’amministratore può limitare l’esposizione in anticipo. Documentazione dei terminali Open WebUI

Una configurazione in sola lettura separa prove, permessi di esecuzione e decisione di revisione. Illustrazione originale di Telli.sh.

Il lavoro risparmiato è il tempo fra aprire i risultati e sapere dove guardare. Un comando affidabile può fare molto. Fagli produrre ID e stato, poi lascia all’agente spiegare gli errori attraverso diversi tipi di uscita. La divisione aiuta se il compito si comporta male. Puoi confrontare l’ID con il manifesto e vedere se l’input è sbagliato prima di provare un altro agente.

Controlla anche il costo. I compiti pianificati possono consumare utilizzo fatturato se l’agente chiama un modello a pagamento. Log lunghi ampliano l’input e fallimenti ricorrenti possono ripetere l’analisi. Misura prima quanta revisione utile ottieni da un estratto limitato e un calendario breve. Se ogni esecuzione legge gli stessi file grandi, usa un passo deterministico economico per registrare se qualcosa è cambiato. Un’attività giornaliera è facile da preventivare quando ha un limite noto per l’input.

Per un piccolo gruppo la responsabilità conta quanto il terminale. Secondo la documentazione, l’automazione appartiene a chi l’ha creata ed è privata. Un rapporto personale può restare lì. L’approvazione di un rilascio usata da più persone richiede un processo visibile per condividere le prove e passare la responsabilità. La cronologia aiuta una persona a indagare su un errore. Un controllo CI condiviso tiene la decisione visibile a chi pubblica. Controlli d’accesso delle automazioni

Il rapporto mattutino si guadagna il posto durante la revisione

Dopo la prima settimana, guarda quali rapporti sono stati aperti. Controlla il link o l’estratto di ogni voce urgente e conta quante volte il riepilogo ha perso un errore, ne ha ripetuto uno noto o citato il commit sbagliato. Chiedi se il rapporto ha aiutato a trovare il prossimo test da esaminare. Queste osservazioni dicono più sul valore del calendario del numero di risposte automatiche.

Se l’uscita resta utile, puoi aggiungere una nuova fonte di evidenza un file alla volta. Dai al terminale un riferimento stabile, limita le credenziali e fai passare le modifiche al codice o all’infrastruttura dalla revisione abituale. Il miglior segnale è un rapporto mattutino su cui puoi agire e che puoi verificare in fretta quando qualcosa non torna.

Fonti

• Note di Open WebUI v0.13.3
• Configurazione, permessi e cronologia delle automazioni
• Connessioni e contesti dei terminali Open WebUI

---

Per conservare in un archivio consultabile le conversazioni e le decisioni alla base del lavoro, crea un account Telli.sh.