Le comportement des messages Telegram dans OpenClaw

L’essentiel de ce qu’un utilisateur de Telegram remarque d’un bot OpenClaw, l’aperçu modifié qui grandit pendant qu’il réfléchit, le menu de commandes, la petite réaction qui dit qu’il travaille, se décide dans une poignée de clés du bloc du canal. Voici le modèle d’exécution derrière elles, le changement d’aperçu qui a surpris en 2026.8.1, et les limites et cibles qui façonnent la livraison. Les changements de mode de réponse, de réglages de diffusion et de limite de découpage s’appliquent au tour assemblé suivant sans reconnecter Telegram, surcharges de compte comprises, tandis que les tours actifs gardent ce qu’ils ont capturé.

Modèle d’exécution

• Le traitement Telegram tourne dans le processus de la passerelle, les messages entrants se normalisent dans l’enveloppe de canal partagée avec les métadonnées de réponse, les marqueurs de médias et le contexte persistant de chaîne de réponses pour les réponses que la passerelle a observées, les sessions de groupe sont isolées par identifiant de groupe, et les sujets de forum ajoutent un suffixe de sujet portant l’identifiant du fil.
• Quand le bot rejoint un groupe ou supergroupe autorisé, il publie une introduction ancrée dans les métadonnées de salle qu’il peut voir, le titre, la description et le message épinglé ; l’API Bot ne peut pas lire les messages antérieurs à son arrivée, donc les introductions ne prétendent jamais utiliser l’historique, elles ne s’exécutent jamais en discussion privée, et une clé d’introduction à l’arrivée les désactive au niveau du canal ou par compte.
• Les messages privés peuvent porter un identifiant de fil conservé pour les réponses, mais les sessions de sujet privées ne se séparent que lorsque le getMe du bot rapporte les sujets activés, ce que contrôle le mode fils de BotFather ; sinon les messages privés restent sur la session plate, et les anciennes clés de réponses en fil pour les messages privés ont été retirées, la correction du doctor les nettoyant d’une configuration mise à niveau.
• Le sondage long tourne dans un travailleur isolé, les mises à jour sont enregistrées dans une file durable et traitées dans l’ordre par discussion et par sujet, le démarrage multi-comptes borne les sondes getMe simultanées pour qu’une grande flotte de bots ne lance pas toutes ses sondes d’un coup, chaque processus de passerelle garde le sondage pour qu’un seul sondeur actif utilise un jeton à la fois, des conflits 409 persistants sur getUpdates désignent une autre passerelle, un script ou un sondeur externe sur le même jeton, le chien de garde redémarre après 120 secondes sans vivacité de sondage aboutie, et l’API Bot n’a pas d’accusés de lecture.

Le routage est déterministe : ce qui entre par Telegram répond sur Telegram (le modèle ne choisit pas les canaux).

Les aperçus et le changement de 2026.8.1

Avec la clé de diffusion non définie, Telegram garde désormais un seul brouillon d’état modifiable pendant le tour, l’état courant de l’agent plus ses lignes d’outils, et envoie la réponse finale comme un message normal ; avant 2026.8.1 il diffusait le texte de la réponse lui-même dans l’aperçu. Aucune configuration ne devient invalide et aucune correction du doctor n’est nécessaire, et régler le mode de diffusion sur partial rétablit l’ancien comportement. Les quatre modes sont off, partial, block et progress, progress étant la valeur par défaut : les premiers aperçus courts de réponse sont temporisés puis matérialisés après un délai borné si l’exécution est encore active, et progress garde un brouillon d’état qui montre l’étiquette d’état stable quand l’activité de réponse arrive avant la progression des outils, l’efface à la fin et livre la réponse normalement. Par défaut ce brouillon est discret, le titre d’état, les commentaires, les jalons du plan et les demandes d’approbation, les échecs d’outils intermédiaires et les sorties de commande non nulles étant cachés tandis que les erreurs de tâche terminales passent toujours par la livraison d’erreur normale ; un indicateur de progression des outils sous progress ajoute le journal d’outils défilant, échecs compris, un indicateur de progression d’aperçu décide si les mises à jour d’outils réutilisent l’aperçu modifié dans les modes partial et block, un réglage de texte de commande montre seulement l’étiquette de l’outil ou le texte explicite de la commande, et un indicateur de commentaires fait entrer le préambule de l’assistant dans le brouillon temporaire. Les anciennes clés de mode de flux, les valeurs booléennes de diffusion et les clés retirées de brouillon natif sont détectées et migrées par la correction du doctor, et l’état de compaction suit les mêmes réglages et apparaît dès que la compaction commence. Les réponses à citation sélectionnée sont l’exception : quand le mode de réponse est first, all ou batched et que le message entrant porte un texte de citation sélectionné, la réponse finale passe par le chemin natif de réponse citée de Telegram et les aperçus sont sautés pour ce tour. Pour les réponses textuelles, un aperçu court reçoit la modification finale sur place, une réponse finale longue qui se découpe réutilise l’aperçu comme premier morceau et n’envoie que le reste, les réponses finales du mode progress effacent le brouillon, et si la modification finale échoue avant confirmation, le bot retombe sur la livraison normale et nettoie l’aperçu périmé ; les réponses avec médias prennent toujours le chemin normal. La diffusion par aperçu et la diffusion par blocs s’excluent : un mode d’aperçu explicite autre que off l’emporte sur une valeur par défaut héritée de diffusion par blocs, et un indicateur de blocs explicite l’emporte sur l’aperçu. La commande de flux de raisonnement diffuse le raisonnement dans l’aperçu en direct et supprime cet aperçu après la livraison finale sauf si le raisonnement est gardé visible, et la réponse finale est envoyée sans texte de raisonnement.

Commandes, réponses, accusés, limites

• Le menu de commandes est enregistré au démarrage avec setMyCommands quand les commandes natives sont en auto ; les entrées personnalisées ne sont que des éléments de menu, normalisées en minuscules avec un motif valide de lettres, de chiffres et de tirets bas jusqu’à 32 caractères, incapables de remplacer les commandes natives, les conflits étant sautés et journalisés, et quand le menu déborde encore après une tentative de réduction, vous réduisez les commandes d’extensions, de compétences et personnalisées ou désactivez les commandes natives ; un 404 sur les appels de commandes ou de webhook alors qu’un curl direct fonctionne signifie généralement que la racine d’API a été réglée sur le point de terminaison complet avec le jeton, un 401 sur getMe signifie que le jeton a été rejeté et le bot s’arrête avant le sondage, et des erreurs réseau sur setMyCommands signifient généralement que le DNS ou le HTTPS sortant vers l’hôte de l’API Bot est bloqué.
• Les réponses en fil ont des balises explicites pour le message courant et pour un identifiant de message précis, le mode de réponse est off par défaut avec first et all comme alternatives, un extrait de citation native est ajouté automatiquement quand le texte d’origine est disponible, plafonné à 1024 unités UTF-16 avec une réponse simple en repli, et off ne désactive que le fil implicite tandis que les balises explicites restent honorées ; l’emoji de réaction d’accusé se résout depuis le compte, le canal, le réglage global puis l’emoji d’identité de l’agent avec les yeux en dernier repli, une chaîne vide le désactive, et la portée est par défaut celle des mentions de groupe, donc les messages privés ne reçoivent aucun accusé sauf si la portée est direct ou all, et seule all couvre les événements ambiants de salle.
• La limite de découpage du texte est de 4000 par défaut avec un mode de découpage par saut de ligne qui préfère les frontières de paragraphes, les médias sont plafonnés à 100 Mo en entrée comme en sortie avec une mention de média indisponible dans le corps quand une pièce jointe ne peut pas être téléchargée, l’historique de contexte de groupe est de 50 par défaut et zéro le désactive, le contexte de réponse, de citation et de transfert se normalise en une seule fenêtre sélectionnée quand la passerelle a observé les parents, le cache vivant dans l’état SQLite de l’extension avec une seule charge de réponse peu profonde par mise à jour au-delà, les listes d’autorisation filtrent qui peut déclencher l’agent plutôt que de caviarder le contexte supplémentaire, et les envois en ligne de commande acceptent un identifiant numérique de discussion, un nom d’utilisateur ou une cible de sujet, les sondages acceptant une durée de cinq secondes à sept jours, un vote anonyme ou public et de deux à douze options, des claviers intégrés par blocs de présentation, une livraison épinglée et un indicateur de document forcé, le tout sous le contrôle des interrupteurs d’action d’envoi et de sondage.

OpenClaw sur Telegram est le billet du canal auquel ce comportement appartient, et Le contrôle d’accès Telegram d’OpenClaw décide d’abord qui l’atteint.

Pourquoi le brouillon a changé

Diffuser le texte de la réponse dans un message modifié semblait vivant mais réécrivait sans cesse le message que les gens lisaient, et sur un canal où chaque modification est un appel réseau, le brouillon d’état discret est la meilleure valeur par défaut. Les réactions dans OpenClaw couvre l’emoji d’accusé entre canaux, et Connecter votre premier canal en cinq minutes le parcours du premier canal où vous décidez du comportement voulu avant que quiconque écrive au bot.

Sur Diali

Telegram fait partie des canaux que Diali connecte depuis le tableau de bord, la configuration d’exécution étant générée et remplacée à chaque version, donc les clés de diffusion, de commandes et de limites décrites ici disent ce que fait un bot hébergé plutôt qu’un fichier que vous entretenez. Telegram sur Diali est le canal sur Diali et OpenClaw hébergé sur Diali l’assistant derrière lui.

• Les réponses repartent sur Telegram ; le modèle ne choisit jamais de canal.
• Depuis 2026.8.1 l’aperçu est un brouillon d’état ; partial diffuse la réponse.
• 4000 caractères par morceau, 100 Mo par fichier, un sondeur par jeton.