Gruppennachrichten und Raumverhalten

Die meisten Bot-Probleme in Gruppenchats sind keine Technikfehler. Es sind Manierenfehler.

Eine private DM kann einen gesprächigen Assistenten noch verkraften. Ein geteilter Raum nicht. In dem Moment, in dem ein Agent in eine Gruppe zieht, wird jede Antwort öffentlich, jeder Fehltrigger nerviger und jeder Kontextfehler bekommt Publikum.

Die offiziellen OpenClaw Groups-Doku und die Channel-Routing-Doku machen die Kernidee ziemlich klar: Gruppenverhalten ist ein eigener Betriebsmodus. Es ist nicht bloß eine DM mit mehr Augen darauf.

Was sich in Gruppenkontexten ändert

In einer Direktnachricht geht es vor allem darum, ob diese Person überhaupt mit dem Agenten sprechen darf. In einer Gruppe wird die Frage breiter: Wer darf ihn triggern, wann soll er antworten, welchen Kontext soll er behalten und wie sichtbar soll dieses Verhalten sein?

OpenClaw nimmt diesen Wechsel ernst. Gruppennachrichten bekommen ihre eigene Policy-Schicht, ihren eigenen Allowlist-Pfad und ihre eigenen Session-Key-Formen. Diese Trennung ist keine Deko. Sie verhindert, dass ein lauter Raum in alles andere hineinblutet.

• Gruppenzugriff ist getrennt von DM-Zugriff
• Mentions und Aktivierungsregeln steuern, ob der Bot aufwachen soll
• Gruppen-Sessions bleiben vom Hauptkontext der DMs getrennt
• sichtbare Antworten können automatisch oder bewusst nur per Message-Tool erfolgen

Stell dir das wie Büro-Etikette vor. Ein nützlicher Kollege im geteilten Raum antwortet nicht auf jeden Satz. Er wartet auf seinen Einsatz, spricht, wenn der Raum davon profitiert, und vermeidet es, sich selbst zur Hauptfigur zu machen.

Die Standardhaltung sollte Zurückhaltung sein

Die aktuellen Dokus lehnen sich in die richtige Richtung. Group Policy startet standardmäßig auf Allowlist-Verhalten, und Mention-Gating ist der normale Einstieg. Gut so. Geteilte Räume sollten sich fail-closed anfühlen, bis du sie absichtlich öffnest.

Das ist wichtig, weil Gruppenlärm schnell eskaliert. Ein versehentlicher Trigger ist leicht nervig. Zehn pro Tag sorgen dafür, dass Menschen den Bot entfernen und dem ganzen Setup nicht mehr trauen.

Wenn du unsicher bist, wo du anfangen sollst, ist dieses Muster absichtlich langweilig:

• erlaube nur die Räume, die du wirklich willst
• erlaube nur die Sender, denen du dort Trigger-Rechte geben willst
• verlange anfangs Mentions
• lockere das Raumverhalten erst, wenn das Grundsetup ruhig wirkt

Wann der Bot antworten sollte und wann er still bleiben sollte

Die meisten Gruppen wollen eines von drei Verhaltensmustern.

1. Mention-gesteuerter Helfer

Das ist der vernünftige Standard für die meisten Teams. Der Bot antwortet, wenn ihn jemand ausdrücklich erwähnt, auf eine seiner Nachrichten antwortet oder einen Befehl nutzt. Alles andere bleibt Hintergrundrauschen.

Nutze das, wenn der Raum menschenzentriert ist und der Agent nur auf Abruf helfen soll.

2. Immer aktiver Raum mit stiller Aufmerksamkeit

Manche Räume profitieren von passivem Kontext. Ein Ops-Raum, Projektkanal oder wiederkehrender Troubleshooting-Thread kann davon leben, dass der Agent Muster bemerkt, ohne in jeden Austausch zu springen.

Genau dafür lohnen sich Raumereignisse im Hintergrund. Erlaubtes ungenanntes Gespräch wird zu stillem Kontext statt zu einer normalen Nutzeranfrage. Der Agent bleibt aufmerksam, aber der Raum bleibt ruhig, bis der Agent bewusst eine sichtbare Nachricht sendet.

3. Immer aktiver sichtbarer Antwortgeber

Das sollte selten sein. Es kann in einem dedizierten Support-Raum, einem bot-zentrierten Workflow-Kanal oder einem engen Test-Raum sinnvoll sein. Außerhalb davon werden daraus meist Unterbrechungen, die nur als Automation verkleidet sind.

Wenn du diesen Modus brauchst, zieh Publikum und Raumumfang hart zusammen. Sonst installierst du im Grunde einen Kollegen, der aus Spaß auf alle antwortet.

Wie Routing das Raumverhalten beeinflusst

Routing entscheidet über mehr als den Zielort der Antwort. Es entscheidet, welcher Agent den Raum bekommt, welche Session den Kontext speichert und ob ein Thread oder Topic vom übergeordneten Raum getrennt bleibt.

Das ist wichtig, weil Raumverhalten teils sozial und teils architektonisch ist. Wenn ein Telegram-Topic, Slack-Thread oder Discord-Channel den falschen Session-Bucket teilt, sitzen deine sauberen Etikette-Regeln trotzdem auf matschigem Kontext.

Die Channel-Routing-Doku zeigt das nützliche Muster: Direktnachrichten laufen meist in Main-Session-Verhalten, während Gruppen und Räume kanal-spezifische Session-Keys behalten. Genau diese Trennung brauchst du dort am meisten, wo Räume geteilt sind.

• Gruppenräume behalten ihren eigenen Kontext-Bucket
• Foren-Topics und Threads können innerhalb des größeren Raums isoliert bleiben
• Bindings lassen einen Raum bei Bedarf zu einem anderen Agenten routen
• operative Kommunikation kann von lockerem Team-Geplauder ferngehalten werden

Auf gut Deutsch: Routing verhindert, dass ein Support-Kanal deinem privaten Assistenten schlechte Angewohnheiten beibringt.

Eine saubere Config-Form für geteilte Räume

Die Details unterscheiden sich je nach Kanal, aber die Form sollte die Raumregeln sofort sichtbar machen.

{
  messages: {
    groupChat: {
      unmentionedInbound: "room_event",
      visibleReplies: "message_tool",
      historyLimit: 50,
    },
  },
  channels: {
    telegram: {
      groupPolicy: "allowlist",
      groupAllowFrom: ["accessGroup:operators"],
      groups: {
        "-1001234567890": {
          requireMention: false,
        },
      },
    },
  },
}

Der Punkt ist nicht, dass jeder Raum ambient sein sollte. Der Punkt ist, dass Raumverhalten explizit sein sollte. Wenn ein Raum immer aktiv ist, sag das klar. Wenn er trotzdem strenge Sender-Kontrollen braucht, sag auch das klar.

Etikette-Regeln, die laute Automationen verhindern

Gutes Raumverhalten ist nicht nur Config. Es ist Policy mit sozialen Folgen.

1. Setze keinen Always-on-Agenten in einen Raum, der nie danach gefragt hat. Technischer Zugriff ist nicht dasselbe wie soziale Erlaubnis.
2. Nutze Mention-Gating, bis du etwas Lockeres sauber begründen kannst. Raumruhe zu bewahren ist leichter, als sie später zurückzugewinnen.
3. Mach sichtbare Antworten bewusst. Nur-per-Message-Tool-Ausgabe ist für ambient oder lautere Räume oft sauberer.
4. Halte den Raumzweck eng. Ein Bot darf im Test-Raum gesprächiger sein als im Leadership-Raum. Beide sollten nicht dieselbe faule Voreinstellung teilen.
5. Sag den Menschen, was der Raum-Bot tut. Stille Aufmerksamkeit ohne klare Erwartung kippt von nützlicher Automation schnell in merkwürdige Überwachungs-Energie.

Dahinter steckt eine alte Büro-Wahrheit: Menschen verzeihen ein leises Tool. Ein lautes Tool, das behauptet zu helfen, verzeihen sie nicht.

Häufige Fehler

• Gruppenzugriff wie eine Kopie von DM-Zugriff zu behandeln
• Mention-Anforderungen zu früh abzuschalten
• automatische sichtbare Antworten in Räumen zu nutzen, die eigentlich bewusstes Sprechen brauchen
• zu vergessen, dass Routing und Session-Keys Verhalten genauso prägen wie Prompts
• den Bot in gemischt genutzte Räume ohne klare Erwartung zu setzen

Keiner dieser Fehler sieht in der Config dramatisch aus. Sie lassen den Bot nur leicht daneben wirken, immer wieder, bis der Raum ihn nicht mehr dort haben will.

Die Kurzfassung

• Gruppenräume brauchen strengere Standards als private Chats
• der beste Standard ist meist allowlisted, mention-gesteuert und ruhig
• Ambient Room Events sind nützlich, wenn Kontext wichtiger ist als Dauerantworten
• Routing und Session-Isolation verhindern, dass ein Raum den anderen verunreinigt
• gute Etikette ist Teil der Architektur und kein weicher Bonus

Wenn sich dein OpenClaw-Bot in geteilten Räumen gut benimmt, hören Menschen auf, den Bot zu bemerken, und fangen an, die Hilfe zu bemerken. Genau das ist der Gewinn.