Quand utiliser un flux de tâches
Modes de synchronisation
Mode géré
Un flux géré dispose d’un contrôleur : du code de plugin qui crée le flux par l’intermédiaire de l’API d’exécution de flux de tâches du plugin, avec un objectif et un identifiant de contrôleur obligatoire, puis le pilote explicitement.- Chaque étape s’exécute comme une tâche en arrière-plan créée sous le flux ; la clé de propriétaire et l’origine du demandeur du flux sont transmises aux tâches enfants.
- Le contrôleur fait progresser le flux entre les états
running,waitinget les états terminaux, et stocke un état d’étape JSON arbitraire dans l’enregistrement du flux. - Chaque modification transmet la révision attendue du flux. Une écriture obsolète est rejetée comme conflit de révision au lieu d’écraser un état plus récent.
- Dès qu’une annulation est demandée, les nouvelles tâches enfants sont refusées et le flux se termine avec l’état
cancelledlorsqu’aucune tâche enfant ne reste active.
Mode répliqué
OpenClaw crée automatiquement un flux répliqué à une seule tâche lorsqu’une exécution détachée d’ACP ou de sous-agent démarre (tâches limitées à la session avec achèvement livrable). L’enregistrement du flux réplique son unique tâche sous-jacente — état, objectif et chronologie — afin que les lancements détachés disposent d’un identifiant de flux stable pour les interfaces d’état et de nouvelle tentative, sans contrôleur. Les flux répliqués affichent le mode de synchronisationtask_mirrored dans la CLI.
États des flux
État durable et suivi des révisions
Les enregistrements de flux sont conservés dans la base de données d’état SQLite partagée (~/.openclaw/state/openclaw.sqlite, table flow_runs) avec les enregistrements de tâches, afin que la progression survive aux redémarrages du Gateway. Chaque écriture incrémente la revision du flux ; les auteurs concurrents qui transmettent une révision attendue obsolète rencontrent un conflit et doivent relire l’enregistrement. La croissance du WAL est limitée par les points de contrôle automatiques de SQLite, auxquels s’ajoutent des points de contrôle passifs périodiques et des points de contrôle avec troncation lors de l’arrêt. L’ancien fichier annexe flows/registry.sqlite des installations antérieures est importé par openclaw doctor.
Comportement d’annulation
openclaw tasks flow cancel définit une intention d’annulation persistante sur le flux, annule ses tâches enfants actives et refuse les nouvelles tâches enfants gérées. Lorsqu’aucune tâche enfant ne reste active, le flux se termine avec l’état cancelled — immédiatement, ou par l’intermédiaire du balayage de maintenance si les tâches enfants mettent plus de temps à se terminer. L’intention est conservée, de sorte qu’un flux annulé reste annulé même si le Gateway redémarre avant la fin de toutes les tâches enfants.
Commandes CLI
Les flux sont également couverts par
openclaw tasks audit (détection des flux obsolètes ou défectueux) et openclaw tasks maintenance (finalise les annulations bloquées et supprime les flux terminaux après 7 jours).
Modèle fiable de workflow planifié
Pour les workflows récurrents tels que les synthèses de veille commerciale, traitez la planification, l’orchestration et les contrôles de fiabilité comme des couches distinctes :- Utilisez les tâches planifiées pour la planification temporelle.
- Utilisez une session Cron persistante lorsque le workflow doit s’appuyer sur le contexte antérieur.
- Utilisez Lobster pour les étapes déterministes, les points de validation et les jetons de reprise.
- Utilisez un flux de tâches pour suivre l’exécution en plusieurs étapes à travers les tâches enfants, les attentes, les nouvelles tentatives et les redémarrages du Gateway.
--session session:<id> plutôt que isolated lorsque le workflow récurrent nécessite délibérément un historique, les résumés des exécutions précédentes ou un contexte permanent. Utilisez isolated lorsque chaque exécution doit repartir de zéro et que tout l’état requis est explicitement défini dans le workflow.
Dans le workflow, placez les contrôles de fiabilité avant l’étape de synthèse par le LLM :
- Disponibilité du navigateur et choix du profil, par exemple
openclawpour un état géré ouuserlorsqu’une session Chrome authentifiée est requise. Consultez Navigateur. - Identifiants d’API et quota pour chaque source.
- Accessibilité réseau des points de terminaison requis.
- Outils requis activés pour l’agent, tels que
lobster,browseretllm-task. - Destination d’échec configurée pour Cron afin que les échecs des contrôles préalables soient visibles. Consultez les tâches planifiées.
sourceUrl, retrievedAt et asOf dans sa sortie. Utilisez Tâche LLM lorsqu’une étape de modèle validée par un schéma est nécessaire dans le workflow.
Pour les workflows réutilisables par une équipe ou une communauté, regroupez la CLI, les fichiers .lobster et les éventuelles notes de configuration sous forme de skill ou de plugin, puis publiez l’ensemble par l’intermédiaire de ClawHub. Conservez les garde-fous propres au workflow dans ce paquet, sauf si l’API du plugin ne fournit pas une fonctionnalité générique nécessaire.
Relation entre les flux et les tâches
Les flux coordonnent les tâches, ils ne les remplacent pas. Un même flux peut piloter plusieurs tâches en arrière-plan au cours de son cycle de vie. Utilisezopenclaw tasks pour examiner les enregistrements de tâches individuels et openclaw tasks flow pour examiner le flux qui les orchestre.
Ressources associées
- Tâches en arrière-plan — le registre du travail détaché coordonné par les flux
- CLI : tâches — référence des commandes CLI pour
openclaw tasks flow - Vue d’ensemble de l’automatisation — tous les mécanismes d’automatisation en un coup d’œil
- Tâches Cron — tâches planifiées pouvant alimenter les flux