Comment planifier un agent de programmation dans Open WebUI sur un serveur domestique

Open WebUI v0.13.3 peut planifier l’exécution d’un agent de programmation sur un terminal et dans un répertoire de travail sélectionnés. Commencez par une tâche de compte rendu uniquement dans une copie de travail jetable : exécutez une commande de test connue, résumez les échecs et envoyez le résultat dans une discussion. Ce test vérifie le planificateur, les autorisations et le circuit de transmission avant d’accorder à une tâche récurrente l’accès à des fichiers importants.

Vous avez besoin d’une installation compatible d’Open WebUI, d’une intégration de terminal accessible proposant l’agent souhaité et d’un espace de travail accessible. Les notes de version de v0.13.3 indiquent que les exécutions planifiées vérifient que le terminal et l’agent enregistrés sont toujours disponibles. Considérez le terminal, le système de fichiers et la connexion au modèle sous-jacente comme des éléments distincts de la configuration.

Qu’est-ce que la version de novembre a changé ?

L’éditeur d’automatisations permet de sélectionner un terminal et un répertoire, puis de choisir un agent proposé par ce terminal. Le terminal et le dossier configurés sont repris lors de l’exécution planifiée. Les résultats des automatisations d’agents sont envoyés dans une discussion, tandis que les autres types d’automatisation peuvent proposer d’autres options de destination. La précédente version v0.13.1 a ajouté les agents de programmation au sélecteur de modèles lorsqu’un terminal connecté les propose.

Un terminal sélectionné peut s’exécuter sur le même hôte qu’Open WebUI ou être un service distinct accessible. Pour la tâche, c’est le système de fichiers du terminal qui compte. Un répertoire visible sur votre ordinateur portable peut être absent d’un conteneur. Un fichier accessible à un terminal peut ne pas exister dans un autre. Vérifiez le chemin dans le terminal exact sélectionné pour l’automatisation.

Comment préparer l’espace de travail ?

Créez une copie de test dédiée, idéalement pour un petit dépôt sans secrets de production. Figez une révision connue et incluez dans la configuration un test inoffensif qui réussit et un test dont l’échec est connu. Pour le premier rapport, exposez la copie de travail d’entrée en lecture seule si le lanceur de tests le permet. Prévoyez un emplacement temporaire accessible en écriture pour les caches et les journaux de test. Certains outils de compilation exigent d’écrire dans l’arborescence : configurez-les pour écrire ailleurs ou utilisez une copie jetable accessible en écriture.

Si plusieurs tâches partagent un dépôt, créez un arbre de travail pour chaque agent ou tâche. Gardez les sauvegardes et le répertoire de travail séparés. Lisez pourquoi les sauvegardes peuvent échouer en cas d’accès partagé avant d’accorder à une tâche de larges permissions d’écriture sur un serveur de fichiers.

Comment configurer la première tâche planifiée ?

Ouvrez l’éditeur d’automatisation dans une version qui inclut l’automatisation des agents. Sélectionnez votre terminal, choisissez le répertoire visible depuis ce terminal, puis sélectionnez l’agent. Pour le premier test, planifiez une exécution unique à une date proche si votre installation propose cette option. Consultez l’horaire dans le fuseau horaire configuré. Définissez une durée ou un nombre d’étapes modéré à l’aide des commandes disponibles pour votre agent et votre déploiement.

Donnez à la tâche une entrée, une commande et un format de résultat précis. Par exemple :

Examinez le dépôt extrait dans le répertoire de travail sélectionné.
Exécutez une fois la commande locale de test rapide existante.
Indiquez la commande, le code de sortie et le premier test en échec.
Si la commande ou le dossier n’est pas disponible, signalez cet échec.
N’installez pas de dépendances, ne modifiez pas le dépôt et ne contactez pas de services externes.

Les instructions guident l’agent. Définissez séparément les limites d’accès au système de fichiers et au réseau à l’aide de la configuration du terminal et du conteneur. Vérifiez qu’une dépendance manquante provoque un échec explicite plutôt qu’une installation inattendue. La documentation d’Open WebUI est le point de départ pour configurer le terminal et les paramètres administrateur.

Que vérifier après la première exécution ?

Ouvrez la conversation obtenue et vérifiez l’identité de l’agent, le chemin de travail, la commande de test, le code de sortie et la révision testée. Comparez le résultat à une exécution manuelle de la même commande dans ce terminal. Une automatisation terminée indique uniquement que le flux de travail s’est achevé. Le rapport doit encore prouver que le test prévu a bien été exécuté.

Testez délibérément un scénario d’échec. Indiquez à une tâche de test une entrée inoffensive inexistante ou arrêtez brièvement le terminal jetable, puis observez l’état obtenu. Rétablissez la situation après le test. Un opérateur doit pouvoir distinguer un agent indisponible, un répertoire manquant, un test échoué et un délai d’expiration du modèle sans lire tout l’historique de discussion. Vérifiez que la prochaine exécution légitime ne réutilise pas silencieusement des résultats obsolètes.

L’auto-hébergement d’Open WebUI permet-il de garder le code en local ?

Open WebUI et son terminal peuvent être auto-hébergés, tandis que l’agent de programmation sélectionné utilise un modèle distant. Déterminez où l’agent envoie les invites système, les extraits de fichiers et les journaux de test. Vérifiez la configuration de son fournisseur avant de connecter un dépôt privé. Stockez les identifiants du fournisseur dans la configuration des secrets prévue à cet effet dans le service et évitez de les partager dans les invites ou les journaux.

Commencez par un point de terminaison de modèle local si vos exigences interdisent tout traitement externe. Vérifiez le point de terminaison et la configuration de secours de l’agent, puis examinez les restrictions réseau qui s’appliquent au terminal. Pour en savoir plus sur la réduction des risques d’exposition, consultez ce guide sur le triage des vulnérabilités par l’IA et les secrets.

Comment transformer une tâche de génération de rapport en flux de travail récurrent ?

Une fois que vous comprenez les premières exécutions réussies et celles qui ont échoué, ajoutez un calendrier récurrent qui ne chevauche aucune autre tâche utilisant le même répertoire. Attribuez un horodatage et une révision du dépôt aux rapports. Gardez les alertes simples : signalez les échecs qui nécessitent une intervention et conservez suffisamment de contexte pour pouvoir les reproduire. Vérifiez régulièrement que les identifiants de l’agent, la connectivité du terminal et le répertoire planifié fonctionnent toujours après les mises à niveau.

Si vous autorisez ensuite l’application de correctifs, gardez-les dans une branche isolée et exigez une révision avant leur fusion. Une nouvelle tentative planifiée pourrait sinon reproduire les effets de bord. Une tâche de génération de rapport est plus facile à relancer, car elle ne fait qu’écrire un résultat, tandis que les mises à jour de dépendances et les commandes de déploiement modifient l’état du système. Considérez ce changement comme une décision distincte en matière d’autorisations.

FAQ

Quelle version a ajouté les automatisations d’agent ?

La fonctionnalité concernée figure dans Open WebUI v0.13.3. La fonctionnalité de sélection d’agent de la v0.13.1 est liée, mais distincte.

Pourquoi l’agent n’apparaît-il pas dans le sélecteur ?

Vérifiez que le terminal sélectionné est accessible et qu’il indique prendre en charge cet agent, et que votre version installée ainsi que les autorisations de votre compte donnent accès à cette fonctionnalité.

Puis-je choisir un dossier sur mon ordinateur portable ?

Choisissez un chemin sur le terminal qui exécutera réellement la tâche. Montez-y le dépôt ou copiez-le à cet emplacement au préalable, si nécessaire.

Le résultat d’une automatisation est-il envoyé dans un canal ?

Les notes de version de la v0.13.3 indiquent que les automatisations d’agent envoient les résultats dans le chat. Vérifiez les options de la version actuelle avant de compter sur une destination autre que ce chat.

Que faire si deux exécutions se chevauchent ?

Utilisez des worktrees distincts ou choisissez un horaire et une durée d’exécution qui évitent les chevauchements. Avant de vous fier à son rapport, inspectez toute exécution qui a utilisé la mauvaise révision.

Conclusion

Utilisez un seul terminal, un répertoire de travail dédié et une petite tâche limitée à la génération d’un rapport pour valider l’ensemble du processus. Vérifiez le fournisseur du modèle, testez les cas de réussite et d’échec, et gardez les identifiants de production hors du terminal. Une fois le résultat reproductible, la même configuration peut effectuer des vérifications récurrentes du dépôt.