Broadcast-Gruppen

Status: Experimentell Version: Hinzugefügt in 2026.1.9

Überblick

Broadcast-Gruppen ermöglichen es mehreren Agenten, dieselbe Nachricht gleichzeitig zu verarbeiten und darauf zu antworten. So kannst du spezialisierte Agent-Teams erstellen, die in einer einzelnen WhatsApp-Gruppe oder DM zusammenarbeiten — alles über eine Telefonnummer.

Aktueller Umfang: Nur WhatsApp (Webkanal).

Broadcast-Gruppen werden nach Kanal-Allowlists und Gruppen-Aktivierungsregeln ausgewertet. In WhatsApp-Gruppen bedeutet das, Broadcasts finden statt, wenn OpenClaw normalerweise antworten würde (zum Beispiel: bei Erwähnung, je nach Gruppeneinstellungen).

Anwendungsfälle

1. Spezialisierte Agent-Teams

Setze mehrere Agenten mit fokussierten Aufgaben ein:

Group: "Development Team"
Agents:
  - CodeReviewer (reviews code snippets)
  - DocumentationBot (generates docs)
  - SecurityAuditor (checks for vulnerabilities)
  - TestGenerator (suggests test cases)

Jeder Agent verarbeitet dieselbe Nachricht und liefert seine spezialisierte Perspektive.

2. Mehrsprachiger Support

Group: "International Support"
Agents:
  - Agent_EN (responds in English)
  - Agent_DE (responds in German)
  - Agent_ES (responds in Spanish)

3. Qualitätssicherungs-Workflows

Group: "Customer Support"
Agents:
  - SupportAgent (provides answer)
  - QAAgent (reviews quality, only responds if issues found)

4. Aufgabenautomatisierung

Group: "Project Management"
Agents:
  - TaskTracker (updates task database)
  - TimeLogger (logs time spent)
  - ReportGenerator (creates summaries)

Konfiguration

Grundeinrichtung

Füge einen Top-Level-broadcast-Abschnitt hinzu (neben bindings). Schlüssel sind WhatsApp-Peer-IDs:

Gruppenchats: Gruppen-JID (z. B. [email protected])
DMs: E.164-Telefonnummer (z. B. +15551234567)

{
  "broadcast": {
    "[email protected]": ["alfred", "baerbel", "assistant3"]
  }
}

Ergebnis: Wenn OpenClaw in diesem Chat antworten würde, werden alle drei Agenten ausgeführt.

Verarbeitungsstrategie

Steuere, wie Agenten Nachrichten verarbeiten:

Parallel (Standard)

Alle Agenten verarbeiten gleichzeitig:

{
  "broadcast": {
    "strategy": "parallel",
    "[email protected]": ["alfred", "baerbel"]
  }
}

Sequenziell

Agenten verarbeiten der Reihe nach (einer wartet, bis der vorherige fertig ist):

{
  "broadcast": {
    "strategy": "sequential",
    "[email protected]": ["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",
    "[email protected]": ["code-reviewer", "security-auditor", "docs-generator"],
    "[email protected]": ["support-en", "support-de"],
    "+15555550123": ["assistant", "logger"]
  }
}

Funktionsweise

Nachrichtenfluss

Eingehende Nachricht kommt in einer WhatsApp-Gruppe an
Broadcast-Prüfung: System prüft, ob die Peer-ID in broadcast enthalten ist
Wenn in der Broadcast-Liste:
- Alle gelisteten Agenten verarbeiten die Nachricht
- Jeder Agent hat seinen eigenen Session-Schlüssel und isolierten Kontext
- Agenten verarbeiten parallel (Standard) oder sequenziell
Wenn nicht in der Broadcast-Liste:
- Normales Routing greift (erstes passendes Binding)

Hinweis: Broadcast-Gruppen umgehen keine Kanal-Allowlists oder Gruppen-Aktivierungsregeln (Mentions/Befehle/usw.). Sie ändern nur, welche Agenten ausgeführt werden, wenn eine Nachricht zur Verarbeitung berechtigt ist.

Session-Isolation

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

Session-Schlüssel (agent:alfred:whatsapp:group:120363... vs. agent:baerbel:whatsapp:group:120363...)
Gesprächsverlauf (Agent sieht nicht die Nachrichten anderer Agenten)
Workspace (separate Sandboxes falls konfiguriert)
Tool-Zugriff (verschiedene Allow/Deny-Listen)
Speicher/Kontext (separate IDENTITY.md, SOUL.md usw.)
Gruppenkontext-Puffer (aktuelle Gruppennachrichten für Kontext) wird pro Peer geteilt, sodass alle Broadcast-Agenten denselben Kontext sehen, wenn sie ausgelöst werden

Das ermöglicht jedem Agent:

Verschiedene Persönlichkeiten
Unterschiedlichen Tool-Zugriff (z. B. Nur-Lesen vs. Lesen-Schreiben)
Verschiedene Modelle (z. B. Opus vs. Sonnet)
Verschiedene installierte Skills

Beispiel: Isolierte Sessions

In Gruppe [email protected] mit Agenten ["alfred", "baerbel"]:

Alfreds Kontext:

Session: agent:alfred:whatsapp:group:[email protected]
History: [user message, alfred's previous responses]
Workspace: /Users/pascal/openclaw-alfred/
Tools: read, write, exec

Bärbels Kontext:

Session: agent:baerbel:whatsapp:group:[email protected]
History: [user message, baerbel's previous responses]
Workspace: /Users/pascal/openclaw-baerbel/
Tools: read only

Empfohlene Vorgehensweisen

1. Agenten fokussiert halten

Entwirf jeden Agent mit einer einzigen, klaren Aufgabe:

{
  "broadcast": {
    "DEV_GROUP": ["formatter", "linter", "tester"]
  }
}

Gut: Jeder Agent hat eine Aufgabe Schlecht: Ein generischer „Dev-Helfer”-Agent

2. Aussagekräftige Namen verwenden

Mache deutlich, was jeder Agent tut:

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

3. Unterschiedlichen Tool-Zugriff konfigurieren

Gib Agenten nur die Tools, die sie brauchen:

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

4. Leistung überwachen

Bei vielen Agenten beachte:

Verwende "strategy": "parallel" (Standard) für Geschwindigkeit
Begrenze Broadcast-Gruppen auf 5-10 Agenten
Verwende schnellere Modelle für einfachere Agenten

5. Fehler robust behandeln

Agenten scheitern unabhängig voneinander. Der Fehler eines Agenten blockiert die anderen nicht:

Message → [Agent A ✓, Agent B ✗ error, Agent C ✓]
Result: Agent A and C respond, Agent B logs error

Kompatibilität

Provider

Broadcast-Gruppen funktionieren derzeit mit:

WhatsApp (implementiert)
Telegram (geplant)
Discord (geplant)
Slack (geplant)

Routing

Broadcast-Gruppen funktionieren neben bestehendem 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)

Vorrang: broadcast hat Vorrang vor bindings.

Fehlerbehebung

Agenten antworten nicht

Prüfe:

Agent-IDs existieren in agents.list
Peer-ID-Format ist korrekt (z. B. [email protected])
Agenten sind nicht in Deny-Listen

Debuggen:

tail -f ~/.openclaw/logs/gateway.log | grep broadcast

Nur ein Agent antwortet

Ursache: Peer-ID ist möglicherweise in bindings, aber nicht in broadcast.

Lösung: Zur Broadcast-Konfiguration hinzufügen oder aus Bindings entfernen.

Leistungsprobleme

Bei Langsamkeit mit vielen Agenten:

Anzahl der Agenten pro Gruppe reduzieren
Leichtere Modelle verwenden (Sonnet statt Opus)
Sandbox-Startzeit prüfen

Beispiele

Beispiel 1: Code-Review-Team

{
  "broadcast": {
    "strategy": "parallel",
    "[email protected]": [
      "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"] } }
    ]
  }
}

Benutzer sendet: Code-Snippet Antworten:

code-formatter: “Fixed indentation and added type hints”
security-scanner: “SQL injection vulnerability in line 12”
test-coverage: “Coverage is 45%, missing tests for error cases”
docs-checker: “Missing docstring for function process_data”

Beispiel 2: Mehrsprachiger Support

{
  "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

strategy (optional): Verarbeitungsart der Agenten
- "parallel" (Standard): Alle Agenten verarbeiten gleichzeitig
- "sequential": Agenten verarbeiten in Array-Reihenfolge
[peerId]: WhatsApp-Gruppen-JID, E.164-Nummer oder andere Peer-ID
- Wert: Array von Agent-IDs, die Nachrichten verarbeiten sollen

Einschränkungen

Max. Agenten: Kein festes Limit, aber 10+ Agenten können langsam sein
Geteilter Kontext: Agenten sehen nicht die Antworten der anderen (beabsichtigt)
Nachrichtenreihenfolge: Parallele Antworten können in beliebiger Reihenfolge eintreffen
Rate-Limits: Alle Agenten zählen für WhatsApp-Rate-Limits

Geplante Erweiterungen

Geplante Funktionen:

Geteilter Kontextmodus (Agenten sehen gegenseitig ihre Antworten)
Agent-Koordination (Agenten können sich gegenseitig Signale senden)
Dynamische Agent-Auswahl (Agenten basierend auf Nachrichteninhalt wählen)
Agent-Prioritäten (manche Agenten antworten vor anderen)