Canali e routing

OpenClaw instrada le risposte verso il canale da cui e arrivato il messaggio. Il modello non sceglie un canale; il routing e deterministico e controllato dalla configurazione dell’host.

Termini chiave

• Channel: whatsapp, telegram, discord, slack, signal, imessage, webchat.
• AccountId: istanza account per canale (quando supportato).
• Account predefinito opzionale del canale: channels.<channel>.defaultAccount sceglie quale account viene usato quando un percorso in uscita non specifica accountId.
  • Nelle configurazioni multi-account, imposta un default esplicito (defaultAccount o accounts.default) quando sono configurati due o piu account. Senza di esso, il routing di fallback potrebbe scegliere il primo ID account normalizzato.
• AgentId: un workspace isolato + store di sessione (“cervello”).
• SessionKey: la chiave bucket usata per salvare il contesto e controllare la concorrenza.

Forme delle chiavi di sessione (esempi)

I messaggi diretti collassano nella sessione main dell’agent:

• agent:<agentId>:<mainKey> (predefinito: agent:main:main)

Gruppi e canali restano isolati per canale:

• Gruppi: agent:<agentId>:<channel>:group:<id>
• Canali/stanze: agent:<agentId>:<channel>:channel:<id>

Thread:

• I thread Slack/Discord aggiungono :thread:<threadId> alla chiave base.
• I topic dei forum Telegram incorporano :topic:<topicId> nella chiave del gruppo.

Esempi:

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

Pinning del route DM principale

Quando session.dmScope e main, i messaggi diretti possono condividere una sessione principale. Per evitare che il lastRoute della sessione venga sovrascritto da DM non del proprietario, OpenClaw deduce un proprietario fissato da allowFrom quando tutte queste condizioni sono vere:

• allowFrom ha esattamente una voce non-wildcard.
• La voce puo essere normalizzata in un ID mittente concreto per quel canale.
• Il mittente del DM in ingresso non corrisponde a quel proprietario fissato.

In quel caso di mismatch, OpenClaw registra comunque i metadati della sessione in ingresso, ma salta l’aggiornamento del lastRoute della sessione principale.

Regole di routing (come viene scelto un agent)

Il routing sceglie un agent per ogni messaggio in ingresso:

1. Match esatto sul peer (bindings con peer.kind + peer.id).
2. Match sul peer padre (ereditarieta del thread).
3. Match su guild + ruoli (Discord) via guildId + roles.
4. Match su guild (Discord) via guildId.
5. Match su team (Slack) via teamId.
6. Match su account (accountId sul canale).
7. Match su canale (qualsiasi account su quel canale, accountId: "*").
8. Agent predefinito (agents.list[].default, altrimenti prima voce della lista, fallback a main).

Quando un binding include piu campi di match (peer, guildId, teamId, roles), tutti i campi forniti devono corrispondere affinche quel binding si applichi.

L’agent corrispondente determina quale workspace e store di sessione vengono usati.

Gruppi broadcast (esegui piu agent)

I gruppi broadcast permettono di eseguire piu agent per lo stesso peer quando OpenClaw normalmente risponderebbe (ad esempio: nei gruppi WhatsApp, dopo il gating di menzione/attivazione).

Config:

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

Vedi: Gruppi broadcast.

Panoramica della configurazione

• agents.list: definizioni di agent con nome (workspace, modello, ecc.).
• bindings: mappa canali/account/peer in ingresso agli agent.

Esempio:

{
  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" },
  ],
}

Archiviazione delle sessioni

Gli store di sessione risiedono sotto la directory di stato (predefinita ~/.openclaw):

• ~/.openclaw/agents/<agentId>/sessions/sessions.json
• I transcript JSONL risiedono accanto allo store

Puoi sovrascrivere il percorso dello store tramite session.store e il templating {agentId}.

Il gateway e la scoperta sessioni ACP scansionano anche gli store agent su disco sotto la root predefinita agents/ e sotto le root session.store con template risolto. Gli store scoperti devono restare dentro quella root agent risolta e usare un file regolare sessions.json. I symlink e i percorsi fuori dalla root vengono ignorati.

Comportamento WebChat

WebChat si aggancia all’agent selezionato e usa per default la sessione principale dell’agent. Per questo, WebChat permette di vedere il contesto cross-canale per quell’ agent in un unico posto.

Contesto delle risposte

Le risposte in ingresso includono:

• ReplyToId, ReplyToBody e ReplyToSender quando disponibili.
• Il contesto citato viene aggiunto a Body come blocco [Replying to ...].

Questo e coerente tra i canali.