Kanal Routing

Kanal Routing ist die Vermittlungsstelle hinter deinem OpenClaw-Setup. Wenn dein Agent über Telegram, Slack, Discord, WhatsApp oder WebChat lebt, entscheidet Routing, welches Gehirn die Nachricht bekommt, welcher Session Key den Kontext speichert und wohin die Antwort zurückgeht.

Das klingt technisch, aber die praktische Folge ist simpel. Gutes Routing lässt einen Agenten organisiert und vertrauenswürdig wirken. Schlechtes Routing lässt ihn laut, verwirrt und ein bisschen unheimlich wirken.

Die offizielle OpenClaw-Doku ist bei einem Punkt sehr eindeutig: Antworten gehen zurück in den Kanal, aus dem die Nachricht kam. Das Modell erfindet sein Ziel nicht selbst. Routing ist deterministisch und wird durch Host-Konfiguration, Bindings, Account Scope, Peer Scope und Session-Key-Regeln gesteuert.

Was Kanal Routing eigentlich steuert

Wenn Menschen von "Routing" sprechen, meinen sie oft nur, aus welcher App eine Nachricht kam. Das ist nur ein Teil. In OpenClaw steuert Routing mehrere Dinge gleichzeitig:

• welcher Agent für die eingehende Nachricht gewählt wird
• welcher Session Key den Gesprächskontext speichert
• ob die Nachricht in einem DM-, Gruppen-, Kanal- oder Thread-Bucket landet
• welcher Account genutzt wird, wenn für ausgehende Zustellung ein Default nötig ist
• ob Sonderfälle wie Broadcast Groups den normalen Ein-Agenten-Fluss verändern

Denk an eine Telefonzentrale im Büro. Dem Anrufer ist egal, welche Queue, welcher Schreibtisch, welche Eskalationsspur und welcher Ticket-Topf intern genutzt wurden. Entscheidend ist nur, ob die richtige Person ohne Weiterleitungszirkus erreicht wurde. Kanal Routing ist genau diese interne Logik.

Warum schlechtes Routing laute Agenten erzeugt

Laute Agenten sind meist kein Persönlichkeitsproblem. Sie sind ein Architekturproblem.

Wenn private DMs, öffentliche Gruppen und operative Alerts alle auf demselben Routing-Pfad landen, mischt der Agent Kontexte, die getrennt bleiben sollten. Daraus entstehen ein paar sehr typische Symptome:

• der falsche Ton im falschen Raum
• Antworten in Gruppen, die privat hätten bleiben sollen
• Session Memory, das durch unzusammenhängende Kommunikation verschmutzt wird
• Tool-Entscheidungen, die in einem Kanal sicher sind, in einem anderen aber riskant
• schwindendes Vertrauen, weil der Agent sich aufdringlich anfühlt

Genau deshalb trennt die OpenClaw-Doku zu Gruppenverhalten, Mention Gating und sichtbaren Antworten diese Dinge von gewöhnlichem DM-Verhalten. Ein öffentlicher Raum ist eben nicht nur ein DM mit mehr Zuschauern.

Wie OpenClaw einen Agenten auswählt

Laut offizieller channels/channel-routing-Doku prüft OpenClaw Routing in fester Reihenfolge. Spezifische Matches schlagen breite Regeln. Genau das willst du, denn eine enge Regel für einen konkreten Peer sollte wichtiger sein als eine vage Regel für einen ganzen Kanal.

Die dokumentierte Reihenfolge sieht so aus:

1. exakter Peer Match
2. Parent Peer Match, etwa durch Thread-Vererbung
3. Guild- und Rollen-Match für Discord
4. Guild-Match für Discord
5. Team-Match für Slack
6. Account-Match für einen bestimmten Kanal-Account
7. Kanal-Match für irgendeinen Account in diesem Kanal
8. Default-Agent als Fallback

Diese Reihenfolge ist wichtig. Sie erlaubt dir zum Beispiel, einen breiten Slack-Support-Agenten zu definieren und danach einen konkreten Kanal oder Thread zu überschreiben, wenn dort eine andere Persona, Tool-Policy oder ein anderer Workflow nötig ist.

Session Keys sind Teil des Routings, kein Nebendetail

Einer der häufigsten Denkfehler ist, nur darauf zu schauen, wer antwortet, und zu ignorieren, wo der Kontext gespeichert wird. OpenClaw nutzt unterschiedliche Session-Key-Formen für DMs, Gruppen, Kanäle und Threads. Die Doku zeigt Gruppen-Sessions, Kanal-Sessions und Thread-Suffixe als getrennte Buckets.

Das ist kein unnötiger Verwaltungsaufwand, sondern ein Geschenk. So kann ein Telegram-Forum-Topic isoliert bleiben, und ein Discord-Thread behält seinen eigenen Kontext, statt alles in einen riesigen Raumspeicher zu kippen.

Wenn ein Agent schon einmal einem Team mit Resten aus einem völlig anderen Gespräch geantwortet hat, dann hast du bereits gespürt, warum Session-Key-Design wichtig ist.

Private, Gruppen- und operative Kommunikation sollten nicht gleich behandelt werden

Das ist der praktische Kern des Themas. Die meisten Setups werden schnell besser, wenn du dein Routing in drei Flächen aufteilst:

1. Private Kommunikation

Direktnachrichten sind der Ort, an dem Menschen Flexibilität, Memory und mehr persönlichen Kontext erwarten. Sie eignen sich oft für Workflows mit hohem Vertrauen, mehr Tool-Zugriff und echten Rückfragen.

2. Gruppenkommunikation

Gruppen brauchen strengere Defaults. Die Groups-Doku empfiehlt Allowlists und Mention Gating nicht aus Spaß. Gruppen erzeugen mehr Rauschen, mehr versehentliche Trigger und mehr Chancen auf Oversharing.

3. Operative Kommunikation

Ops-Räume, Benachrichtigungsthreads und Logging-Kanäle sollten bewusst geroutet werden. Diese Flächen brauchen oft low-noise Verhalten, andere Regeln für sichtbare Antworten und engere Befugnisse als ein normaler Support-Raum.

Eine gute Faustregel lautet: Wenn eine Routing-Policy gleichzeitig "sprich privat mit mir" und "poste Deployment-Alerts in einen Teamraum" abdecken soll, ist sie wahrscheinlich zu breit.

Praktische Routing-Muster, die funktionieren

Muster 1: Ein persönlicher Agent, gesandboxte öffentliche Gruppen

Die OpenClaw-Groups-Doku beschreibt ein nützliches Muster, bei dem persönliche DMs auf der Main Route bleiben, während nicht-main Gruppen-Sessions gesandboxed mit engerem Tool-Zugriff laufen. So behältst du eine Agenten-Identität, aber eine andere Ausführungslogik je nach Oberfläche.

Das ist stark, wenn du ein konsistentes Gehirn willst, aber öffentlichen Räumen nicht dieselbe Freiheit geben möchtest wie deinem privaten Chat.

Muster 2: Getrennter Agent für Support oder Operations

Wenn sich Ton, Tools oder Risikoprofil stark unterscheiden, binde diese Räume an einen eigenen Agenten. Das ist oft sauberer, als jeden Sonderfall in einen einzigen Default-Agenten zu stopfen.

Nutze das, wenn du echte Trennung brauchst und nicht nur leicht andere Raumeinstellungen.

Muster 3: Peer-spezifische Overrides für sensible Räume

Starte breit und schneide dann genaue Peers aus, die eine eigene Route verdienen. Ein einzelner Executive-Thread, ein Incident-Kanal oder ein Eskalationsraum für Kunden kann schon einen spezifischen Binding rechtfertigen, selbst wenn alles andere auf einer breiteren Kanalregel bleibt.

Muster 4: Broadcast nur dann, wenn mehrere Agenten wirklich nötig sind

Broadcast Groups sind nicht die Standardantwort auf Routing. Die aktuelle Doku beschreibt sie als experimentell und derzeit WhatsApp-fokussiert. Nutze sie nur, wenn eine zulässige Nachricht wirklich mehrere Spezialisten parallel oder nacheinander starten soll. Sonst bleibt normales Routing klarer und berechenbarer.

Ein sauberer Beispielaufbau für die Konfiguration

Du brauchst keine gigantische Routing-Datei, um vernünftiges Verhalten zu bekommen. Entscheidend ist, dass deine Absicht klar ist.

{
  agents: {
    list: [
      { id: "main", name: "Main" },
      { id: "support", name: "Support" },
      { id: "ops", name: "Ops" }
    ]
  },
  bindings: [
    { match: { channel: "slack", teamId: "T123" }, agentId: "support" },
    { match: { channel: "telegram", peer: { kind: "group", id: "-100777" } }, agentId: "ops" },
    { match: { channel: "discord", guildId: "G456" }, agentId: "support" }
  ]
}

Es geht nicht um die Syntax. Es geht darum, dass Support-Traffic, Ops-Traffic und alles andere nicht mehr um dieselbe vage Default-Logik kämpfen.

Was die lokale Quellprüfung bestätigt

Aktuelle lokale OpenClaw-Build-Artefakte passen hier zur Doku. Das Config-Schema zeigt top-level Bindings und Broadcast-Konfiguration sowie Group-Policy-Steuerung. Auch der Route Resolver spiegelt eine geordnete Binding-Auswertung wider und keine zufällige Modellentscheidung. Kurz gesagt: Die Doku beschreibt echte Routing-Mechanik und nicht bloß Produktnebel.

Häufige Routing-Fehler

• einen einzigen Default-Agenten für alles zu nutzen und Symptome später zu flicken
• zu vergessen, dass Session-Key-Formen das Kontextverhalten verändern
• Gruppenchats wie private Chats zu behandeln
• Support und interne Operations in dieselbe sichtbare Raumstrategie zu mischen
• zu früh nach Broadcast Groups zu greifen, bevor normale Bindings sauber sind

Fast alle dieser Fehler sind Varianten derselben Sache: Eine breite Regel soll Räume mit völlig unterschiedlichen Erwartungen gleichzeitig abdecken.

Die praktische Faustregel

Route zuerst nach menschlichen Erwartungen und erst danach nach technischer Bequemlichkeit. Private Chats brauchen Memory und Flexibilität. Gruppenräume brauchen Zurückhaltung und klare Trigger-Regeln. Operative Räume brauchen Signal und Kontrolle.

Wenn du diese Unterschiede respektierst, wirkt OpenClaw ruhig. Ignorierst du sie, verhält sich dein Agent wie ein Kollege, der auf alles mit Antwort an alle reagiert.