Gérer les automatisations d’OpenClaw

Une fois les tâches créées, quelqu’un doit les lister, les relancer, lire leur historique et les modifier sans casser leur modèle d’autorité. La gestion des automatisations d’OpenClaw est une CLI à une poignée de verbes, un chemin conversationnel pour les administrateurs dans l’interface de contrôle, et un petit jeu de clés de configuration. Voici les recettes de la documentation, les deux chemins de gestion et leurs règles d’autorité, la sémantique de l’historique qui explique une tâche qui a tourné sans livrer, les règles d’options, les notes sur la surcharge de modèle, la configuration, et le comportement des relances et de la rétention.

Recettes et chemins

• Cinq recettes : une vérification d’agenda ponctuelle dans vingt minutes comme événement système de session principale avec réveil immédiat ; une note matinale isolée récurrente à sept heures dans un fuseau, annoncée sur un canal Slack ; une analyse hebdomadaire approfondie avec un modèle et une réflexion élevée ; un condensé des déploiements en semaine publié sur un webhook ; et une sonde de profondeur de file lançant une commande toutes les quinze minutes et annonçant sur une conversation Telegram.
• Dans l’interface de contrôle authentifiée, un administrateur peut demander à l’agent de lister, inspecter, modifier, lancer ou retirer toute automatisation de la passerelle quel que soit son créateur ou son canal ; la passerelle accorde cela à partir des faits d’admission du tour sous forme d’autorisation à usage unique qui expire après soixante secondes et reste liée à l’exécution active, les tours de canaux et les tours non administrateurs n’en reçoivent aucune, et chaque requête est journalisée avec sa méthode, son exécution et son issue.
• La CLI liste les tâches activées ou toutes, obtient une tâche en JSON, l’affiche avec sa route de livraison résolue, active et désactive sans supprimer, modifie, force une exécution immédiate, attend une exécution forcée avec un délai et un intervalle de sondage et ne sort à zéro que sur un achèvement réussi, ne lance que si l’échéance est due, consulte l’historique ou une exécution exacte, retire, et choisit ou efface l’agent sur les hôtes multi-agents ; la correction du doctor répare les tâches anciennes sans métadonnées de créateur seulement quand l’identité stockée prouve le compte.
• Archiver une session désactive toutes les tâches activées qui lui sont liées, sa session isolée par tâche, une cible de session ou une voie de livraison ou de réveil, restaurer la session ne les réactive pas, et les sessions dotées d’une tâche liée activée montrent un badge d’horloge dans la barre latérale.

L’autorité de gestion ne transfère pas l’attribution du créateur et ne remplace pas la politique d’exécution planifiée de la tâche.

Historique et options

La livraison d’une exécution immédiate mesure le retard depuis l’acceptation de la demande manuelle, donc un ancien créneau planifié en attente ne rend pas périmée une sortie fraîche, et une exécution manuelle préserve la cadence récurrente. L’historique garde l’exécution de la charge dans un état ok, erreur ou sautée et l’achèvement de toute l’exécution dans un état d’achèvement réussi, échoué ou inconnu : la livraison demandée est requise sauf si la tâche opte explicitement pour au mieux, un échec de livraison seule laisse l’exécution ok sans toucher aux compteurs d’erreurs ni au recul tout en enregistrant un achèvement échoué, et un envoi d’adaptateur sans identité de livraison reste inconnu sans renvoi automatique. Le silence volontaire, la sortie vide, les accusés de réception du battement de cœur et les transformations de réponse des canaux enregistrent une raison de suppression sans prétendre à une livraison, les tâches ponctuelles qui se terminent ainsi sont supprimées normalement, et les tâches ponctuelles retenues ne se relancent jamais seules. L’outil d’automatisations de l’agent renvoie des résumés compacts, identifiant, nom, activation, agent effectif, prochaine exécution, type de planning et dernière exécution, avec une action de lecture pour une définition complète, et les appelants directs peuvent demander la forme compacte à l’appel de liste. Créer est un alias d’ajouter et accepte un planning et un prompt en position ; une option de webhook ne se combine pas avec les options de livraison par chat ; à la modification, des options d’effacement retirent individuellement le canal, le destinataire, le fil et le compte, distinctes de l’option sans livraison qui ne désactive que la livraison de repli de l’exécuteur. Notes sur le modèle : l’option de modèle fixe le modèle principal de la tâche et les chaînes de repli configurées s’appliquent encore, un modèle non autorisé ou non résolu fait échouer l’exécution avec une erreur de validation, l’option de replis remplace la chaîne configurée pour cette tâche et une valeur vide rend l’exécution stricte, des options d’effacement retirent l’une ou l’autre surcharge, et un modèle seul sans liste de replis ne retombe jamais sur le modèle principal de l’agent comme relance cachée.

Configuration et rétention

• Clés : activation, un réglage des déclencheurs qui bascule ensemble les scripts de condition, les charges de script et les sources de flux, un jeton de webhook envoyé en en-tête porteur puisque les URL ne doivent pas embarquer d’identifiants, la politique SSRF des webhooks qui est stricte quand elle est omise, et une rétention de session de vingt-quatre heures par défaut pour les sessions d’exécution isolées ; les tâches, l’historique et les tâches malformées en quarantaine vivent dans la base SQLite partagée et l’ancienne clé de magasin est retirée.
• Un réglage de saut des tâches manquées fait avancer les tâches récurrentes cron et à intervalle à leur prochaine occurrence future après une mise hors ligne de la passerelle au lieu de rattraper, au prix de l’abandon du travail manqué, tandis que les tâches ponctuelles gardent leur rattrapage dans tous les cas ; les automatisations peuvent être désactivées entièrement par la clé d’activation ou une variable d’environnement.
• Les relances des tâches ponctuelles suivent un calendrier intégré pour les erreurs passagères tandis que les erreurs permanentes désactivent la tâche immédiatement ; les erreurs d’exécution récurrentes reculent à trente secondes, une minute, cinq, quinze et soixante, avec réinitialisation après le succès suivant. L’historique terminal est conservé sept jours, les lignes perdues vingt-quatre heures, avec les deux mille lignes les plus récentes par tâche et classe d’historique comme plafond, et la correction du doctor importe les anciens fichiers JSON de tâches, d’état, de quarantaine et d’exécutions dans SQLite en archivant les originaux.

Les automatisations d’OpenClaw est le guide sur lequel ces verbes opèrent, et OpenClaw doctor la commande qui répare les métadonnées de créateur, les retraits de modèles et les anciens magasins.

Où vont les enregistrements

Chaque exécution d’automatisation atterrit aussi en silence dans le registre des tâches d’arrière-plan, et une tâche liée à une session suit l’état d’archivage de cette session. Les tâches d’arrière-plan d’OpenClaw est ce registre, et Les sessions d’OpenClaw explique les règles d’identité d’archivage et de restauration qui décident si les tâches liées reviennent.

Sur Diali

Sur Diali, l’écran des automatisations du tableau de bord est la surface de gestion, les tâches et leur historique vivent dans la base d’état de l’assistant sur son volume, et les valeurs de rétention et de relance sont celles de l’amont. OpenClaw hébergé sur Diali est l’assistant et Le basculement de modèle d’OpenClaw la chaîne par laquelle un modèle par tâche se replie encore.

• Les autorisations d’administration durent soixante secondes et se lient à une exécution.
• L’état est la charge ; l’état d’achèvement est toute l’exécution.
• Sept jours d’historique, deux mille lignes par tâche.