Grupy rozgłoszeniowe
Status: EksperymentalneWersja: Dodano w 2026.1.9
Omówienie
Grupy rozgłoszeniowe umożliwiają wielu agentom jednoczesne przetwarzanie i odpowiadanie na tę samą wiadomość. Pozwala to tworzyć wyspecjalizowane zespoły agentów, które współpracują w jednej grupie WhatsApp lub rozmowie DM — wszystko przy użyciu jednego numeru telefonu. Obecny zakres: tylko WhatsApp (kanał web). Grupy rozgłoszeniowe są oceniane po listach dozwolonych kanałów i regułach aktywacji grup. W grupach WhatsApp oznacza to, że rozgłaszanie następuje wtedy, gdy OpenClaw normalnie by odpowiedział (na przykład po wzmiance, zależnie od ustawień grupy).Przypadki użycia
1. Wyspecjalizowane zespoły agentów
Wdróż wielu agentów o atomowych, wyspecjalizowanych odpowiedzialnościach:2. Obsługa wielu języków
3. Przepływy pracy zapewnienia jakości
4. Automatyzacja zadań
Konfiguracja
Podstawowa konfiguracja
Dodaj sekcjębroadcast na najwyższym poziomie (obok bindings). Klucze to identyfikatory peerów WhatsApp:
- czaty grupowe: grupowy JID (np.
120363403215116621@g.us) - rozmowy DM: numer telefonu w formacie E.164 (np.
+15551234567)
Strategia przetwarzania
Kontroluj sposób przetwarzania wiadomości przez agentów:Równolegle (domyślnie)
Wszyscy agenci przetwarzają jednocześnie:Sekwencyjnie
Agenci przetwarzają po kolei (jeden czeka, aż poprzedni zakończy pracę):Pełny przykład
Jak to działa
Przepływ wiadomości
- Wiadomość przychodząca trafia do grupy WhatsApp
- Sprawdzenie rozgłaszania: system sprawdza, czy identyfikator peera znajduje się w
broadcast - Jeśli znajduje się na liście rozgłaszania:
- Wszyscy wymienieni agenci przetwarzają wiadomość
- Każdy agent ma własny klucz sesji i odizolowany kontekst
- Agenci przetwarzają równolegle (domyślnie) lub sekwencyjnie
- Jeśli nie znajduje się na liście rozgłaszania:
- Zastosowanie ma normalne routowanie (pierwsze pasujące powiązanie)
Izolacja sesji
Każdy agent w grupie rozgłoszeniowej utrzymuje całkowicie oddzielne:- Klucze sesji (
agent:alfred:whatsapp:group:120363...vsagent:baerbel:whatsapp:group:120363...) - Historię rozmowy (agent nie widzi wiadomości innych agentów)
- Workspace (oddzielne sandboxy, jeśli są skonfigurowane)
- Dostęp do narzędzi (różne listy dozwolonych/zabronionych narzędzi)
- Pamięć/kontekst (oddzielne
IDENTITY.md,SOUL.mditd.) - Bufor kontekstu grupy (ostatnie wiadomości grupowe używane jako kontekst) jest współdzielony dla danego peera, więc wszyscy agenci rozgłoszeniowi widzą ten sam kontekst przy uruchomieniu
- Różne osobowości
- Różny dostęp do narzędzi (np. tylko do odczytu vs. odczyt i zapis)
- Różne modele (np. opus vs. sonnet)
- Różne zainstalowane Skills
Przykład: izolowane sesje
W grupie120363403215116621@g.us z agentami ["alfred", "baerbel"]:
Kontekst Alfreda:
Dobre praktyki
1. Utrzymuj skupienie agentów
Projektuj każdego agenta z jedną, jasno określoną odpowiedzialnością:❌ Źle: Jeden ogólny agent „dev-helper”
2. Używaj opisowych nazw
Nazwy powinny jasno wskazywać, co robi każdy agent:3. Skonfiguruj różny dostęp do narzędzi
Dawaj agentom tylko te narzędzia, których potrzebują:4. Monitoruj wydajność
Przy dużej liczbie agentów rozważ:- Użycie
"strategy": "parallel"(domyślnie) dla szybkości - Ograniczenie grup rozgłoszeniowych do 5–10 agentów
- Używanie szybszych modeli dla prostszych agentów
5. Obsługuj błędy z zachowaniem odporności
Agenci zawodzą niezależnie od siebie. Błąd jednego agenta nie blokuje pozostałych:Zgodność
Dostawcy
Grupy rozgłoszeniowe obecnie działają z:- ✅ WhatsApp (zaimplementowane)
- 🚧 Telegram (planowane)
- 🚧 Discord (planowane)
- 🚧 Slack (planowane)
Routowanie
Grupy rozgłoszeniowe działają równolegle z istniejącym routowaniem:GROUP_A: odpowiada tylko alfred (normalne routowanie)GROUP_B: odpowiadają agent1 ORAZ agent2 (rozgłaszanie)
broadcast ma pierwszeństwo przed bindings.
Rozwiązywanie problemów
Agenci nie odpowiadają
Sprawdź:- Identyfikatory agentów istnieją w
agents.list - Format identyfikatora peera jest poprawny (np.
120363403215116621@g.us) - Agenci nie znajdują się na listach zabronionych
Odpowiada tylko jeden agent
Przyczyna: Identyfikator peera może znajdować się wbindings, ale nie w broadcast.
Rozwiązanie: Dodaj go do konfiguracji broadcast albo usuń z bindings.
Problemy z wydajnością
Jeśli jest wolno przy wielu agentach:- Zmniejsz liczbę agentów w grupie
- Używaj lżejszych modeli (sonnet zamiast opus)
- Sprawdź czas uruchamiania sandboxa
Przykłady
Przykład 1: Zespół do przeglądu kodu
Odpowiedzi:
- code-formatter: „Naprawiono wcięcia i dodano podpowiedzi typów”
- security-scanner: „⚠️ Podatność SQL injection w linii 12”
- test-coverage: „Pokrycie wynosi 45%, brakuje testów dla przypadków błędów”
- docs-checker: „Brakuje docstringa dla funkcji
process_data”
Przykład 2: Obsługa wielu języków
Dokumentacja API
Schemat konfiguracji
Pola
strategy(opcjonalne): sposób przetwarzania agentów"parallel"(domyślnie): wszyscy agenci przetwarzają jednocześnie"sequential": agenci przetwarzają w kolejności z tablicy
[peerId]: grupowy JID WhatsApp, numer E.164 lub inny identyfikator peera- Wartość: tablica identyfikatorów agentów, które powinny przetwarzać wiadomości
Ograniczenia
- Maksymalna liczba agentów: brak sztywnego limitu, ale 10+ agentów może działać wolno
- Współdzielony kontekst: agenci nie widzą odpowiedzi innych agentów (celowo)
- Kolejność wiadomości: odpowiedzi równoległe mogą pojawić się w dowolnej kolejności
- Limity szybkości: wszyscy agenci liczą się do limitów szybkości WhatsApp
Przyszłe ulepszenia
Planowane funkcje:- Tryb współdzielonego kontekstu (agenci widzą odpowiedzi innych agentów)
- Koordynacja agentów (agenci mogą sygnalizować sobie nawzajem)
- Dynamiczny wybór agentów (wybór agentów na podstawie treści wiadomości)
- Priorytety agentów (niektórzy agenci odpowiadają przed innymi)