Les tâches d’arrière-plan d’OpenClaw

Le travail qui tourne hors de votre conversation principale, une exécution ACP, un lancement de sous-agent, une tâche d’automatisation, une opération lancée par la CLI, a besoin d’un endroit où être vu. Les tâches d’arrière-plan d’OpenClaw sont cet endroit : un registre d’activité qui enregistre quel travail détaché a eu lieu, quand, et s’il a réussi, sans remplacer les sessions, les automatisations ni les battements de cœur, qui décident quand le travail s’exécute. Voici ce qui crée une tâche, le cycle de vie et l’état perdu conscient de l’environnement, pourquoi la livraison est suivie à part de l’exécution, les chemins et politiques de notification, les commandes de récupération, et les règles d’audit et de maintenance.

Ce qui crée une tâche

• Les exécutions ACP d’arrière-plan quand une session enfant ACP est lancée, l’orchestration de sous-agents quand un sous-agent est lancé, chaque exécution d’automatisation, en session principale ou isolée, les commandes d’agent qui passent par la passerelle, et les générations d’images, de musique et de vidéo adossées à une session ; les tours de battement de cœur, le chat interactif normal et les réponses directes aux commandes n’en créent pas.
• Les politiques de notification par défaut diffèrent : les tâches ACP et de sous-agents ne rapportent que l’état terminal, tandis que les tâches d’automatisation, de CLI et de médias sont silencieuses, puisque le planificateur possède son propre chemin de livraison et que l’achèvement des médias est rendu à la session demandeuse comme un réveil interne, avec un repli direct idempotent des médias manquants vers le canal d’origine si ce réveil échoue.
• Tant qu’une tâche de génération de médias est active, répéter le même prompt renvoie l’état de la tâche active au lieu de lancer un doublon, un prompt distinct lance sa propre tâche, et une action d’état donne une consultation explicite de la progression.
• Les enregistrements terminaux sont conservés sept jours, les enregistrements perdus vingt-quatre heures, puis purgés automatiquement ; la liste des tâches montre tout du plus récent au plus ancien avec des filtres d’environnement et d’état, et la commande des tâches sans argument se comporte comme la liste.

Les tâches sont des enregistrements, pas des planificateurs : les automatisations et le battement de cœur décident quand le travail s’exécute, les tâches consignent ce qui s’est passé.

Cycle de vie et livraison

Chaque tâche passe de en file à en cours puis à un état terminal, réussie, échouée, expirée, annulée ou perdue, sous l’effet automatique des événements de cycle de vie de l’exécution, et une fois terminale, un signal ultérieur ne la rétrograde jamais. Perdu est conscient de l’environnement : une tâche ACP n’est vivante que tant qu’un tour vivant existe dans le processus de la passerelle, une tâche de sous-agent est perdue quand sa session enfant a disparu ou porte une pierre tombale de récupération après redémarrage, une tâche d’automatisation vérifie d’abord l’historique durable des exécutions avant d’être marquée perdue, et une tâche CLI avec identité d’exécution vérifie le contexte d’exécution vivant plutôt que des lignes de session qui traînent. Exécution et livraison du résultat sont séparées : une tâche de sous-agent peut rester réussie tandis que sa livraison est en file ou échouée, et l’issue terminale est réussie après livraison et bloquée quand le travail est fini mais que le résultat n’a pas pu être rendu, ce qui préserve le résultat au lieu de signaler à tort l’enfant comme échoué ; les tâches bloquées apparaissent sous les filtres bloqué et réussi. La livraison est poussée : la livraison directe va droit au canal demandeur quand la tâche a une origine, les achèvements de groupe et de canal étant routés par la session demandeuse pour que l’agent parent écrive la réponse visible, et la livraison par session, utilisée quand la livraison directe échoue ou qu’aucune origine n’existe, fait apparaître la mise à jour comme événement système au prochain battement de cœur, qu’elle réveille immédiatement. Les transferts durables d’achèvement de sous-agents sont relancés jusqu’à trente minutes avec un recul plafonné ; quand la livraison atteint son échéance, la tâche montre une issue bloquée et garde son résultat sept jours, et une relance démarre une nouvelle génération de livraison clôturée tandis qu’un abandon enregistre une non-livraison volontaire. Avec une origine publique configurée et l’interface de contrôle activée, les notifications directes portent un lien d’inspection vers la session propre de la tâche.

Politiques, audit, maintenance

• Trois politiques de notification : fin seulement, le défaut pour ACP et les sous-agents, qui ne livre que l’état terminal ; changements d’état, qui livre chaque transition et mise à jour de progression ; et silencieuse, le défaut pour les tâches d’automatisation, de CLI et de médias ; la politique peut changer pendant qu’une tâche tourne, et les notifications restent avec l’agent demandeur enregistré même sous une portée de session globale.
• L’audit des tâches fait remonter les problèmes des tâches et des flux dans un seul rapport et dans la commande d’état : en file depuis plus de dix minutes, en cours depuis plus de trente, propriété perdue, livraison échouée sous une politique non silencieuse, une tâche terminale sans horodatage de nettoyage, et des violations de chronologie ; les constats de flux ajoutent les restaurations de registre échouées, les flux en cours, en attente ou bloqués périmés, les annulations coincées après cinq minutes, les tâches liées manquantes et les identifiants de tâches bloquées pendants.
• La maintenance prévisualise ou applique la réconciliation, l’estampillage de nettoyage et la purge : seul le processus de la passerelle fait autorité sur la vivacité, donc un audit CLI hors ligne ne récupère jamais les tâches ACP et ne marque pas une tâche d’automatisation perdue seulement parce que son ensemble local en mémoire est vide ; l’annulation n’interrompt que l’exécution vivante choisie et ses approbations en attente et ne rapporte un succès qu’une fois qu’elle est réglée, et le nettoyage d’achèvement ferme au mieux les onglets et processus de navigateur suivis pour la session enfant tandis que la livraison d’automatisation isolée attend la fin du travail des sous-agents descendants et supprime les accusés de réception périmés du parent.

Task Flow dans OpenClaw est l’enregistrement d’orchestration qui coordonne plusieurs de ces tâches, et Le battement de cœur d’OpenClaw le tic que réveillent les achèvements mis en file dans la session.

L’habitude du push

La conclusion de la documentation est une habitude de travail : lancez le travail détaché une fois, puis laissez l’environnement vous réveiller ou vous notifier à l’achèvement, et ne consultez l’état des tâches que pour le débogage, une intervention ou un audit explicite. Les sous-agents d’OpenClaw couvre les lancements qui remplissent l’essentiel de ce registre, et Les automatisations d’OpenClaw les tâches dont chaque exécution y atterrit en silence.

Sur Diali

Sur Diali, le registre des tâches tourne avec les valeurs amont par défaut, sept jours d’enregistrements terminaux sur le volume de l’assistant, et les avis d’achèvement atteignent le canal depuis lequel le travail a été demandé. OpenClaw hébergé sur Diali est l’assistant et Les sessions d’OpenClaw la session demandeuse à laquelle un achèvement mis en file revient.

• Un registre, pas un planificateur.
• Réussie peut rester bloquée ; la livraison est suivie à part.
• Pousser, ne pas interroger ; auditer quand quelque chose paraît périmé.