OpenClaw : Si votre tâche ne survit pas à un redémarrage, c’est encore une session de discussion

Un post sur r/clawdbot fait une observation pertinente sur les workflows OpenClaw : si votre tâche ne peut pas survivre à un redémarrage, ce n'est toujours qu'une session de chat. L'auteur soutient que traiter l'historique de conversation comme la source de vérité pour un travail de longue durée est une recette pour l'échec.

Pourquoi l'historique de chat n'est pas l'état de la tâche

L'historique de chat peut aider à expliquer ce qui s'est passé, mais il ne devrait pas être la source de vérité pour un travail durable. Lorsque la passerelle redémarre, que le modèle devient indisponible ou qu'un worker échoue en plein milieu d'une tâche, vous avez besoin d'un enregistrement qu'un autre worker peut lire et sur lequel agir immédiatement.

Le post décrit ce que chaque tâche sérieuse doit stocker en dehors de la conversation :

• Identité stable — un ID unique pour la tâche
• Étape actuelle — où elle en est dans le flux de travail
• Résultat attendu — ce à quoi ressemble "terminé"
• État d'approbation — si les approbations utilisateur/automatisées sont en attente ou accordées
• Exceptions — ce qui a mal tourné, le cas échéant
• Preuves — journaux, résultats ou sorties collectés jusqu'à présent
• Prochaine action sûre — l'action précise à entreprendre lors de la reprise

Le choix de la base de données est moins important que le comportement. N'importe quel stockage persistant fonctionne tant qu'il est stable et interrogeable.

Le vrai problème : les effets secondaires externes

Cela devient critique lorsque le flux de travail touche un système externe. Si un e-mail, un déploiement ou une publication a été tenté avant une interruption, une nouvelle tentative naïve peut entraîner des messages en double, des publications en double ou des actions destructrices répétées.

La solution est de se réconcilier avec le fournisseur avant de réessayer. Cela signifie vérifier auprès du service externe (comme une API e-mail, une plateforme de déploiement ou un éditeur de contenu) si l'action a réellement réussi ou est toujours en attente — puis décider de la prochaine étape sûre.

Un test pratique pour la reprise

Le post suggère une expérience simple :

1. Arrêtez un workflow immédiatement après son premier effet secondaire externe (par exemple, juste après l'envoi d'un e-mail).
2. Redémarrez OpenClaw.
3. Observez ce qui se passe.

Peut-il distinguer entre :

• Terminé — l'effet secondaire s'est produit avec succès
• Tenté — il a essayé mais a échoué
• Échoué — il a généré une erreur
• Inconnu — on ne sait pas clairement ce qui s'est passé

Peut-il reprendre à partir de la prochaine action sûre sans rejouer toute la conversation ? Si non, le workflow n'est pas réellement reprenable — il espère simplement que la transcription reste disponible.

En résumé

Pour les développeurs qui construisent des automatisations OpenClaw robustes, la leçon est claire : stockez l'état de la tâche en externe et concevez des flux de récupération qui tiennent compte des effets externes incertains. Le post vous met au défi de réfléchir à si vos workflows passeraient le test de redémarrage.

Le fil original sur r/clawdbot comprend une section de commentaires où les développeurs partagent leurs approches — à lire si vous construisez des workflows d'agents de production.