Channels & Routing

OpenClaw leitet Antworten zurück an den Channel, von dem die Nachricht kam. Das Modell wählt keinen Channel aus — das Routing ist deterministisch und wird durch die Host-Konfiguration gesteuert.

Wichtige Begriffe

  • Channel: whatsapp, telegram, discord, slack, signal, imessage, webchat.
  • AccountId: Konto-Instanz pro Channel (wenn unterstützt).
  • AgentId: Ein isolierter Workspace + Session-Speicher (das „Gehirn”).
  • SessionKey: Der Bucket-Key zum Speichern von Kontext und zur Steuerung der Parallelität.

Session-Key-Formate (Beispiele)

Direktnachrichten werden in der main-Session des Agents zusammengeführt:

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

Gruppen und Channels bleiben pro Channel isoliert:

  • Gruppen: agent:<agentId>:<channel>:group:<id>
  • Channels/Räume: agent:<agentId>:<channel>:channel:<id>

Threads:

  • Slack/Discord-Threads hängen :thread:<threadId> an den Basis-Key an.
  • Telegram-Forum-Topics betten :topic:<topicId> in den Gruppen-Key ein.

Beispiele:

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

Routing-Regeln (wie ein Agent ausgewählt wird)

Das Routing wählt einen Agent für jede eingehende Nachricht:

  1. Exakter Peer-Match (bindings mit peer.kind + peer.id).
  2. Guild-Match (Discord) über guildId.
  3. Team-Match (Slack) über teamId.
  4. Account-Match (accountId auf dem Channel).
  5. Channel-Match (beliebiges Konto auf diesem Channel).
  6. Standard-Agent (agents.list[].default, sonst erster Listeneintrag, Fallback auf main).

Der gematchte Agent bestimmt, welcher Workspace und Session-Speicher verwendet werden.

Broadcast-Gruppen (mehrere Agents ausführen)

Mit Broadcast-Gruppen kannst du mehrere Agents für denselben Peer ausführen, wenn OpenClaw normalerweise antworten würde (zum Beispiel: in WhatsApp-Gruppen, nach Mention/Aktivierungs-Gating).

Konfiguration:

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

Siehe: Broadcast-Gruppen.

Konfigurations-Übersicht

  • agents.list: Benannte Agent-Definitionen (Workspace, Modell usw.).
  • bindings: Ordnet eingehende Channels/Konten/Peers den Agents zu.

Beispiel:

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

Session-Speicherung

Session-Speicher befinden sich im State-Verzeichnis (Standard: ~/.openclaw):

  • ~/.openclaw/agents/<agentId>/sessions/sessions.json
  • JSONL-Transkripte liegen neben dem Speicher

Du kannst den Speicherpfad über session.store und {agentId}-Templating überschreiben.

WebChat-Verhalten

WebChat verbindet sich mit dem ausgewählten Agent und verwendet standardmäßig die main-Session des Agents. Dadurch kannst du im WebChat den kanalübergreifenden Kontext für diesen Agent an einem Ort sehen.

Antwort-Kontext

Eingehende Antworten enthalten:

  • ReplyToId, ReplyToBody und ReplyToSender, wenn verfügbar.
  • Zitierter Kontext wird als [Replying to ...]-Block an Body angehängt.

Das ist über alle Channels hinweg konsistent.