Kanäle & Routing

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

Schlüsselbegriffe

Channel: whatsapp, telegram, discord, slack, signal, imessage, webchat.
AccountId: Pro-Kanal-Kontoinstanz (wenn unterstützt).
Optionales Kanal-Standardkonto: channels.<channel>.defaultAccount bestimmt, welches Konto verwendet wird, wenn ein ausgehender Pfad keine accountId angibt.
- Bei Multi-Account-Setups setze einen expliziten Standard (defaultAccount oder accounts.default), wenn zwei oder mehr Konten konfiguriert sind. Ohne diesen kann das Fallback-Routing die erste normalisierte Account-ID wählen.
AgentId: ein isolierter Workspace + Session-Store („Gehirn”).
SessionKey: der Bucket-Schlüssel zum Speichern von Kontext und zur Steuerung der Parallelität.

Session-Key-Formen (Beispiele)

Direktnachrichten werden zur Haupt-Session des Agenten zusammengeführt:

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

Gruppen und Kanäle bleiben pro Kanal isoliert:

Gruppen: agent:<agentId>:<channel>:group:<id>
Kanäle/Räume: agent:<agentId>:<channel>:channel:<id>

Threads:

Slack/Discord-Threads hängen :thread:<threadId> an den Basisschlüssel an.
Telegram-Forum-Topics betten :topic:<topicId> in den Gruppenschlüssel ein.

Beispiele:

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

Haupt-DM-Route-Pinning

Wenn session.dmScope main ist, können Direktnachrichten eine gemeinsame Hauptsession teilen. Um zu verhindern, dass die lastRoute der Session durch Nicht-Besitzer-DMs überschrieben wird, leitet OpenClaw einen gepinnten Besitzer aus allowFrom ab, wenn alle folgenden Bedingungen erfüllt sind:

allowFrom hat genau einen Nicht-Wildcard-Eintrag.
Der Eintrag kann zu einer konkreten Absender-ID für diesen Kanal normalisiert werden.
Der eingehende DM-Absender stimmt nicht mit diesem gepinnten Besitzer überein.

In diesem Fall zeichnet OpenClaw weiterhin eingehende Session-Metadaten auf, überspringt aber die Aktualisierung der lastRoute der Hauptsession.

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

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

Exakte Peer-Übereinstimmung (bindings mit peer.kind + peer.id).
Parent-Peer-Übereinstimmung (Thread-Vererbung).
Guild + Rollen-Übereinstimmung (Discord) über guildId + roles.
Guild-Übereinstimmung (Discord) über guildId.
Team-Übereinstimmung (Slack) über teamId.
Account-Übereinstimmung (accountId auf dem Kanal).
Kanal-Übereinstimmung (beliebiges Konto auf diesem Kanal, accountId: "*").
Standard-Agent (agents.list[].default, sonst erster Listeneintrag, Fallback auf main).

Wenn ein Binding mehrere Match-Felder enthält (peer, guildId, teamId, roles), müssen alle angegebenen Felder übereinstimmen, damit das Binding greift.

Der zugeordnete Agent bestimmt, welcher Workspace und Session-Store verwendet werden.

Broadcast-Gruppen (mehrere Agenten ausführen)

Broadcast-Gruppen ermöglichen es, mehrere Agenten für denselben Peer auszuführen, wenn OpenClaw normalerweise antworten würde (zum Beispiel: in WhatsApp-Gruppen nach Mention/Activation-Gating).

Konfiguration:

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

Siehe: Broadcast Groups.

Konfigurationsübersicht

agents.list: benannte Agentendefinitionen (Workspace, Modell usw.).
bindings: ordne eingehende Kanäle/Konten/Peers Agenten 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-Speicher

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

~/.openclaw/agents/<agentId>/sessions/sessions.json
JSONL-Transkripte befinden sich neben dem Store

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

Gateway- und ACP-Session-Discovery durchsucht auch festplattenbasierte Agent-Stores unter dem Standard-agents/-Root und unter templatisierten session.store-Roots. Entdeckte Stores müssen innerhalb dieses aufgelösten Agent-Roots bleiben und eine reguläre sessions.json-Datei verwenden. Symlinks und Pfade außerhalb des Roots werden ignoriert.

WebChat-Verhalten

WebChat verbindet sich mit dem ausgewählten Agenten und nutzt standardmäßig die Hauptsession des Agenten. Dadurch kannst du kanalübergreifenden Kontext für diesen Agenten an einem Ort sehen.

Antwortkontext

Eingehende Antworten enthalten:

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

Dies ist kanalübergreifend konsistent.