La livraison des automatisations d’OpenClaw

Une tâche qui a parfaitement tourné sans le dire à personne est une tâche qui n’a pas tourné, pour autant qu’on puisse le savoir. La couche de livraison d’OpenClaw décide où une exécution terminée envoie sa sortie, ce qui compte comme livré, et comment les échecs sont signalés sans inonder le canal. Voici les trois modes et la sémantique de validation des tâches de session courante, la garde des webhooks, la syntaxe des cibles, la règle de partage entre les envois propres de l’agent et le repli de l’exécuteur, la politique d’alertes d’échec avec ses incidents et ses avis de rétablissement, et les deux règles qui piègent, échec de livraison contre échec d’exécution et langue de réponse.

Modes et validations

• Annonce livre en repli le texte final à la cible si l’agent ne l’a pas envoyé lui-même, webhook publie la charge d’événement terminée vers une URL, et aucun ne fait aucune livraison de repli ; une exécution webhook principale réussie sans résumé non vide saute la publication et enregistre une raison de suppression vide, tandis que les erreurs d’exécution envoient toujours l’événement d’erreur.
• Avec une origine publique configurée et l’interface de contrôle activée, les notifications de chat portent un lien d’inspection : les achèvements de commandes et de scripts ouvrent l’exécution d’automatisation, les annonces d’agent isolé ouvrent la session de l’exécution.
• Pour une tâche de session courante, le résultat final de l’assistant est un achèvement de session de plein droit : OpenClaw attend les tours actifs de la conversation liée à la création, vérifie que la même génération de session possède encore la clé, et valide le résultat par l’écrivain de transcription canonique avec la provenance de tâche et d’exécution et une clé d’idempotence, si bien qu’une relance ne peut pas l’ajouter deux fois ; WebChat reçoit l’événement immédiatement et le même résultat vient de l’historique après une reconnexion.
• Si la conversation liée est un canal externe, l’envoi durable normal a aussi lieu, au plus une fois, et un envoi vérifié par l’outil de message supprime le renvoi automatique mais pas la validation de session ; une conversation sans route externe se termine sur la seule validation, et une route qui ne peut pas être résolue à l’exécution laisse le résultat dans la conversation et enregistre une erreur de livraison, pas un échec de tour.

Les tâches d’automatisation ne déduisent pas la langue de réponse du canal, de la locale ni des messages précédents.

Gardes, cibles, partage

Chaque webhook d’automatisation sortant utilise la garde SSRF stricte : les cibles en boucle locale, privées, de lien local et autres usages spéciaux sont refusées par défaut pour la livraison principale, les destinations d’achèvement et d’échec et les webhooks d’alerte d’échec, et la seule exception recommandée est une entrée exacte de nom d’hôte ou d’IP dans la politique de webhooks, l’option de réseau privé étant réservée aux hôtes où chaque webhook configuré peut atteindre des services internes de confiance. Les cibles suivent la syntaxe des canaux : un identifiant de conversation Telegram avec un suffixe de sujet, Slack, Discord et Mattermost avec des préfixes de canal ou d’utilisateur, des identifiants de salon Matrix sensibles à la casse. Sur les hôtes à plusieurs canaux configurés, les tâches d’annonce isolées doivent nommer un canal sauf si une cible préfixée par fournisseur ou une route de session préservée en choisit un, une option au mieux accepte une livraison de repli non résolue sans faire échouer la tâche, et un préfixe de fournisseur doit s’accorder avec un canal explicite pour qu’un identifiant Telegram ne soit jamais confié à WhatsApp comme numéro de téléphone. Les annonces ne relancent les échecs passagers que quand rien n’a pu atteindre le destinataire. Pour les tâches isolées, la livraison de chat est partagée : avec une route de chat disponible, l’agent peut utiliser l’outil de message même avec la livraison désactivée, et s’il envoie à la cible configurée ou courante, l’exécuteur saute son annonce de repli ; un rappel créé depuis un chat actif stocke cette cible vivante comme route de repli, la livraison par annonce implicite valide et reroute les cibles périmées par les listes d’autorisation des canaux, et les approbations d’appairage de messages privés ne sont jamais des destinataires de repli.

Alertes d’échec

• Les échecs d’exécution utilisent une politique unique possédée par le planificateur : une tâche dotée d’une route d’échec existante est couverte par défaut après deux échecs consécutifs avec un délai de grâce d’une heure, des échecs répétés de même cause forment un seul incident qui ne réalerte pas même après le délai ou un redémarrage, une cause ou une destination changée peut alerter de nouveau, et un succès ultérieur envoie un seul avis de rétablissement et clôt l’incident ; les exécutions sautées et les issues inconnues n’établissent pas de rétablissement. Les routes se résolvent depuis l’objet d’alerte propre à la tâche, puis la destination d’échec de la tâche superposée à la politique globale, puis la cible d’annonce principale, avec des surcharges par tâche pour le seuil, le délai, le canal, le destinataire, le mode, le compte et l’alerte sur les exécutions sautées.
• Un échec de livraison d’achèvement requise est distinct d’un échec d’exécution : une exécution peut enregistrer un état d’exécution ok avec un état d’achèvement échoué, cela n’incrémente ni la série d’échecs ni le recul, cela peut alerter par une destination de remplacement sans attendre le seuil, et des échecs de livraison répétés forment leur propre incident ; les notifications de chat montrent des causes normalisées avec l’heure de début de l’exécution dans le fuseau de l’utilisateur, tandis que les commandes brutes, les corps des fournisseurs et les traces restent dans l’historique. Un fournisseur qui rejette un modèle non pris en charge enregistre un état de modèle introuvable que la correction du doctor répare en basculant vers le successeur déclaré par le fournisseur quand la politique le permet ou en effaçant la surcharge.
• Le garde-fou inconditionnel : une tâche récurrente temporelle est désactivée automatiquement après dix échecs d’exécution consécutifs, les échecs répétés de calcul de planning après trois, la tâche enregistre la raison, l’agent propriétaire reçoit une notification sûre avec la commande de rétablissement, et la réactivation efface la raison et les séries ; les tâches désactivées sont cachées de la liste par défaut, donc utilisez l’option tout pour les trouver.

Les automatisations d’OpenClaw est le guide auquel cette couche de livraison appartient, et Hooks et webhooks dans OpenClaw le côté webhook de la même histoire sortante.

Langue et cibles

Mettez la règle de langue dans le message planifié ou le gabarit, par exemple répondre en chinois en gardant les URL, le code et les noms de produits inchangés, et vérifiez que les espaces réservés du gabarit sont remplis avant l’exécution ; une sortie mêlant les langues signifie que la règle n’était pas assez explicite. OpenClaw sur Telegram montre la syntaxe des cibles de sujets en contexte, et Streaming et découpage dans OpenClaw comment une cible Discord en texte seul reçoit le texte final une fois plutôt que chaque fragment diffusé.

Sur Diali

Sur Diali, la livraison par annonce vers le canal que vous avez connecté est le cas courant, les alertes d’échec arrivent par la même route après le deuxième échec consécutif, et la langue de réponse est celle que vous écrivez dans le message de la tâche. OpenClaw hébergé sur Diali est l’assistant et Les fuseaux horaires dans OpenClaw le fuseau dans lequel les avis d’échec sont horodatés.

• Annonce, webhook, aucun ; les résumés vides sautent la publication.
• Deux échecs, une heure, un incident, un avis de rétablissement.
• Dix échecs désactivent la tâche ; dites la langue dans le message.