Fils et sessions Slack dans OpenClaw

Les fils Slack cachent leurs messages au canal, et c’est exactement pourquoi le modèle de sessions doit être précis sur la session OpenClaw à laquelle un message appartient et sur l’endroit où atterrit la réponse. Voici la correspondance des surfaces Slack aux sessions, les règles des fils, les contrôles de réponse avec la différence avec Telegram qui mérite d’être retenue, et l’expérience Agent View où Slack lui-même gère les fils.

Sessions

• Les messages privés se routent en direct, les canaux en channel et les messages de groupe en group ; les liaisons de route acceptent des identifiants bruts plus les formes de cible Slack pour un canal, un utilisateur ou une mention d’utilisateur ; avec la portée principale par défaut des messages privés, les messages privés ordinaires se fondent dans la session principale de l’agent tandis que les racines Agent View et les fils Assistant View existants restent isolés en sessions de fil ; et les sessions de canal sont indexées par agent, canal et identifiant de canal.
• Les messages de canal ordinaires de premier niveau restent sur la session du canal même quand le mode de réponse n’est pas off, tandis que les réponses en fil de canal, de message de groupe, d’Agent View et d’Assistant View utilisent l’horodatage du fil parent comme suffixe de fil ; un fil de réponse ordinaire en message privé reste une commodité d’interface sur la session de base.
• OpenClaw amorce une racine de canal de premier niveau éligible dans une session de fil indexée par l’horodatage de cette racine quand la racine est censée ouvrir un fil visible, pour que la racine et ses réponses ultérieures partagent une seule session ; cela s’applique aux événements de mention de l’application, aux correspondances explicites du bot ou des motifs de mention configurés, et aux canaux sans mention obligatoire dont le mode de réponse n’est pas off.
• La portée d’historique des fils vaut thread par défaut, l’héritage du parent vaut faux par défaut, et la limite d’historique initiale décide du nombre de messages existants du fil récupérés quand une nouvelle session de fil démarre, 20 par défaut et zéro pour désactiver.

Les fils Slack cachent les messages du canal tandis que les réponses Telegram restent visibles en ligne.

Réponses, balises et diffusion

Deux indicateurs de mention implicite décident de ce qui contourne la mention obligatoire : une réponse au propre message du bot, et une suite dans un fil où le bot a répondu, tous deux vrais par défaut, le second passant à faux quand vous voulez une nouvelle mention explicite dans les suites ; la correction du doctor migre l’ancienne clé de fil exigeant une mention explicite vers cet indicateur positif, les surcharges de compte vivent sous le bloc de mentions implicites du compte et les valeurs partagées sous les valeurs par défaut des canaux. Le mode de réponse est off par défaut avec first, all et batched comme alternatives, réglable par canal, par type de discussion pour direct, group et channel, et par l’ancien mode de réponse des messages privés pour les discussions directes. Les balises de réponse manuelles visent le message courant ou un identifiant de message précis. Une réponse en fil explicite depuis l’outil de message peut demander la diffusion pour que Slack publie aussi la réponse dans le canal parent, ce qui correspond à l’indicateur de diffusion de la publication de message et ne fonctionne que pour les envois de texte ou de Block Kit, pas pour les envois de médias. Un appel de l’outil de message exécuté dans un fil et visant le même canal hérite normalement du fil courant selon le mode de réponse effectif du compte, du type de discussion ou du canal, les réponses automatiques et les envois ou téléversements dans le même canal utilisent la même surcharge, et un indicateur de premier niveau ou un identifiant de fil nul force à la place un nouveau message dans le canal parent. Le mode de réponse off désactive le fil sortant facultatif y compris les balises explicites, ce qui diffère de Telegram, où les balises explicites restent honorées en off ; Agent View et Assistant View sont des expériences en fil gérées par Slack dont les réponses et l’état restent sur la racine visible quoi qu’il arrive, et off n’aplatit pas les autres sessions de fil entrantes.

Les messages privés Agent View

• Agent View est l’expérience de messagerie de Slack pour les applications d’IA : Slack marque l’application comme un agent, chaque message tapé dans le compositeur de premier niveau de l’onglet Messages ouvre une nouvelle racine que Slack met en fil lui-même, les suites appartiennent au fil de cette racine, et OpenClaw traite chaque racine comme une conversation distincte avec un suffixe de fil ajouté à la session de base que choisit la portée des messages privés, si bien que les racines restent isolées même sous la portée principale.
• Les suites dans le fil d’une racine restent sur la session de cette racine, un nouveau message du compositeur ouvre une nouvelle session, les réponses et l’état du fil restent sur la racine visible quel que soit le mode de réponse parce que Slack possède le fil, et les entités de la vue active n’atteignent l’agent que comme contexte structuré non fiable dans l’ordre de pertinence de Slack, un message privé qui n’en porte aucune les effaçant pour ce tour plutôt que de réutiliser d’anciennes valeurs.
• Slack ne dit jamais quelle expérience une application utilise, donc OpenClaw enregistre Agent View au premier signal qu’il voit, un événement de changement de contexte d’application, un message privé porteur d’un contexte d’application, ou l’appel sans fil d’invites suggérées qu’il fait quand un membre ouvre l’onglet Messages, où ok comme erreur interne comptent comme preuve et où une réponse d’application non agent signifie Assistant View ; un message privé dont l’horodatage de fil égale son propre horodatage est reconnu à lui seul comme une racine gérée par Slack, le marqueur est durable et indexé par compte, espace de travail et identifiant d’application, le mode Socket lit l’identifiant d’application dans le jeton d’application au démarrage, le mode HTTP l’apprend au premier événement signé et le journalise une fois, et le mode relais ne garde le marqueur que dans le processus en cours.

OpenClaw sur Slack est le billet du canal auquel ces sessions appartiennent, et Le comportement des messages Slack dans OpenClaw ce à quoi ressemble la conversation pendant qu’une réponse se produit.

Une session par fil, à dessein

Amorcer la racine dans la session de fil est ce qui permet à une mention dans un canal animé de devenir un fil de travail privé avec sa propre mémoire, au lieu que chaque réponse retombe dans la session partagée du canal. Le routage des canaux dans OpenClaw explique comment la session de canal choisit son agent, et La recherche de sessions dans OpenClaw comment retrouver plus tard l’une de ces sessions de fil.

Sur Diali

Slack 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 fils et de réponses décrites ici disent comment un agent hébergé se comporte dans votre espace de travail plutôt qu’un fichier que vous entretenez. Slack sur Diali est le canal sur Diali et OpenClaw hébergé sur Diali l’assistant derrière lui.

• Une racine mentionnée et son fil partagent une seule session.
• Off sur Slack fait taire aussi les balises explicites ; Telegram les garde.
• Chaque racine Agent View est sa propre conversation.