Skip to main content
Status: Experimentell. Hinzugefügt in 2026.1.9. Nur WhatsApp (Webkanal).

Ü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)
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:

Vollständiges Beispiel

Funktionsweise

Nachrichtenfluss

1

Eingehende Nachricht trifft ein

Eine WhatsApp-Gruppen- oder DM-Nachricht trifft ein.
2

Routing und Zulassung

OpenClaw wendet Kanal-Zulassungslisten, Gruppenaktivierungsregeln und die Eigentümerschaft konfigurierter ACP-Bindungen an.
3

Broadcast-Prüfung

Wenn keine konfigurierte ACP-Bindung für die Route zuständig ist, prüft OpenClaw, ob die Peer-ID in broadcast enthalten ist.
4

Wenn Broadcast angewendet wird

  • Alle aufgeführten Agenten verarbeiten die Nachricht.
  • Jeder Agent hat seinen eigenen Sitzungsschlüssel und isolierten Kontext.
  • Agenten verarbeiten parallel (Standard) oder sequenziell.
  • Audioanhänge werden vor der Verteilung einmal transkribiert, sodass die Agenten ein gemeinsames Transkript verwenden, anstatt separate STT-Aufrufe auszuführen.
5

Wenn Broadcast nicht angewendet wird

OpenClaw leitet an die gewöhnliche Route oder an die während des Routings ausgewählte konfigurierte ACP-Sitzungsroute weiter.
Broadcast-Gruppen umgehen weder Kanal-Zulassungslisten noch Gruppenaktivierungsregeln (Erwähnungen/Befehle/usw.). Sie ändern nur, welche Agenten ausgeführt werden, wenn eine Nachricht verarbeitet werden darf.

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

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

Weisen Sie jedem Agenten eine einzige, klar definierte Verantwortung zu (formatter, linter, tester), statt einen allgemeinen „dev-helper“-Agenten zu verwenden.
reviewer ist schreibgeschützt. fixer kann lesen und schreiben.
Bevorzugen Sie bei vielen Agenten "strategy": "parallel" (Standard), beschränken Sie Broadcast-Gruppen auf wenige Agenten und verwenden Sie schnellere Modelle für einfachere Agenten.
Agenten schlagen unabhängig voneinander fehl. Der Fehler eines Agenten wird protokolliert (Broadcast agent <id> failed: ...) und blockiert die anderen nicht.

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:
  • GROUP_A: Nur Alfred antwortet (normales Routing).
  • GROUP_B: Agent1 UND Agent2 antworten (Broadcast).
Priorität: broadcast hat Vorrang vor gewöhnlichen Routenbindungen. Konfigurierte ACP-Bindungen (bindings[].type="acp") sind exklusiv: Wenn eine davon übereinstimmt, leitet OpenClaw an die konfigurierte ACP-Sitzung weiter, anstatt einen Broadcast an mehrere Agenten zu verteilen.

Fehlerbehebung

Prüfen Sie Folgendes:
  1. Agenten-IDs sind in agents.entries vorhanden (die Konfigurationsvalidierung lehnt unbekannte IDs ab).
  2. Das Peer-ID-Format ist korrekt (Gruppen-JID wie 120363403215116621@g.us oder E.164 wie +15551234567 für DMs).
  3. Die Nachricht hat die normale Zugangsprüfung bestanden (Erwähnungs-/Aktivierungsregeln gelten weiterhin).
Debugging:
Eine erfolgreiche Verteilung protokolliert Broadcasting message to <n> agents (<strategy>).
Ursache: Die Peer-ID ist möglicherweise in gewöhnlichen Routenbindungen, aber nicht in broadcast enthalten, oder sie stimmt möglicherweise mit einer exklusiven konfigurierten ACP-Bindung überein.Behebung: Fügen Sie an gewöhnliche Routen gebundene Peers zur Broadcast-Konfiguration hinzu oder entfernen/ändern Sie die konfigurierte ACP-Bindung, wenn die Broadcast-Verteilung gewünscht ist.
Wenn die Verarbeitung bei vielen Agenten langsam ist: Reduzieren Sie die Anzahl der Agenten pro Gruppe, verwenden Sie weniger ressourcenintensive Modelle und prüfen Sie die Startzeit der Sandbox.

Beispiele

Ein Codeausschnitt in der Gruppe erzeugt vier Antworten: Formatierungskorrekturen, einen Sicherheitsbefund, eine Abdeckungslücke und einen kleinen Dokumentationshinweis.

API-Referenz

Konfigurationsschema

Felder

"parallel" | "sequential"
Standard:"\"parallel\""
Legt fest, wie Agenten verarbeitet werden. parallel führt alle Agenten gleichzeitig aus; sequential führt sie in Array-Reihenfolge aus.
string[]
WhatsApp-Gruppen-JID oder Telefonnummer im E.164-Format. Der Wert ist das Array der Agenten-IDs, die alle Nachrichten dieses Peers verarbeiten sollen.

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