Task Flow dans OpenClaw

Une seule tâche d’arrière-plan a besoin d’un enregistrement de tâche ; une chaîne en plusieurs étapes a besoin de quelque chose qui se souvient d’où elle en est à travers les redémarrages. Task Flow d’OpenClaw est cette couche : un flux est un enregistrement durable d’un travail en plusieurs étapes avec son propre état, son JSON d’état, son compteur de révisions et ses enregistrements de tâches liés, il survit aux redémarrages de la passerelle, et les tâches individuelles restent l’unité du travail détaché. Voici quand en utiliser un, les modes de synchronisation géré et miroir, les états, comment l’état et les révisions sont stockés, comment l’annulation se règle, la CLI, et le schéma de la documentation pour un flux planifié fiable.

Quand et comment

• Une seule tâche d’arrière-plan est une tâche ordinaire, une chaîne en plusieurs étapes pilotée par du code d’extension est un flux géré, un lancement détaché ACP ou de sous-agent reçoit un flux miroir créé automatiquement, et un rappel ponctuel est une tâche d’automatisation.
• Un flux géré a un contrôleur : du code d’extension crée le flux avec un but et un identifiant de contrôleur et le pilote explicitement. Créer un flux géré crée un état, pas une exécution, lier une tâche lie une exécution existante au lieu d’en lancer une, le contrôleur passe entre les états en cours, en attente et terminaux en gardant des identifiants, résumés et curseurs bornés dans le JSON d’état, et chaque transition, mise en attente, reprise, fin, échec et demande d’annulation, exige la dernière révision attendue, donc chaque résultat doit être vérifié.
• Le travail enfant est lancé par son environnement pris en charge avant d’être lié, et la liaison exige la tâche de support existante qui fait autorité, son identifiant d’exécution canonique et sa clé de session enfant, le bon environnement et la même session propriétaire ; une clé de session copiée ou un identifiant d’exécution inventé ne font pas autorité. Pour les sous-agents d’extensions adossés à la passerelle, le chemin public est l’exécution de sous-agent de l’environnement avec livraison d’achèvement au demandeur courant dans un vrai hook de distribution lié au demandeur, et l’hôte crée la tâche canonique et le flux miroir.
• Un flux miroir est créé automatiquement quand une exécution détachée ACP ou de sous-agent démarre : il reflète sa seule tâche de support, état, but et chronologie, en donnant aux lancements détachés une poignée stable pour les surfaces d’état et de relance sans contrôleur, et affiche le mode de synchronisation miroir de tâche dans la CLI.

Les flux coordonnent les tâches, ils ne les remplacent pas.

États, état durable, annulation

Huit états : en file, en cours, en attente quand un flux géré est garé sur des métadonnées d’attente comme un minuteur ou un événement externe, bloqué, réussi, échoué, annulé une fois une annulation demandée et tous les enfants réglés, et perdu quand le flux a perdu son état de support faisant autorité. Bloqué est le seul état dont le sens terminal dépend de l’enregistrement : un flux géré sans heure de fin reste reprenable, tandis qu’un flux bloqué avec une heure de fin est terminé, y compris les flux miroirs dont la tâche de support s’est terminée bloquée. Les enregistrements persistent dans la base d’état SQLite partagée à côté des tâches, chaque écriture incrémente la révision, une révision attendue périmée obtient un conflit et doit relire, et un ancien registre annexe est importé par la commande doctor. La durabilité couvre les enregistrements, pas une pile d’appels JavaScript ni une planification automatique : après un redémarrage, le contrôleur propriétaire recharge le flux, vérifie l’annulation et l’état terminal, réconcilie les issues des enfants et reprend explicitement depuis la dernière révision, les métadonnées d’attente seules n’enregistrent aucun minuteur, et les effets de bord ne sont jamais rejoués aveuglément après un conflit. Les flux terminés sont conservés sept jours, les flux bloqués reprenables sans limite d’âge. Annuler pose une intention collante, annule les enfants actifs, refuse de nouveaux enfants gérés, et finalise en annulé une fois qu’aucun enfant n’est actif, immédiatement ou par le balayage de maintenance, et l’intention survit à un redémarrage.

CLI et schéma de flux

• Les commandes de flux listent les flux suivis avec mode de synchronisation, état, révision, contrôleur et nombre de tâches, montrent un flux par identifiant ou clé de propriétaire avec ses tâches liées, et annulent un flux en cours et ses tâches actives ; les flux sont aussi couverts par l’audit des tâches pour les constats périmés ou cassés et par la maintenance des tâches, qui finalise les annulations coincées et purge les flux terminaux après sept jours.
• Pour les flux récurrents comme une note de veille de marché, la documentation sépare quatre couches : les automatisations pour le temps, une session d’automatisation persistante quand le flux doit s’appuyer sur le contexte antérieur, l’outil Lobster facultatif pour les étapes déterministes, les points d’approbation et les jetons de reprise, et Task Flow pour suivre l’exécution à travers les tâches enfants, les attentes, les relances et les redémarrages. L’outil Lobster peut exécuter un flux avec un identifiant de contrôleur et un but, enregistre une vraie pause d’approbation comme attente, et renvoie une mutation dont l’indicateur d’application et l’enregistrement post-mutation fournissent la prochaine révision attendue.
• Dans le flux, les vérifications de fiabilité précèdent l’étape de résumé par le modèle : une pré-vérification de la disponibilité et du profil du navigateur, des identifiants et des quotas, de la joignabilité du réseau, des outils requis et d’une destination d’échec configurée, des champs de provenance sur chaque élément collecté avec une URL source, une heure de récupération et une date de validité, le rejet des éléments périmés avant le résumé, et une étape de modèle validée par schéma qui doit préserver ces champs.

Les tâches d’arrière-plan d’OpenClaw est le registre du travail détaché qu’un flux coordonne, et Les automatisations d’OpenClaw la couche de temps qui l’alimente.

Où il se place

Un flux ne remplace ni les tâches, ni les sessions, ni les automatisations, ni les objectifs ; il donne à une exécution en plusieurs étapes une poignée durable dont la révision la protège de deux écrivains. Les sous-agents d’OpenClaw explique les lancements détachés qui reçoivent des flux miroirs, et OpenClaw doctor la commande qui importe un ancien registre de flux dans la base partagée.

Sur Diali

Sur Diali, les enregistrements de flux vivent dans la base d’état de l’assistant sur son volume et survivent aux releases comme le reste de son état, et la couche de temps est faite des automatisations que vous créez depuis le tableau de bord. OpenClaw hébergé sur Diali est l’assistant et Les objectifs de session d’OpenClaw l’objectif par session qui se place à côté d’un flux plutôt qu’à l’intérieur.

• Un enregistrement durable avec une révision, pas une pile d’appels.
• Les flux gérés ont un contrôleur ; les flux miroirs ont une tâche.
• L’annulation est collante ; bloqué a deux sens.