Gruppen

OpenClaw wendet dieselben Gruppenregeln auf alle gruppenfähigen Kanäle an, darunter Discord, iMessage, Matrix, Microsoft Teams, QQBot, Signal, Slack, Telegram, WhatsApp und Zalo.

Informationen zu dauerhaft aktiven Räumen, die unaufdringlich Kontext bereitstellen sollen, sofern der Agent nicht ausdrücklich eine sichtbare Nachricht sendet, finden Sie unter Umgebungsbezogene Raumereignisse.

Einführung für Einsteiger (2 Minuten)

OpenClaw „lebt“ in Ihren eigenen Messaging-Konten. Es gibt keinen separaten WhatsApp-Bot-Benutzer: Wenn Sie Mitglied einer Gruppe sind, kann OpenClaw diese Gruppe sehen und dort antworten.

Standardverhalten:

• Gruppen sind eingeschränkt (groupPolicy: "allowlist"); Absender in Gruppen werden blockiert, bis sie auf die Zulassungsliste gesetzt werden.
• Antworten erfordern eine Erwähnung, sofern Sie die Erwähnungsprüfung für eine Gruppe nicht deaktivieren.
• Der endgültige Antworttext wird automatisch im Raum veröffentlicht (visibleReplies: "automatic").

Das bedeutet: Zugelassene Absender können OpenClaw auslösen, indem sie es erwähnen.

Kurzer Ablauf (was mit einer Gruppennachricht geschieht):

groupPolicy? disabled -> verwerfengroupPolicy? allowlist -> Gruppe zugelassen? nein -> verwerfenrequireMention? ja -> erwähnt? nein -> nur als Kontext speichernErwähnung/Antwort/Befehl/DM -> BenutzeranfrageUnterhaltungen in dauerhaft aktiven Gruppen -> Benutzeranfrage oder, wenn konfiguriert, Raumereignis

Sichtbare Antworten

Bei normalen Gruppen-/Kanalanfragen verwendet OpenClaw standardmäßig messages.groupChat.visibleReplies: "automatic": Der endgültige Assistententext wird als sichtbare Antwort im Raum veröffentlicht.

Verwenden Sie messages.groupChat.visibleReplies: "message_tool", wenn der Agent in einem gemeinsam genutzten Raum selbst entscheiden soll, wann er spricht, indem er message(action=send) aufruft. Dies funktioniert am besten mit Modellen, die Tools zuverlässig verwenden (beispielsweise GPT-5.6 Sol). Wenn das Modell das Tool nicht verwendet und stattdessen substanziellen endgültigen Text zurückgibt, hält OpenClaw diesen Text privat, anstatt ihn im Raum zu veröffentlichen.

Verwenden Sie "automatic" für Modelle oder Laufzeitumgebungen, die eine ausschließlich toolbasierte Zustellung nicht zuverlässig befolgen: Normale endgültige Textantworten werden direkt im Raum veröffentlicht, und der Agent kann weiterhin message(action=send) für Dateien, Bilder oder andere Anhänge aufrufen, die nicht zusammen mit dem endgültigen Text übertragen werden können.

Wenn das Nachrichtentool gemäß der aktiven Tool-Richtlinie nicht verfügbar ist, greift OpenClaw auf automatische sichtbare Antworten zurück, anstatt die Antwort stillschweigend zu unterdrücken. openclaw doctor warnt vor dieser Diskrepanz.

Für Direktchats und alle anderen Quellereignisse wendet messages.visibleReplies: "message_tool" dasselbe ausschließlich toolbasierte Verhalten global an; messages.groupChat.visibleReplies bleibt die spezifischere Überschreibung für Gruppen-/Kanalräume. Interne direkte WebChat-Interaktionen verwenden standardmäßig die automatische Zustellung endgültiger Antworten, sodass Pi und Codex denselben Vertrag für sichtbare Antworten erhalten.

Der ausschließlich toolbasierte Modus ersetzt das frühere Muster, das Modell bei den meisten Interaktionen im stillen Beobachtungsmodus zu einer Antwort mit NO_REPLY zu zwingen. Im ausschließlich toolbasierten Modus definiert der Prompt keinen NO_REPLY-Vertrag; nichts sichtbar zu tun bedeutet lediglich, das Nachrichtentool nicht aufzurufen.

Plugin-eigene Konversationsbindungen bilden die Ausnahme. Sobald ein Plugin einen Thread bindet und die eingehende Interaktion übernimmt, ist die vom Plugin zurückgegebene Antwort die sichtbare Bindungsantwort; sie benötigt message(action=send) nicht. Diese Antwort ist eine Ausgabe der Plugin-Laufzeitumgebung und kein privater endgültiger Modelltext.

Bei direkten Gruppenanfragen werden weiterhin Tippindikatoren gesendet. Umgebungsbezogene Ereignisse dauerhaft aktiver Räume bleiben, wenn aktiviert, strikt und unaufdringlich, sofern der Agent nicht das Nachrichtentool aufruft.

Sitzungen unterdrücken standardmäßig ausführliche Tool-/Fortschrittszusammenfassungen. Verwenden Sie beim Debuggen /verbose on (oder /verbose full), um sie für die aktuelle Sitzung anzuzeigen, und /verbose off, um zum Verhalten mit ausschließlich endgültigen Antworten zurückzukehren. Der Ausführlichkeitsstatus gilt pro Sitzung und funktioniert in Direktchats, Gruppen, Kanälen und Forenthemen gleich.

Um nicht erwähnte Unterhaltungen in dauerhaft aktiven Gruppen als unaufdringlichen Raumkontext statt als Benutzeranfragen zu übermitteln, verwenden Sie Umgebungsbezogene Raumereignisse:

{  messages: {    groupChat: {      unmentionedInbound: "room_event",    },  },}

Der Standardwert ist unmentionedInbound: "user_request". Erwähnte Nachrichten, Befehle, Abbruchanfragen und DMs bleiben Benutzeranfragen.

So erzwingen Sie, dass sichtbare Ausgaben für Gruppen-/Kanalanfragen über das Nachrichtentool gesendet werden:

{  messages: {    groupChat: {      visibleReplies: "message_tool",    },  },}

So erzwingen Sie dies für jeden Quellchat:

{  messages: {    visibleReplies: "message_tool",  },}

Das Gateway übernimmt Änderungen an der messages-Konfiguration nach dem Speichern der Datei ohne Neustart. Starten Sie nur neu, wenn das erneute Laden der Konfiguration deaktiviert ist (gateway.reload.mode: "off").

Befehlsinteraktionen umgehen visibleReplies: "message_tool" und antworten immer sichtbar: Sowohl native Slash-Befehle (Discord, Telegram und andere Oberflächen mit nativer Befehlsunterstützung) als auch autorisierte /...-Textbefehle veröffentlichen ihre Antwort im Quellchat. Nicht autorisierte /...-Textinteraktionen in Gruppen bleiben ausschließlich nachrichtentoolbasiert; gewöhnliche Chatinteraktionen folgen dem konfigurierten Standard.

Kontextsichtbarkeit und Zulassungslisten

Für die Sicherheit von Gruppen sind zwei unterschiedliche Steuerungen relevant:

• Auslöseberechtigung: Wer den Agenten auslösen kann (groupPolicy, groups, groupAllowFrom, kanalspezifische Zulassungslisten).
• Kontextsichtbarkeit: Welcher ergänzende Kontext in das Modell eingespeist wird (Antwort-/Zitattext, Threadverlauf, weitergeleitete Metadaten).

Standardmäßig behält OpenClaw den Kontext so bei, wie er empfangen wurde: Zulassungslisten bestimmen, wer Aktionen auslösen kann, nicht welche zitierten oder historischen Ausschnitte das Modell sieht. Um auch ergänzenden Kontext zu filtern, legen Sie contextVisibility fest:

Legen Sie dies pro Kanal (channels.<channel>.contextVisibility), pro Konto (channels.<channel>.accounts.<accountId>.contextVisibility) oder global (channels.defaults.contextVisibility) fest. Kanäle, die ergänzenden Kontext abrufen (Discord, Feishu, iMessage, Matrix, Microsoft Teams, Signal, Slack, Telegram, WhatsApp), wenden die Richtlinie beim Erstellen des eingehenden Kontexts an; unbekannte Richtlinienkombinationen schlagen nach dem Fail-Closed-Prinzip fehl und lassen den Kontext weg.

Diese Modi filtern nur den vom Kanal bereitgestellten ergänzenden Kontext. Die Tool-Richtlinie und das ausschließlich dem Eigentümer vorbehaltene Tool-Inventar werden weiterhin anhand des ursprünglichen Anfragenden der aktuellen Interaktion ausgewählt, nicht anhand jedes im Prompt dargestellten Absenders. Siehe Auf den Anfragenden beschränkte Steuerungen und Prompt-Kontext.

Wenn Sie Folgendes erreichen möchten ...

Informationen zu wiederverwendbaren Absender-Zulassungslisten finden Sie unter Zugriffsgruppen.

Sitzungsschlüssel

• Gruppensitzungen verwenden agent:<agentId>:<channel>:group:<id>-Sitzungsschlüssel (Räume/Kanäle verwenden agent:<agentId>:<channel>:channel:<id>).
• Telegram-Forenthemen fügen der Gruppen-ID :topic:<threadId> hinzu, sodass jedes Thema über eine eigene Sitzung verfügt.
• Direktchats verwenden die Hauptsitzung (oder Sitzungen pro Absender, wenn session.dmScope konfiguriert ist).
• Heartbeats werden in der konfigurierten Heartbeat-Sitzung ausgeführt (Standard: Hauptsitzung des Agenten); Gruppensitzungen führen keine eigenen Heartbeats aus.

Muster: persönliche DMs + öffentliche Gruppen (ein Agent)

Ja — dies funktioniert gut, wenn Ihr „persönlicher“ Datenverkehr aus DMs und Ihr „öffentlicher“ Datenverkehr aus Gruppen besteht.

Grund: Im Einzelagentenmodus landen DMs üblicherweise unter dem Hauptsitzungs-Schlüssel (agent:main:main), während Gruppen immer Nicht-Hauptsitzungs-Schlüssel (agent:main:<channel>:group:<id>) verwenden. Wenn Sie Sandboxing mit mode: "non-main" aktivieren, werden diese Gruppensitzungen im konfigurierten Sandbox-Backend ausgeführt, während Ihre DM-Hauptsitzung auf dem Host verbleibt. Docker ist das Standard-Backend, wenn Sie kein anderes auswählen.

Dadurch erhalten Sie ein gemeinsames „Gehirn“ des Agenten (gemeinsamer Arbeitsbereich und Speicher), aber zwei Ausführungsmodi:

• DMs: vollständige Tools (Host)
• Gruppen: Sandbox und eingeschränkte Tools

{  agents: {    defaults: {      sandbox: {        mode: "non-main", // Gruppen/Kanäle sind keine Hauptsitzungen -> in der Sandbox        scope: "session", // stärkste Isolation (ein Container pro Gruppe/Kanal)        workspaceAccess: "none",      },    },  },  tools: {    sandbox: {      tools: {        // Wenn allow nicht leer ist, wird alles andere blockiert (deny hat weiterhin Vorrang).        allow: ["group:messaging", "group:sessions"],        deny: ["group:runtime", "group:fs", "group:ui", "nodes", "cron", "gateway"],      },    },  },}

{  agents: {    defaults: {      sandbox: {        mode: "non-main",        scope: "session",        workspaceAccess: "none",        docker: {          binds: [            // Hostpfad:Containerpfad:Modus            "/home/user/FriendsShared:/data:ro",          ],        },      },    },  },}

Verwandte Themen:

• Konfigurationsschlüssel und Standardwerte: Gateway-Konfiguration
• Debugging, warum ein Tool blockiert wird: Sandbox im Vergleich zu Tool-Richtlinie und erhöhten Berechtigungen
• Details zu Bind-Mounts: Sandboxing

Anzeigebezeichnungen

• UI-Bezeichnungen verwenden displayName, sofern verfügbar, formatiert als <channel>:<token>.
• #room ist für Räume/Kanäle reserviert; Gruppenchats verwenden g-<slug> (Kleinbuchstaben, Leerzeichen -> -, #@+._- beibehalten). Sehr lange undurchsichtige IDs werden zu einem stabilen Token verkürzt, statt vollständige Routing-IDs in der UI offenzulegen.

Gruppenrichtlinie

Steuern Sie pro Kanal, wie Gruppen-/Raumnachrichten behandelt werden:

{  channels: {    whatsapp: {      groupPolicy: "disabled", // "open" | "disabled" | "allowlist"      groupAllowFrom: ["+15551234567"],    },    telegram: {      groupPolicy: "disabled",      groupAllowFrom: ["123456789"], // numerische Telegram-Benutzer-ID (Einrichtung löst @username auf)    },    signal: {      groupPolicy: "disabled",      groupAllowFrom: ["+15551234567"],    },    imessage: {      groupPolicy: "disabled",      groupAllowFrom: ["chat_id:123"],    },    msteams: {      groupPolicy: "disabled",      groupAllowFrom: ["user@org.com"],    },    discord: {      groupPolicy: "allowlist",      guilds: {        GUILD_ID: { channels: { help: { enabled: true } } },      },    },    slack: {      groupPolicy: "allowlist",      channels: { "#general": { enabled: true } },    },    matrix: {      groupPolicy: "allowlist",      groupAllowFrom: ["@owner:example.org"],      groups: {        "!roomId:example.org": { enabled: true },        "#alias:example.org": { enabled: true },      },    },  },}

Kurzes mentales Modell (Auswertungsreihenfolge für Gruppennachrichten):

Erwähnungs-Gating (Standard)

Gruppennachrichten erfordern eine Erwähnung, sofern dies nicht pro Gruppe überschrieben wird. Standardwerte befinden sich je Subsystem unter *.groups."*".

Unterstützte implizite Erwähnungsfakten sind kanalspezifisch:

Jeder Fakt ist standardmäßig aktiviert, wenn der Kanal ihn erzeugt. Setzen Sie das entsprechende implicitMentions-Flag auf false, damit dieser Fakt das Erwähnungs-Gating nicht mehr umgeht; native explizite Erwähnungen bleiben davon unberührt. Ein Flag hat keine Auswirkung auf Kanäle, die diesen Fakt nicht erzeugen.

{  channels: {    whatsapp: {      groups: {        "*": { requireMention: true },        "123@g.us": { requireMention: false },      },    },    telegram: {      groups: {        "*": { requireMention: true },        "123456789": { requireMention: false },      },    },    imessage: {      groups: {        "*": { requireMention: true },        "123": { requireMention: false },      },    },  },  agents: {    entries: {      main: {        groupChat: {          mentionPatterns: ["@openclaw", "openclaw", "\\+15555550123"],          historyLimit: 50,        },      },    },  },}

Konfigurierte Erwähnungsmuster eingrenzen

Konfigurierte mentionPatterns sind Regex-Fallback-Auslöser. Verwenden Sie sie, wenn die Plattform keine native Bot-Erwähnung bereitstellt oder wenn Klartext wie openclaw: als Erwähnung gelten soll. Native Plattform-Erwähnungen sind separat: Wenn Discord, Slack, Telegram, Matrix, Signal oder ein anderer Kanal nachweisen kann, dass die Nachricht den Bot explizit erwähnt hat, löst diese native Erwähnung weiterhin aus, selbst wenn konfigurierte Regex-Muster verweigert werden.

Standardmäßig gelten konfigurierte Erwähnungsmuster überall dort, wo der Kanal Provider- und Konversationsfakten an die Erwähnungserkennung übergibt. Um zu verhindern, dass weit gefasste Muster den Agenten in jeder Gruppe aktivieren, grenzen Sie sie pro Kanal mit channels.<channel>.mentionPatterns ein.

Verwenden Sie mode: "deny", wenn Regex-Erwähnungsmuster für einen Kanal standardmäßig deaktiviert sein sollen, und aktivieren Sie sie anschließend mit allowIn für bestimmte Räume:

{  messages: {    groupChat: {      mentionPatterns: ["\\bopenclaw\\b", "\\bops bot\\b"],    },  },  channels: {    slack: {      mentionPatterns: {        mode: "deny",        allowIn: ["C0123OPS"],      },    },  },}

Verwenden Sie den Standardwert mode: "allow" (oder lassen Sie mode weg), wenn Regex-Erwähnungsmuster allgemein gelten sollen, und deaktivieren Sie sie anschließend mit denyIn in störungsreichen Räumen:

{  messages: {    groupChat: {      mentionPatterns: ["\\bopenclaw\\b"],    },  },  channels: {    telegram: {      mentionPatterns: {        denyIn: ["-1001234567890", "-1001234567890:topic:42"],      },    },  },}

Richtlinienauflösung:

Derzeit unterstützte eingegrenzte Regex-Richtlinien:

Kanalkonfigurationen auf Kontoebene können dieselbe Richtlinie unter channels.<channel>.accounts.<accountId>.mentionPatterns festlegen, wenn der Kanal mehrere Konten unterstützt. Die Kontorichtlinie hat für dieses Konto Vorrang vor der Kanalrichtlinie der obersten Ebene.

Tool-Einschränkungen für Gruppen/Kanäle (optional)

Einige Kanalkonfigurationen unterstützen die Einschränkung, welche Tools innerhalb einer bestimmten Gruppe/eines bestimmten Raums/Kanals verfügbar sind.

• tools: Tools für die gesamte Gruppe zulassen/verweigern (allow, alsoAllow, deny; Verweigerung hat Vorrang).
• toolsBySender: Absenderspezifische Überschreibungen innerhalb der Gruppe. Verwenden Sie explizite Schlüsselpräfixe: channel:<channelId>:<senderId>, id:<senderId>, e164:<phone>, username:<handle>, name:<displayName> und den Platzhalter "*". Kanal-IDs verwenden kanonische OpenClaw-Kanal-IDs; Aliase wie teams werden zu msteams normalisiert. Veraltete Schlüssel ohne Präfix werden weiterhin akzeptiert, nur als id: abgeglichen und protokollieren eine Veraltungswarnung.

Auflösungsreihenfolge (die spezifischste Regel hat Vorrang):

Beispiel (Telegram):

{  channels: {    telegram: {      groups: {        "*": { tools: { deny: ["exec"] } },        "-1001234567890": {          tools: { deny: ["exec", "read", "write"] },          toolsBySender: {            "id:123456789": { alsoAllow: ["exec"] },          },        },      },    },  },}

Gruppen-Zulassungslisten

Wenn channels.whatsapp.groups, channels.telegram.groups oder channels.imessage.groups konfiguriert ist, dienen die Schlüssel als Gruppen-Zulassungsliste. Verwenden Sie "*", um alle Gruppen zuzulassen und dennoch das standardmäßige Erwähnungsverhalten festzulegen.

Gängige Anwendungsfälle (zum Kopieren und Einfügen):

{  channels: { whatsapp: { groupPolicy: "disabled" } },}

{  channels: {    whatsapp: {      groups: {        "123@g.us": { requireMention: true },        "456@g.us": { requireMention: false },      },    },  },}

{  channels: {    whatsapp: {      groups: { "*": { requireMention: true } },    },  },}

{  channels: {    whatsapp: {      groupPolicy: "allowlist",      groupAllowFrom: ["+15551234567"],      groups: { "*": { requireMention: true } },    },  },}

Aktivierung (nur Eigentümer)

Gruppeneigentümer können die Aktivierung für jede Gruppe mit einer eigenständigen Nachricht umschalten:

• /activation mention
• /activation always

/activation ist ein Kernbefehl, der Eigentümern vorbehalten ist und nur in Gruppenchats gilt. Eigentümer bedeutet, dass der Absender commands.ownerAllowFrom entspricht; allowFrom-Listen des Kanals steuern lediglich den gewöhnlichen Kanal- und Befehlszugriff. Der gespeicherte Modus überschreibt auf Kanälen, die ihn berücksichtigen (Google Chat, QQBot, Telegram, WhatsApp), den Wert requireMention dieser Gruppe, und die Einleitung des Gruppen-System-Prompts gibt überall den aktiven Modus wieder.

Kontextfelder

Eingehende Gruppen-Payloads legen Folgendes fest:

• ChatType=group
• GroupSubject (falls bekannt)
• GroupMembers (falls bekannt)
• WasMentioned (Ergebnis der Erwähnungsprüfung)
• Telegram-Forenthemen enthalten außerdem MessageThreadId und IsForum.

Der Agent-System-Prompt enthält im ersten Durchlauf einer neuen Gruppensitzung (und nach Änderungen an /activation) eine Gruppeneinleitung. Sie erinnert das Modell daran, wie ein Mensch zu antworten, Leerzeilen zu minimieren, die üblichen Chat-Abstände einzuhalten und die wörtliche Eingabe von \n-Sequenzen zu vermeiden. Kanäle, deren deklarierter Tabellenmodus native oder unformatierte Tabellen nicht beibehält, raten außerdem von Markdown-Tabellen ab. Aus Kanälen stammende Gruppennamen und Teilnehmerbezeichnungen werden als eingezäunte, nicht vertrauenswürdige Metadaten dargestellt, nicht als eingebettete Systemanweisungen.

iMessage-Besonderheiten

• Bevorzugen Sie chat_id:<id> für Routing oder Zulassungslisten.
• Chats auflisten: imsg chats --limit 20.
• Gruppenantworten werden immer an dieselbe chat_id zurückgesendet.

WhatsApp-System-Prompts

Die maßgeblichen Regeln für WhatsApp-System-Prompts, einschließlich der Auflösung von Gruppen- und Direkt-Prompts, des Platzhalterverhaltens und der Semantik von Kontoüberschreibungen, finden Sie unter WhatsApp.

WhatsApp-Besonderheiten

WhatsApp-spezifisches Verhalten (Verlaufseinfügung und Details zur Verarbeitung von Erwähnungen) finden Sie unter Gruppennachrichten.

Verwandte Themen

• Broadcast-Gruppen
• Kanal-Routing
• Gruppennachrichten
• Kopplung