Aller au contenu
Guides

La protection contre les boucles de bots d’OpenClaw

Comment deux bots sont empêchés de se répondre sans fin, le budget à fenêtre glissante, la priorité des surcharges, et quels canaux peuvent l’appliquer

4 min de lecture

Deux bots serviables dans un même salon, c’est un échec classique : chacun répond à l’autre, poliment, pour toujours. OpenClaw peut accepter les messages écrits par d’autres bots sur les canaux qui prennent en charge le réglage d’autorisation des bots, et quand ce chemin est activé, la protection des paires empêche deux identités de bots de se répondre indéfiniment. Voici comment fonctionne la garde, ses valeurs par défaut, comment fixer une base partagée et des surcharges plus étroites, quels canaux peuvent l’appliquer, et le budget séparé qui gouverne les tours internes des groupes d’agents.

Comment fonctionne la garde

  • La garde est appliquée par l’exécuteur de réponses entrantes central : chaque canal qui la prend en charge convertit son événement entrant en faits génériques, le compte ou la portée, l’identifiant de conversation, l’identifiant du bot expéditeur et celui du bot destinataire.
  • Le cœur suit la paire de participants dans les deux sens, si bien que A vers B et B vers A comptent comme la même paire, applique un budget à fenêtre glissante, et supprime la paire pendant un délai de grâce une fois le budget dépassé.
  • Valeurs par défaut : activée, vingt événements par paire dans une fenêtre glissante de soixante secondes, et une suppression de soixante secondes après dépassement du budget ; la garde est active dès qu’un canal laisse des messages écrits par des bots atteindre la distribution.
  • Elle n’affecte ni les messages écrits par des humains, ni les déploiements à un seul bot, ni le filtrage des messages propres, ni les réponses de bots qui restent sous le budget.
Ne mettez enabled à false que quand votre politique de canal autorise volontairement les conversations entre bots sans suppression automatique.

Base et surcharges

Une base partagée sous les valeurs par défaut des canaux donne à chaque canal qui la prend en charge la même fenêtre, le même budget et le même délai, et les canaux peuvent exposer des surcharges plus étroites qui se superposent clé par clé. Priorité, du plus étroit au plus large : un réglage par salon ou par espace quand le canal prend en charge les surcharges par conversation, un réglage par compte quand le canal prend en charge les comptes, le réglage de premier niveau du canal, les valeurs par défaut partagées, puis les valeurs intégrées. L’exemple de la documentation garde le budget partagé à vingt, abaisse Discord à huit avec un compte secondaire autorisant les bots à cinq événements et un délai de quatre-vingt-dix secondes, fixe un espace Google Chat et un salon Matrix à cinq, et donne huit à Slack avec les bots autorisés sur mention ; Feishu utilise volontairement la seule base partagée.

Prise en charge par canal

  • Discord utilise le fait natif d’auteur bot indexé par compte, canal et paire de bots ; Feishu le type natif d’expéditeur bot pour les messages de groupe écrits par des bots admis, indexé par compte, conversation et paire ; Google Chat le type natif d’expéditeur bot indexé par compte, espace et paire ; Matrix les comptes de bots configurés indexés par compte, salon et paire configurée ; et Slack l’identifiant de bot natif indexé par compte, canal et paire.
  • Les canaux qui n’exposent pas d’identité de bot entrante fiable gardent leurs filtres normaux de messages propres et de politique d’accès, et la documentation dit qu’ils ne devraient pas adhérer à cette garde tant qu’ils ne peuvent pas identifier les deux participants de la paire.
  • Les fils de groupes d’agents utilisent un budget de coordination séparé pour les participants qui partagent un même message entrant : les entrées de diffusion qualifiées autorisent au plus quatre tours et trente-deux tours de participants, les tours incluent le premier, les tours de participants comptent les exécutions d’agents démarrées avec des créneaux réservés avant le lancement en parallèle, et le passage de tous, l’une des limites ou une annulation arrête les tours suivants. Ce budget en mémoire est limité au canal, au compte, à la conversation, au fil et au message racine et ne peut pas reprendre après un redémarrage de la passerelle ; les continuations internes portent des identités distinctes pour que la déduplication ordinaire ne les supprime pas, et elles ne changent ni les seuils de la garde des paires de transport ni ne remplacent les politiques d’admission des bots et de messages propres.

Les groupes de diffusion d’OpenClaw est la fonction dont les tours reçoivent le budget de coordination séparé, et OpenClaw sur Slack l’un des canaux qui applique la garde des paires sur mention.

Quand l’assouplir

La seule raison de désactiver la garde est une politique de canal qui veut volontairement une conversation entre bots sans suppression ; sinon, réglez le budget par salon ou par compte et laissez la base activée. OpenClaw sur Discord est le canal à la surface de surcharges la plus riche, et La messagerie d’agent à agent d’OpenClaw le chemin délibéré d’agent à agent qui ne passe pas du tout par un salon de discussion.

Sur Diali

Sur Diali, la garde est activée avec les valeurs amont par défaut pour Discord et Slack, les deux canaux connectés qui exposent des identités de bots ; WhatsApp, Telegram, le SMS et la voix gardent leurs filtres ordinaires de messages propres et de politique d’accès. OpenClaw hébergé sur Diali est l’assistant.

  • Vingt événements, soixante secondes, soixante secondes de silence.
  • A vers B et B vers A ne font qu’une paire.
  • Le salon bat le compte, qui bat le canal, qui bat les défauts.
Commencer

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.