Hooks et webhooks dans OpenClaw

Le mot hook recouvre trois choses différentes dans OpenClaw, et la documentation ouvre la page des hooks par un tableau pour les tenir séparées. Les hooks internes sont de petits gestionnaires qui tournent dans le processus de la passerelle quand un événement se produit ; les hooks d’extension sont des gestionnaires typés qui modifient les invites, interceptent les outils ou contrôlent les réponses depuis la boucle d’agent ; les webhooks sont une entrée HTTP, une façon pour un autre service de lancer du travail par une requête. Voici lequel sert à quoi, le hook embarqué que la documentation suggère d’essayer en premier, ce que prouvent réellement les trois mots d’état, et les règles sur l’endroit où un hook est activé et chargé.

Trois surfaces

• Les hooks internes, un fichier de hook plus un gestionnaire : sauvegarder le contexte sur une commande de nouvelle session, journaliser les commandes, réagir aux événements de session et de message. Ils tournent avec l’accès de la passerelle au système de fichiers, au réseau et à l’environnement, la documentation dit donc de relire le code avant d’en activer un.
• Les hooks d’extension, enregistrés par l’API des extensions : modifier les invites, intercepter les outils, réclamer ou faire taire des réponses, avec des priorités et des valeurs de retour ; ils apparaissent dans la liste des hooks avec un préfixe d’extension et se commandent en activant l’extension propriétaire.
• Les webhooks, configurés séparément des hooks internes : ils acceptent des requêtes externes qui déclenchent du travail au lieu de s’abonner aux événements de la boucle, et ils vivent sur la page des tâches cron.
• Les événements de diagnostic sont une quatrième surface pour la télémétrie qui ne change rien.

Les hooks internes sont du code de confiance, pas des scripts en bac à sable.

Le démarrage rapide

La documentation commence par le journal de commandes embarqué parce qu’il n’exige ni binaire ni appel de modèle et laisse un fichier que vous pouvez inspecter : listez les hooks, lisez ses informations, activez-le, sur l’hôte de la passerelle avec le profil de la passerelle. Le rechargement hybride par défaut applique le changement sans redémarrage. Envoyez une commande de nouvelle session ou de réinitialisation dans une conversation que vous pouvez réinitialiser sans risque, puis lisez les dernières lignes du journal des commandes sous le répertoire OpenClaw et cherchez une ligne JSON avec l’action, un horodatage récent et la clé de session de cette conversation. Cela prouve qu’un gestionnaire a tourné ; la commande de vérification seule ne le prouve pas. Le journal contient des identifiants de session et d’expéditeur, désactivez donc le hook ensuite si vous ne voulez pas conserver ces enregistrements.

Éligible, activé, chargé

• Prérequis satisfaits : les exigences du hook en système, binaires, environnement et configuration passent sur l’hôte qui vérifie.
• Activé par la configuration : la politique par hook l’autorise ; les hooks d’espace de travail exigent un consentement explicite, les embarqués et gérés non une fois la découverte large activée.
• Chargé : la passerelle en marche l’a sélectionné, a importé le gestionnaire et enregistré ses événements. Les champs prêt, éligible et chargeable de la CLI couvrent les deux premières vérifications et une liste d’événements non vide ; ils ne prouvent jamais que la passerelle a importé le gestionnaire ni qu’un événement s’est produit, vérifiez donc l’effet de bord.

Les automatisations OpenClaw couvre cron, l’autre moitié du travail piloté par événements, et Les extensions OpenClaw le mécanisme sur lequel reposent les hooks d’extension.

Portée

Les commandes de liste, d’information et de vérification demandent son inventaire à la passerelle sélectionnée, et une passerelle distante configurée ne se rabat pas sur les hooks de votre portable ; activer et désactiver changent toujours la configuration locale, lancez-les donc sur l’hôte de la passerelle. L’option d’agent sélectionne un espace de travail à inspecter, pas un registre séparé : l’entrée enregistrée est globale, la passerelle charge les hooks de répertoire depuis son espace de travail sélectionné dans un registre unique pour le processus, et un gestionnaire qui ne doit agir que pour un agent doit filtrer l’événement lui-même. Le rechargement de configuration prépare les nouveaux gestionnaires avant de les échanger, garde les anciens si l’un échoue à se charger, et ne rejoue jamais l’événement de démarrage. OpenClaw comme agent IA montre où dans la boucle la variété d’extension se déclenche.

Sur Diali

Sur Diali, le processus de la passerelle est à nous, ce qui explique que les hooks qui tournent comme code de confiance en son sein ne soient pas quelque chose que vous téléversez : le travail piloté par événements que vous pouvez configurer, ce sont les automatisations et les compétences, et la frontière est le but. OpenClaw hébergé sur Diali est l’assistant.

• Les hooks internes tournent dans la passerelle ; les hooks d’extension dans la boucle ; les webhooks viennent de l’extérieur.
• Le journal de commandes d’abord : il laisse un fichier qui prouve que le gestionnaire a tourné.
• Prêt et éligible ne veulent pas dire chargé ; l’effet de bord est la preuve.