OpenClaw Channel-Routing: Mehrere Kanäle und Agenten sauber zuordnen

Ein OpenClaw-Gateway kann Nachrichten aus Telegram, WhatsApp, Discord oder Slack gleichzeitig annehmen. Kritisch wird es, sobald zwei Konten, mehrere Agenten oder Gruppenräume beteiligt sind: Eine technisch erfolgreiche Antwort kann trotzdem im falschen Gespräch auftauchen.

Der Rückweg einer normalen Antwort wird vom Gateway anhand der eingehenden Nachricht und der Hostkonfiguration bestimmt. Das Modell sucht sich den Zielkanal nicht selbst aus. Für den Betrieb ergibt sich daraus eine klare Aufgabe: Jede Route muss so eng definiert und getestet sein, dass Eingang, zuständiger Agent, Session und Antwortziel nachvollziehbar bleiben.

Vier Begriffe, die du getrennt halten musst

Beim Routing greifen vier Ebenen ineinander:

• Channel bezeichnet den Anbieter oder Kanaltyp, etwa telegram, whatsapp, discord oder slack.
• AccountId identifiziert eine konkrete Konto-Instanz innerhalb eines Channels, sofern der Kanal mehrere Konten unterstützt.
• Agent ist die Arbeitsumgebung, die eine Nachricht verarbeitet.
• Session hält den jeweiligen Gesprächskontext, zum Beispiel für eine Direktnachricht, einen Raum oder einen Gruppenchat.

Eine eingehende Nachricht kehrt normalerweise über denselben Kanal zurück. Bei mehreren Konten reicht die Angabe „Discord“ oder „WhatsApp“ deshalb nicht aus: Auch die Konto-Instanz und der Gesprächskontext müssen stimmen.

Der Rückkanal und der gespeicherte Gesprächskontext sind dabei verschiedene Dinge. Direktnachrichten an denselben Agenten teilen sich standardmäßig dessen Hauptsession, auch wenn sie aus verschiedenen Kanälen stammen. Wenn du DM-Kontexte trennen willst, musst du den Session-Geltungsbereich passend zur gewünschten Kanal- oder Kontotrennung festlegen und anschließend prüfen.

webchat nimmt dabei eine Sonderrolle ein. Er bezeichnet den internen WebChat-UI-Kanal und sollte nicht wie ein frei konfigurierbarer ausgehender Kanal behandelt werden.

Wo Fehlrouting tatsächlich entsteht

OpenClaw würfelt den Rückweg nicht aus. Probleme entstehen meist durch Zuordnungen, die für ein kleines Setup bequem wirken und beim Ausbau mehr Fälle erfassen als beabsichtigt.

Wenn du die Gateway-Konfiguration zuerst sauber aufsetzen willst, hilft der Guide zum OpenClaw-Gateway mit JSON5. Für Discord lohnt sich zusätzlich der Blick auf Threads und Sessions bei ACP, weil dort der Gesprächskontext besonders sichtbar wird.

Ein typisches Fehlerbild: Ein Testchat erreicht das Gateway, der erwartete Agent antwortet, doch die Antwort erscheint unter dem falschen Konto oder in einem unerwarteten Raum. Dann hilft es wenig, den Prompt umzuschreiben. Prüfe den Annahmepfad:

1. Welcher Channel hat die Nachricht empfangen?
2. Welche Konto-Instanz war beteiligt?
3. Welchem Agenten wurde die Nachricht zugeordnet?
4. Welche Session wurde verwendet?
5. Wohin ging die tatsächliche Antwort?

Diese fünf Angaben gehören in einen belastbaren Routing-Test. Fehlt eine davon, bleibt ein scheinbar erfolgreicher Lauf schwer reproduzierbar.

Agenten vor den Kanälen ordnen

Lege Agenten mit stabilen IDs und klaren Zuständigkeiten an. Eine Route sollte anschließend eindeutig erkennen lassen, welche Arbeitsumgebung, Dateien und Gesprächskontexte zum Einsatz kommen.

Meine Betriebsregel dafür ist schlicht: Schalte keine weitere Route frei, solange die vorhandene nicht vollständig nachvollziehbar ist. Starte mit einem unkritischen Testchat und einem vorgesehenen Agenten. Wenn Eingang und Rückweg mehrfach erwartungsgemäß funktionieren, kannst du das Setup erweitern.

Deterministisches Routing macht eine breite oder missverständliche Konfiguration schließlich nicht automatisch verständlich.

Ein Prompt ersetzt keine Route

Eine normale Antwort folgt dem vom Gateway bestimmten Rückweg. Die Prompt-Anweisung „Schick das an Telegram“ ändert diese Zuordnung nicht zuverlässig und taugt nicht als Sicherheitsmechanismus.

Für einen bewussten Wechsel in einen anderen Kanal brauchst du ein explizites Messaging-Werkzeug und ein eindeutig angegebenes Ziel. Diese Grenze erschwert es, Inhalte allein durch eine Freitextanweisung aus einem privaten Kontext in einen anderen Raum umzuleiten.

Routing und Berechtigung sind zwei Prüfungen

Routing beantwortet, welcher Agent eine eingehende Nachricht erhält und wohin die normale Antwort zurückläuft. Zulassungsregeln entscheiden separat, ob ein Kanal, Konto, Raum oder Gruppenchat verarbeitet werden darf.

Zu diesen Regeln gehören beispielsweise:

• erlaubte Kanäle oder Konten,
• aktivierte Gruppen,
• Mention- oder Aktivierungsregeln,
• kanalbezogene Zulassungslisten.

Eine passende Agentenzuordnung bedeutet daher noch nicht, dass eine Nachricht verarbeitet werden darf. Umgekehrt macht eine erlaubte Nachricht eine zu breite Route nicht sicher. Prüfe beide Ebenen getrennt und halte jeweils Erwartung und Ergebnis fest.

Broadcast bleibt ein Sonderfall

Broadcast-Gruppen sind eine experimentelle Funktion ausschließlich für WhatsApp über den Webkanal. Sie können dort dieselbe eingehende Nachricht an mehrere Agenten verteilen. Die beteiligten Agenten arbeiten dabei in getrennten Sessions und veröffentlichen eigene Antworten.

Für Telegram, Slack, Discord und andere Kanäle ist Broadcast nicht als allgemeine Routing-Regel dokumentiert. Prüfe vor einem produktiven Einsatz die Broadcast-Dokumentation deiner installierten OpenClaw-Version und teste die konkrete WhatsApp-Web-Umgebung isoliert.

Für gewöhnliches Channel-Routing ersetzt Broadcast weder eindeutige Zuordnungen noch Zugriffskontrollen.

Ein kleiner Abnahmetest reicht zum Start

Teste jede Route einzeln. Halte dabei mindestens Eingangskanal, Konto, erwarteten Agenten, verwendeten Gesprächskontext und tatsächliches Antwortziel fest.

Prüfe nach jedem Lauf die verfügbaren Gateway-Statusinformationen und Logs auf den erkannten Kanal, das beteiligte Konto, den ausgewählten Agenten und die Session. Welche Diagnoseangaben verfügbar sind, hängt von deiner OpenClaw-Version und Umgebung ab.

Weicht das tatsächliche Ziel von der Erwartung ab, stoppe den Ausbau. Nimm die neue Route aus dem produktiven Verkehr oder beschränke sie wieder auf den Testchat, bis du den Annahmepfad erklären kannst. Ein Prompt-Workaround verdeckt das Problem nur.

Fazit für den produktiven Betrieb

Schalte einen weiteren Kanal erst frei, wenn du für die vorhandene Route fünf Fragen sicher beantworten kannst: Wo kam die Nachricht an, welches Konto nahm sie an, welcher Agent bearbeitete sie, welche Session hielt den Kontext und wo erschien die Antwort?

Das wirkt bei einem einzelnen Testchat übervorsichtig. Beim zweiten Konto oder einem Gruppenraum spart diese Disziplin jedoch genau die Fehlersuche, die sonst mit dem Satz beginnt: „Warum hat der Agent ausgerechnet dort geantwortet?“