Come pianificare un agente di programmazione in Open WebUI su un server domestico

Open WebUI v0.13.3 può pianificare l'esecuzione di un agente di programmazione su un terminale e una directory di lavoro selezionati. Inizia con un'attività che generi solo un report in un checkout usa e getta: esegui un comando di test noto, riepiloga gli errori e invia il risultato a una chat. Questo test verifica lo scheduler, i permessi e il percorso di consegna prima di concedere a un job ricorrente l'accesso a file importanti.

Serve un'installazione compatibile di Open WebUI, un'integrazione del terminale raggiungibile che offra l'agente previsto e un ambiente di lavoro accessibile. Le note di rilascio della v0.13.3 dicono che le esecuzioni pianificate verificano che il terminale e l'agente salvati siano ancora disponibili. Considera il terminale, il file system e la connessione al modello sottostante come parti separate della configurazione.

Quali cambiamenti ha introdotto la release di novembre?

Nell'editor di automazione puoi selezionare un terminale e una directory, quindi scegliere un agente offerto da quel terminale. Il terminale e la cartella configurati vengono mantenuti nell'esecuzione pianificata. I risultati dell'automazione dell'agente vengono inviati a una chat, mentre altri tipi di automazione possono avere opzioni di destinazione diverse. La precedente release v0.13.1 ha introdotto gli agenti di programmazione nel selettore di modelli, quando un terminale connesso li offre.

Un terminale selezionato può essere eseguito sullo stesso host di Open WebUI oppure essere un servizio separato raggiungibile. Per il job conta il file system del terminale. Una directory visualizzata sul tuo portatile potrebbe non essere presente in un container. Un file disponibile in un terminale potrebbe non esistere in un altro. Verifica il percorso nel terminale esatto selezionato per l'automazione.

Come preparare l'ambiente di lavoro?

Crea un checkout di test dedicato, idealmente per un repository piccolo e senza segreti di produzione. Fissa una revisione nota e includi nella configurazione un test innocuo che venga superato e uno notoriamente non superato. Per il primo report, esponi il checkout di input in sola lettura, se il runner di test lo supporta. Fornisci una posizione temporanea scrivibile per le cache dei test e i log. Alcuni strumenti di compilazione insistono per scrivere nell'albero, quindi configurali in modo che scrivano altrove oppure usa una copia scrivibile usa e getta.

Se condividi un repository tra più job, crea un worktree per ogni agente o attività. Tieni separati i backup e la directory di lavoro. Leggi perché i backup possono fallire in caso di accesso condiviso prima di concedere a un’attività ampi permessi di scrittura su un file server.

Come configuri il primo job pianificato?

Apri l’editor delle automazioni in una versione che include l’automazione degli agenti. Seleziona il terminale, scegli la directory visibile da quel terminale e poi seleziona l’agente. Per il primo test, pianifica un’esecuzione singola a breve termine, se la tua installazione offre questa opzione. Controlla l’orario pianificato nel fuso orario configurato. Imposta un limite moderato di runtime o di passaggi, usando i controlli disponibili per il tuo agente e la tua distribuzione.

Assegna al job un input, un comando e un formato del risultato concreti. Per esempio:

Esamina il checkout nella directory di lavoro selezionata.
Esegui una volta il comando locale esistente per lo smoke test.
Indica il comando, il codice di uscita e il primo test non superato.
Se il comando o la cartella non sono disponibili, segnala l’errore.
Non installare dipendenze, modificare il repository né contattare servizi esterni.

Le istruzioni guidano l’agente. Applica separatamente i limiti del file system e della rete tramite la configurazione del terminale e del container. Verifica che una dipendenza mancante generi un errore chiaro anziché un’installazione imprevista. La documentazione di Open WebUI è il punto di partenza per le impostazioni del terminale e dell’amministratore.

Che cosa dovresti verificare dopo la prima esecuzione?

Apri la chat risultante e controlla l’identità dell’agente, il percorso di lavoro, il comando di test, il codice di uscita e la revisione testata. Confronta il risultato con l’esecuzione manuale dello stesso comando in quel terminale. Il completamento di un’automazione dimostra solo che il flusso di lavoro è terminato. Il report deve comunque fornire prove che il test previsto sia stato effettivamente eseguito.

Prova deliberatamente un percorso di errore. Indica a un job di test un input mancante innocuo oppure arresta brevemente il terminale usa e getta e osserva lo stato risultante. Ripristinalo dopo il test. Un operatore dovrebbe poter distinguere un agente non disponibile, una directory mancante, un test non riuscito e un timeout del modello senza leggere un’intera trascrizione della chat. Verifica che la successiva esecuzione legittima non riutilizzi silenziosamente un output obsoleto.

L’hosting autonomo di Open WebUI mantiene il codice in locale?

Open WebUI e il suo terminale possono essere ospitati autonomamente, mentre l’agente di programmazione selezionato usa un modello remoto. Scopri dove l’agente invia i prompt di sistema, gli estratti dei file e i log dei test. Verifica la configurazione del provider prima di collegare un checkout privato. Conserva le credenziali del provider nella configurazione segreta designata del servizio ed evita di condividerle tramite prompt o log.

Se i tuoi requisiti vietano l’elaborazione esterna, inizia con un endpoint di un modello locale. Verifica l’endpoint e la configurazione di fallback dell’agente, poi controlla le eventuali restrizioni di rete applicabili al terminale. Per saperne di più su come limitare l’esposizione, consulta questa guida al triage delle vulnerabilità con l’IA e alla protezione dei segreti.

Come si trasforma un job che produce solo report in un flusso di lavoro ricorrente?

Dopo aver verificato che sia i primi esiti positivi sia quelli negativi siano comprensibili, aggiungi una pianificazione ricorrente che non si sovrapponga a un altro job che usa la stessa directory. Assegna ai report un timestamp e la revisione del repository. Mantieni semplici gli avvisi: segnala gli errori che richiedono un intervento e conserva un contesto sufficiente per riprodurli. Verifica periodicamente che le credenziali dell’agente, la connettività del terminale e la directory pianificata continuino a funzionare dopo gli aggiornamenti.

Se in seguito consenti l’applicazione di patch, mantienile in un branch isolato e richiedi una revisione prima del merge. In caso contrario, un nuovo tentativo pianificato potrebbe duplicare gli effetti collaterali. Un job che produce solo report è più facile da ripetere perché scrive soltanto un risultato, mentre gli aggiornamenti delle dipendenze e i comandi di distribuzione modificano lo stato. Considera questo passaggio una decisione separata sui permessi.

Domande frequenti

Quale versione ha introdotto le automazioni degli agenti?

La funzionalità pertinente è indicata in Open WebUI v0.13.3. La funzionalità del selettore degli agenti in v0.13.1 è correlata, ma distinta.

Perché l’agente non compare nel selettore?

Verifica che il terminale selezionato sia raggiungibile e indichi la disponibilità di quell’agente, e che la versione installata e i permessi del tuo account consentano di usare questa funzionalità.

Posso scegliere una cartella dal mio portatile?

Scegli un percorso sul terminale che eseguirà davvero il job. Se necessario, monta o copia prima lì il checkout.

Il risultato di un’automazione viene inviato a un canale?

Le note della versione v0.13.3 indicano la consegna tramite chat per le automazioni degli agenti. Prima di affidarti a una destinazione diversa dalla chat, verifica le opzioni della versione corrente.

Cosa devo fare se due esecuzioni si sovrappongono?

Usa worktree separati oppure scegli una pianificazione e un limite di esecuzione che evitino sovrapposizioni. Prima di fidarti del report di un’esecuzione che ha usato la revisione sbagliata, esaminala.

Conclusione

Usa un terminale, una directory di lavoro dedicata e un piccolo job che produca solo report per convalidare l’intero flusso. Verifica il provider del modello, prova sia un esito positivo sia uno negativo e tieni le credenziali di produzione fuori dal terminale. Una volta ottenuto un risultato ripetibile, la stessa configurazione può gestire controlli ricorrenti dei repository.