Broadcast-Gruppen

Überblick

Broadcast-Gruppen führen mehrere Agenten für dieselbe eingehende Nachricht aus. Jeder Agent verarbeitet die Nachricht in seiner eigenen isolierten Sitzung und veröffentlicht seine eigene Antwort, sodass eine WhatsApp-Nummer ein Team spezialisierter Agenten in einem einzigen Gruppenchat oder einer DM bereitstellen kann.

Broadcast-Gruppen werden nach Kanal-Zulassungslisten und Gruppenaktivierungsregeln ausgewertet. In WhatsApp-Gruppen erfolgen Broadcasts, wenn OpenClaw normalerweise antworten würde (beispielsweise bei einer Erwähnung, abhängig von Ihren Gruppeneinstellungen). Sie ändern nur, welche Agenten ausgeführt werden, niemals, ob eine Nachricht verarbeitet werden darf.

Die aktive WhatsApp-QA-Lane umfasst whatsapp-broadcast-group-fanout, wodurch überprüft wird, dass eine erwähnte Gruppennachricht unterschiedliche sichtbare Antworten von zwei konfigurierten Agenten erzeugen kann.

Konfiguration

Grundeinrichtung

Fügen Sie einen broadcast-Abschnitt auf oberster Ebene hinzu (neben bindings). Die Schlüssel sind WhatsApp-Peer-IDs, die Werte sind Arrays von Agenten-IDs:

• Gruppenchats: Gruppen-JID (z. B. 120363403215116621@g.us)
• DMs: Telefonnummer des Absenders im E.164-Format (z. B. +15551234567)

{  "broadcast": {    "120363403215116621@g.us": ["alfred", "baerbel", "assistant3"]  }}

Ergebnis: Wenn OpenClaw in diesem Chat antworten würde, führt es alle drei Agenten aus.

Jede aufgeführte Agenten-ID muss in agents.entries vorhanden sein: Die Konfigurationsvalidierung meldet unbekannte IDs, und die Laufzeit überspringt sie mit einer Broadcast agent <id> not found in agents.entries; skipping-Warnung.

Verarbeitungsstrategie

broadcast.strategy legt fest, wie Agenten die Nachricht verarbeiten:

{  "broadcast": {    "strategy": "sequential",    "120363403215116621@g.us": ["alfred", "baerbel"]  }}

Vollständiges Beispiel

{  "agents": {    "list": [      {        "id": "code-reviewer",        "name": "Code Reviewer",        "workspace": "/path/to/code-reviewer",        "sandbox": { "mode": "all" }      },      {        "id": "security-auditor",        "name": "Security Auditor",        "workspace": "/path/to/security-auditor",        "sandbox": { "mode": "all" }      },      {        "id": "docs-generator",        "name": "Documentation Generator",        "workspace": "/path/to/docs-generator",        "sandbox": { "mode": "all" }      }    ]  },  "broadcast": {    "strategy": "parallel",    "120363403215116621@g.us": ["code-reviewer", "security-auditor", "docs-generator"],    "120363424282127706@g.us": ["support-en", "support-de"],    "+15555550123": ["assistant", "logger"]  }}

Funktionsweise

Nachrichtenfluss

Sitzungsisolierung

Jeder Agent in einer Broadcast-Gruppe verwaltet vollständig getrennte:

• Sitzungsschlüssel (agent:alfred:whatsapp:group:120363... gegenüber agent:baerbel:whatsapp:group:120363...)
• Konversationsverläufe (ein Agent sieht die Antworten anderer Agenten nicht)
• Arbeitsbereiche (separate Sandboxes, sofern konfiguriert)
• Werkzeugzugriffe (unterschiedliche Zulassungs-/Sperrlisten)
• Arbeitsspeicher/Kontexte (separate IDENTITY.md, SOUL.md usw.)

Eine Ausnahme wird bewusst gemeinsam genutzt: Der Gruppenkontextpuffer (kürzlich gesendete Gruppennachrichten, die als Kontext verwendet werden) wird pro Peer gemeinsam genutzt, sodass alle Broadcast-Agenten beim Auslösen denselben Kontext sehen. Er wird nach Abschluss der Verteilung einmal geleert.

Dadurch kann jeder Agent unterschiedliche Persönlichkeiten, Modelle, Skills und Werkzeugzugriffe haben (beispielsweise schreibgeschützt gegenüber Lese- und Schreibzugriff).

Beispiel: isolierte Sitzungen

In der Gruppe 120363403215116621@g.us mit den Agenten ["alfred", "baerbel"]:

Sitzung: agent:alfred:whatsapp:group:120363403215116621@g.usVerlauf: [Benutzernachricht, vorherige Antworten von Alfred]Arbeitsbereich: ~/openclaw-alfred/Werkzeuge: Lesen, Schreiben, Ausführen

Sitzung: agent:baerbel:whatsapp:group:120363403215116621@g.usVerlauf: [Benutzernachricht, vorherige Antworten von Baerbel]Arbeitsbereich: ~/openclaw-baerbel/Werkzeuge: nur Lesen

Anwendungsfälle

• Spezialisierte Agententeams: eine Entwicklungsgruppe, in der code-reviewer, security-auditor, test-generator und docs-checker dieselbe Nachricht jeweils aus ihrer eigenen Perspektive beantworten.
• Mehrsprachiger Support: ein Support-Chat, in dem support-en, support-de und support-es in ihren jeweiligen Sprachen antworten.
• Qualitätssicherung: support-agent antwortet, während qa-agent die Antwort prüft und nur reagiert, wenn Probleme gefunden werden.
• Aufgabenautomatisierung: task-tracker, time-logger und report-generator verarbeiten alle dieselbe Statusaktualisierung.

Bewährte Vorgehensweisen

{  "agents": {    "list": [      { "id": "security-scanner", "name": "Security Scanner" },      { "id": "code-formatter", "name": "Code Formatter" },      { "id": "test-generator", "name": "Test Generator" }    ]  }}

{  "agents": {    "list": [      { "id": "reviewer", "tools": { "allow": ["read", "exec"] } },      { "id": "fixer", "tools": { "allow": ["read", "write", "edit", "exec"] } }    ]  }}

Kompatibilität

Provider

Broadcast-Gruppen sind derzeit nur für WhatsApp (Webkanal) implementiert. Andere Kanäle ignorieren die broadcast-Konfiguration.

Routing

Broadcast-Gruppen funktionieren zusammen mit dem bestehenden Routing:

{  "bindings": [    {      "match": { "channel": "whatsapp", "peer": { "kind": "group", "id": "GROUP_A" } },      "agentId": "alfred"    }  ],  "broadcast": {    "GROUP_B": ["agent1", "agent2"]  }}

• GROUP_A: Nur Alfred antwortet (normales Routing).
• GROUP_B: Agent1 UND Agent2 antworten (Broadcast).

Fehlerbehebung

openclaw logs --follow | grep -i broadcast

Beispiele

{  "broadcast": {    "strategy": "parallel",    "120363403215116621@g.us": [      "code-formatter",      "security-scanner",      "test-coverage",      "docs-checker"    ]  },  "agents": {    "list": [      {        "id": "code-formatter",        "workspace": "~/agents/formatter",        "tools": { "allow": ["read", "write"] }      },      {        "id": "security-scanner",        "workspace": "~/agents/security",        "tools": { "allow": ["read", "exec"] }      },      {        "id": "test-coverage",        "workspace": "~/agents/testing",        "tools": { "allow": ["read", "exec"] }      },      { "id": "docs-checker", "workspace": "~/agents/docs", "tools": { "allow": ["read"] } }    ]  }}

{  "broadcast": {    "strategy": "sequential",    "+15555550123": ["detect-language", "translator-en", "translator-de"]  },  "agents": {    "list": [      { "id": "detect-language", "workspace": "~/agents/lang-detect" },      { "id": "translator-en", "workspace": "~/agents/translate-en" },      { "id": "translator-de", "workspace": "~/agents/translate-de" }    ]  }}

API-Referenz

Konfigurationsschema

interface OpenClawConfig {  broadcast?: {    strategy?: "parallel" | "sequential";    [peerId: string]: string[];  };}

Felder

Einschränkungen

1. Maximale Anzahl von Agenten: keine feste Begrenzung, aber viele Agenten (10+) können langsam sein.
2. Gemeinsamer Kontext: Agenten sehen die Antworten der jeweils anderen nicht (beabsichtigtes Verhalten).
3. Nachrichtenreihenfolge: Parallele Antworten können in beliebiger Reihenfolge eintreffen.
4. Ratenbegrenzungen: Alle Antworten stammen von einem WhatsApp-Konto, sodass die Antwort jedes Agenten auf dieselben WhatsApp-Ratenbegrenzungen angerechnet wird.

Verwandte Themen

• Kanal-Routing
• Gruppen
• Multi-Agent-Sandbox-Tools
• Kopplung
• Sitzungsverwaltung