Групи трансляції
Статус: ЕкспериментальноВерсія: Додано у 2026.1.9
Огляд
Групи трансляції дають змогу кільком агентам одночасно обробляти те саме повідомлення й відповідати на нього. Це дає змогу створювати спеціалізовані команди агентів, які працюють разом в одній групі або DM WhatsApp — і все це з використанням одного номера телефону. Поточна сфера дії: лише WhatsApp (вебканал). Групи трансляції оцінюються після списків дозволу каналу та правил активації групи. У групах WhatsApp це означає, що трансляції відбуваються тоді, коли OpenClaw зазвичай відповів би (наприклад, на згадування, залежно від ваших налаштувань групи).Варіанти використання
1. Спеціалізовані команди агентів
Розгорніть кількох агентів з атомарними, вузькоспрямованими обов’язками:2. Підтримка кількох мов
3. Робочі процеси забезпечення якості
4. Автоматизація завдань
Конфігурація
Базове налаштування
Додайте верхньорівневий розділbroadcast (поруч із bindings). Ключами є peer ID WhatsApp:
- групові чати: JID групи (наприклад,
120363403215116621@g.us) - DM: номер телефону у форматі E.164 (наприклад,
+15551234567)
Стратегія обробки
Керуйте тим, як агенти обробляють повідомлення:Паралельно (типово)
Усі агенти обробляють одночасно:Послідовно
Агенти обробляють по черзі (кожен чекає, поки завершиться попередній):Повний приклад
Як це працює
Потік повідомлень
- Вхідне повідомлення надходить у групу WhatsApp
- Перевірка трансляції: система перевіряє, чи є peer ID у
broadcast - Якщо є у списку трансляції:
- Усі перелічені агенти обробляють повідомлення
- Кожен агент має власний ключ сесії та ізольований контекст
- Агенти обробляють паралельно (типово) або послідовно
- Якщо немає у списку трансляції:
- Застосовується звичайна маршрутизація (перше binding, що збіглося)
Ізоляція сесій
Кожен агент у групі трансляції підтримує повністю окремі:- Ключі сесій (
agent:alfred:whatsapp:group:120363...протиagent:baerbel:whatsapp:group:120363...) - Історію розмови (агент не бачить повідомлень інших агентів)
- Робочий простір (окремі ізольовані середовища, якщо налаштовано)
- Доступ до інструментів (різні списки allow/deny)
- Пам’ять/контекст (окремі IDENTITY.md, SOUL.md тощо)
- Буфер контексту групи (останні групові повідомлення, що використовуються для контексту) є спільним для кожного peer, тож усі агенти трансляції бачать однаковий контекст під час запуску
- Різні особистості
- Різний доступ до інструментів (наприклад, лише читання чи читання-запис)
- Різні моделі (наприклад, opus або sonnet)
- Різні встановлені Skills
Приклад: ізольовані сесії
У групі120363403215116621@g.us з агентами ["alfred", "baerbel"]:
Контекст Alfred:
Рекомендовані практики
1. Зберігайте вузьку спеціалізацію агентів
Проєктуйте кожного агента з одним чітким обов’язком:❌ Погано: Один універсальний агент “dev-helper”
2. Використовуйте зрозумілі назви
Назва має чітко вказувати, що робить кожен агент:3. Налаштовуйте різний доступ до інструментів
Надавайте агентам лише ті інструменти, які їм потрібні:4. Відстежуйте продуктивність
За великої кількості агентів враховуйте таке:- Використовуйте
"strategy": "parallel"(типово) для швидкості - Обмежуйте групи трансляції до 5–10 агентів
- Використовуйте швидші моделі для простіших агентів
5. Коректно обробляйте збої
Агенти збоять незалежно один від одного. Помилка одного агента не блокує інших:Сумісність
Провайдери
Групи трансляції наразі працюють із:- ✅ WhatsApp (реалізовано)
- 🚧 Telegram (заплановано)
- 🚧 Discord (заплановано)
- 🚧 Slack (заплановано)
Маршрутизація
Групи трансляції працюють разом з наявною маршрутизацією:GROUP_A: відповідає лише alfred (звичайна маршрутизація)GROUP_B: відповідають agent1 І agent2 (трансляція)
broadcast має вищий пріоритет за bindings.
Усунення несправностей
Агенти не відповідають
Перевірте:- Ідентифікатори агентів існують у
agents.list - Формат peer ID правильний (наприклад,
120363403215116621@g.us) - Агенти не перебувають у списках deny
Відповідає лише один агент
Причина: peer ID може бути вbindings, але не в broadcast.
Виправлення: Додайте його до конфігурації трансляції або видаліть із bindings.
Проблеми з продуктивністю
Якщо повільно за великої кількості агентів:- Зменште кількість агентів на групу
- Використовуйте легші моделі (sonnet замість opus)
- Перевірте час запуску ізольованого середовища
Приклади
Приклад 1: Команда перевірки коду
Відповіді:
- code-formatter: “Виправлено відступи та додано підказки типів”
- security-scanner: “⚠️ Уразливість SQL-ін’єкції в рядку 12”
- test-coverage: “Покриття становить 45%, бракує тестів для випадків помилок”
- docs-checker: “Бракує docstring для функції
process_data”
Приклад 2: Підтримка кількох мов
Довідник API
Схема конфігурації
Поля
strategy(необов’язково): як обробляти агентів"parallel"(типово): усі агенти обробляють одночасно"sequential": агенти обробляють у порядку масиву
[peerId]: JID групи WhatsApp, номер E.164 або інший peer ID- Значення: масив ідентифікаторів агентів, які мають обробляти повідомлення
Обмеження
- Максимальна кількість агентів: жорсткого обмеження немає, але 10+ агентів можуть працювати повільно
- Спільний контекст: агенти не бачать відповіді один одного (за задумом)
- Порядок повідомлень: паралельні відповіді можуть надходити в будь-якому порядку
- Обмеження швидкості: усі агенти враховуються в обмеженнях швидкості WhatsApp
Майбутні покращення
Заплановані можливості:- Режим спільного контексту (агенти бачать відповіді один одного)
- Координація агентів (агенти можуть подавати сигнали один одному)
- Динамічний вибір агентів (вибір агентів на основі вмісту повідомлення)
- Пріоритети агентів (деякі агенти відповідають раніше за інших)