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 einzelnen Gruppenchat oder einer Direktnachricht beherbergen kann.

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

Die aktive WhatsApp-QA-Teststrecke enthält whatsapp-broadcast-group-fanout. Sie überprüft, ob eine einzelne Gruppennachricht mit Erwähnung unterschiedliche sichtbare Antworten von zwei konfigurierten Agenten erzeugen kann.

Konfiguration

Grundlegende Einrichtung

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)
• Direktnachrichten: 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.list vorhanden sein: Die Konfigurationsvalidierung meldet unbekannte IDs, und die Laufzeit überspringt sie mit der Warnung Broadcast agent <id> not found in agents.list; skipping.

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...)
• Unterhaltungsverläufe (ein Agent sieht die Antworten anderer Agenten nicht)
• Arbeitsbereiche (separate Sandboxen, falls konfiguriert)
• Werkzeugzugriffe (unterschiedliche Zulassungs-/Sperrlisten)
• Speicher/Kontexte (separate IDENTITY.md, SOUL.md usw.)

Eine Ausnahme wird absichtlich gemeinsam verwendet: Der Gruppenkontextpuffer (die letzten Gruppennachrichten, die als Kontext verwendet werden) wird pro Peer gemeinsam genutzt, sodass alle Broadcast-Agenten bei ihrer Auslösung denselben Kontext sehen. Er wird einmal geleert, nachdem die Verteilung abgeschlossen ist.

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"]:

Session: agent:alfred:whatsapp:group:120363403215116621@g.usHistory: [user message, alfred's previous responses]Workspace: ~/openclaw-alfred/Tools: read, write, exec

Session: agent:baerbel:whatsapp:group:120363403215116621@g.usHistory: [user message, baerbel's previous responses]Workspace: ~/openclaw-baerbel/Tools: read only

Anwendungsfälle

• Teams spezialisierter Agenten: Eine Entwicklungsgruppe, in der code-reviewer, security-auditor, test-generator und docs-checker jeweils dieselbe Nachricht 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 überprü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: Es gibt keine feste Grenze, aber viele Agenten (10 oder mehr) 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, daher zählt die Antwort jedes Agenten für dieselben WhatsApp-Ratenbegrenzungen.

Verwandte Themen

• Kanalrouting
• Gruppen
• Sandbox-Tools für mehrere Agenten
• Kopplung
• Sitzungsverwaltung