Les événements de salon ambiants d’OpenClaw
Des salons permanents que l’agent écoute en silence, les deux réglages qui les font fonctionner, les deux prérequis qui les cassent en silence, et les exemples par canal
Certains salons doivent être surveillés, pas répondus. Les événements de salon ambiants d’OpenClaw laissent le bavardage de groupe ou de canal sans mention être traité comme contexte silencieux : l’agent peut mettre à jour la mémoire et l’état de session, mais le salon reste silencieux sauf si l’agent appelle explicitement l’outil de message. Pour les salons permanents, la documentation combine deux réglages, l’entrée sans mention en événements de salon et les réponses visibles par l’outil de message, si bien que l’agent écoute, décide quand une réponse est utile, et n’a jamais besoin de l’ancien schéma du jeton silencieux. Voici la configuration, les deux prérequis, ce qui change, les exemples par canal, les modes de réponse, l’historique, et le dépannage.
Configuration et prérequis
- Pris en charge aujourd’hui : les canaux de guilde Discord, les canaux, canaux privés et messages privés à plusieurs de Slack, et les groupes ou supergroupes Telegram ; les autres canaux de groupe gardent leur comportement existant sauf indication contraire sur leur page. Le réglage global recommandé est l’entrée en événements de salon, les réponses visibles par l’outil de message et une limite d’historique de cinquante, puis le salon devient permanent en désactivant le filtrage par mention, tout en devant encore passer sa politique de groupe, sa liste de salons et sa liste d’expéditeurs.
- Deux réglages désactivent en silence les événements ambiants même quand le mode d’entrée est fixé : le filtrage par mention doit être désactivé pour le salon, parce qu’une exigence de mention abandonne les messages sans mention avant le routage, si bien qu’ils ne deviennent jamais des événements et que l’agent n’a alors aucun historique du salon, ce qui est la première chose à vérifier quand il dit ne pas voir les messages récents.
- L’agent a besoin de l’outil de message, puisque les événements de salon utilisent une livraison visible stricte et que publier exige l’action d’envoi du message ; l’outil est livré dans le profil de messagerie mais pas dans les profils minimal ni de code, donc un agent sur le profil de code écoute et ne peut jamais parler tant que l’outil n’est pas accordé explicitement par une entrée d’autorisation supplémentaire, vérifiée par la liste des agents et un tour de sonde plutôt que supposée.
- Après l’enregistrement, la passerelle applique à chaud les réglages de messages, et seul un mode de rechargement désactivé exige un redémarrage manuel.
L’agent écoute, décide quand une réponse est utile, et n’a jamais besoin de l’ancien schéma de prompt consistant à répondre NO_REPLY.
Ce qui change
Avec l’entrée en événements de salon, les messages de groupe ou de canal autorisés sans mention deviennent des événements silencieux tandis que les messages avec mention, les commandes texte et natives, les demandes d’interruption ou d’arrêt et les messages privés restent tous des requêtes d’utilisateur. Les événements de salon utilisent une livraison visible stricte, donc le texte final de l’assistant est privé et l’agent doit appeler l’action d’envoi du message pour publier ; les indicateurs de frappe et les réactions de statut de cycle de vie restent supprimés pour les événements de salon, avec une seule exception explicite, une portée de réaction d’accusé valant tout, qui envoie la réaction configurée, si bien que toute portée plus étroite ou désactivée garde le salon complètement silencieux. Les réponses visibles valent automatique par défaut pour les requêtes de groupe normales, et le mode par outil de message reste recommandé pour les salons ambiants, surtout avec les modèles récents fiables sur les outils : l’agent décide quand parler, et si le modèle renvoie un texte final sans appeler l’outil, OpenClaw le garde privé et journalise des métadonnées de livraison supprimée. Les événements de salon restent stricts même quand les autres requêtes de groupe utilisent des réponses automatiques.
Exemples et historique
- Discord : la politique de liste avec une entrée de guilde qui désactive l’exigence de mention et liste votre identifiant d’utilisateur, ou une entrée par canal sous la guilde quand un seul canal doit être ambiant, lister le canal étant ce qui l’autorise. Slack : les listes de canaux sont d’abord par identifiant, donc la clé est un identifiant de canal plutôt qu’un nom avec dièse, listé sous la carte des canaux avec l’exigence de mention désactivée ; l’application a aussi besoin de la portée d’historique pour ce type de salon, public, privé ou message privé à plusieurs.
- Telegram : le bot doit pouvoir voir les messages de groupe normaux, donc avec l’exigence de mention désactivée, désactivez le mode de confidentialité de BotFather ou utilisez une configuration qui livre tout le trafic du groupe ; les identifiants de groupes sont généralement des nombres négatifs trouvés dans le flux des journaux, par un bot d’aide aux identifiants ou par les mises à jour de l’API des bots. Quand plusieurs agents partagent un salon mais qu’un seul doit traiter le bavardage sans mention comme contexte ambiant, un réglage d’entrée au niveau de l’agent surcharge le réglage global pour cet agent.
- La limite d’historique fixe la valeur globale par défaut de l’historique de groupe, cinquante quand elle n’est pas définie, surchargeable par canal et parfois par compte, zéro désactivant l’historique de groupe pour un canal ; les canaux pris en charge gardent les messages ambiants récents comme contexte, et Telegram garde une fenêtre glissante permanente par groupe où les tours de requête d’utilisateur reçoivent les entrées postérieures à la dernière réponse du bot tandis que les tours d’événements de salon reçoivent toute la fenêtre pour que le modèle voie ses propres publications récentes.
Les conversations de groupe dans OpenClaw est le modèle que les salons ambiants prolongent, et OpenClaw sur Discord le canal dont les canaux de guilde les prennent en charge.
Dépannage
Un salon qui montre une frappe ou une consommation de jetons mais aucun message visible : confirmez que le salon passe les listes de canaux et d’expéditeurs, confirmez que l’exigence de mention est désactivée au niveau attendu, vérifiez si le réglage d’entrée global ou celui de l’agent vaut événements de salon, inspectez les journaux pour des charges finales supprimées ou un indicateur d’envoi par outil de message à faux, et pour les requêtes de groupe normales rétablissez les réponses automatiques si vous voulez que les réponses finales soient publiées, tandis que les salons ambiants ont besoin d’un modèle qui appelle les outils de façon fiable. Des salons Telegram qui ne déclenchent jamais pointent vers le mode de confidentialité ; des salons Slack vers un nom utilisé à la place d’un identifiant ou une portée d’historique manquante. OpenClaw sur Slack et OpenClaw sur Telegram sont les deux autres canaux avec la même prise en charge.
Sur Diali
Sur Diali, les salons ambiants sont disponibles sur Discord, Slack et Telegram, les trois canaux connectés qui les prennent en charge ; passer un salon en ambiant signifie que l’assistant lit tout ce que le salon dit, donc choisissez les salons délibérément. OpenClaw hébergé sur Diali est l’assistant et La sécurité chez Diali décrit ce qui reste à l’intérieur de sa frontière.
- Des événements de salon en entrée, l’outil de message en sortie, le silence sinon.
- Filtrage par mention désactivé, outil de message accordé, sinon rien ne se passe.
- Des identifiants pour Slack, le mode de confidentialité désactivé pour Telegram.
Arrêtez de lire, construisez le vôtre
Configurez un agent, choisissez un canal, et faites-le travailler dans l’application que vous gardez déjà ouverte.
