Canaux et routage

OpenClaw route les reponses vers le canal d’ou provient le message. Le modele ne choisit pas un canal ; le routage est deterministe et controle par la configuration de l’hote.

Termes cles

  • Canal : whatsapp, telegram, discord, slack, signal, imessage, webchat.
  • AccountId : instance de compte par canal (quand pris en charge).
  • Compte par defaut du canal optionnel : channels.<channel>.defaultAccount choisit quel compte est utilise quand un chemin sortant ne specifie pas accountId.
    • Dans les configurations multi-comptes, definissez un compte par defaut explicite (defaultAccount ou accounts.default) quand deux comptes ou plus sont configures. Sans cela, le routage de secours peut choisir le premier ID de compte normalise.
  • AgentId : un espace de travail isole + magasin de sessions (« cerveau »).
  • SessionKey : la cle de compartiment utilisee pour stocker le contexte et controler la concurrence.

Formes de cles de session (exemples)

Les messages prives se replient dans la session principale de l’agent :

  • agent:<agentId>:<mainKey> (par defaut : agent:main:main)

Les groupes et canaux restent isoles par canal :

  • Groupes : agent:<agentId>:<channel>:group:<id>
  • Canaux/salons : agent:<agentId>:<channel>:channel:<id>

Fils de discussion :

  • Les fils Slack/Discord ajoutent :thread:<threadId> a la cle de base.
  • Les sujets de forum Telegram integrent :topic:<topicId> dans la cle de groupe.

Exemples :

  • agent:main:telegram:group:-1001234567890:topic:42
  • agent:main:discord:channel:123456:thread:987654

Epinglage de route DM principale

Quand session.dmScope est main, les messages prives peuvent partager une seule session principale. Pour empecher que le lastRoute de la session soit ecrase par des DMs de non-proprietaires, OpenClaw deduit un proprietaire epingle depuis allowFrom quand toutes ces conditions sont vraies :

  • allowFrom a exactement une entree non-joker.
  • L’entree peut etre normalisee en un ID d’expediteur concret pour ce canal.
  • L’expediteur DM entrant ne correspond pas a ce proprietaire epingle.

Dans ce cas de non-correspondance, OpenClaw enregistre quand meme les metadonnees de session entrantes, mais il n’ecrase pas le lastRoute de la session principale.

Regles de routage (comment un agent est choisi)

Le routage choisit un agent pour chaque message entrant :

  1. Correspondance de pair exacte (bindings avec peer.kind + peer.id).
  2. Correspondance de pair parent (heritage de fil).
  3. Correspondance guilde + roles (Discord) via guildId + roles.
  4. Correspondance de guilde (Discord) via guildId.
  5. Correspondance d’equipe (Slack) via teamId.
  6. Correspondance de compte (accountId sur le canal).
  7. Correspondance de canal (tout compte sur ce canal, accountId: "*").
  8. Agent par defaut (agents.list[].default, sinon premiere entree de la liste, repli sur main).

Quand un binding inclut plusieurs champs de correspondance (peer, guildId, teamId, roles), tous les champs fournis doivent correspondre pour que ce binding s’applique.

L’agent selectionne determine quel espace de travail et quel magasin de sessions sont utilises.

Groupes de diffusion (executer plusieurs agents)

Les groupes de diffusion vous permettent d’executer plusieurs agents pour le meme pair quand OpenClaw repondrait normalement (par exemple : dans les groupes WhatsApp, apres le filtrage par mention/activation).

Config :

{
  broadcast: {
    strategy: "parallel",
    "[email protected]": ["alfred", "baerbel"],
    "+15555550123": ["support", "logger"],
  },
}

Voir : Groupes de diffusion.

Apercu de la configuration

  • agents.list : definitions d’agents nommees (espace de travail, modele, etc.).
  • bindings : associe les canaux/comptes/pairs entrants aux agents.

Exemple :

{
  agents: {
    list: [{ id: "support", name: "Support", workspace: "~/.openclaw/workspace-support" }],
  },
  bindings: [
    { match: { channel: "slack", teamId: "T123" }, agentId: "support" },
    { match: { channel: "telegram", peer: { kind: "group", id: "-100123" } }, agentId: "support" },
  ],
}

Stockage des sessions

Les magasins de sessions se trouvent dans le repertoire d’etat (par defaut ~/.openclaw) :

  • ~/.openclaw/agents/<agentId>/sessions/sessions.json
  • Les transcriptions JSONL se trouvent a cote du magasin

Vous pouvez surcharger le chemin du magasin via session.store et le template {agentId}.

La decouverte de sessions de la Gateway et de l’ACP scanne egalement les magasins d’agents sur disque sous la racine par defaut agents/ et sous les racines de session.store templatisees. Les magasins decouverts doivent rester a l’interieur de cette racine d’agent resolue et utiliser un fichier sessions.json standard. Les liens symboliques et les chemins hors racine sont ignores.

Comportement WebChat

WebChat se rattache a l’agent selectionne et utilise par defaut la session principale de l’agent. Grace a cela, WebChat vous permet de voir le contexte inter-canaux pour cet agent en un seul endroit.

Contexte de reponse

Les reponses entrantes incluent :

  • ReplyToId, ReplyToBody et ReplyToSender quand disponibles.
  • Le contexte cite est ajoute au Body sous forme de bloc [Replying to ...].

C’est coherent entre tous les canaux.