Групи

OpenClaw застосовує однакові правила груп у всіх каналах із підтримкою груп, зокрема Discord, iMessage, Matrix, Microsoft Teams, QQBot, Signal, Slack, Telegram, WhatsApp і Zalo.

Для постійно активних кімнат, які мають надавати фоновий контекст без зайвих повідомлень, якщо агент явно не надсилає видиме повідомлення, див. Фонові події кімнати.

Вступ для початківців (2 хвилини)

OpenClaw «живе» у ваших власних облікових записах служб обміну повідомленнями. Окремого користувача-бота WhatsApp немає: якщо ви перебуваєте в групі, OpenClaw може бачити цю групу й відповідати в ній.

Типова поведінка:

• Групи обмежені (groupPolicy: "allowlist"); відправників у групах заблоковано, доки їх не додано до списку дозволених.
• Для відповідей потрібна згадка, якщо для групи не вимкнено обмеження за згадкою.
• Остаточний текст відповіді автоматично публікується в кімнаті (visibleReplies: "automatic").

Інакше кажучи: відправники зі списку дозволених можуть активувати OpenClaw, згадавши його.

Коротка схема (що відбувається з повідомленням у групі):

groupPolicy? disabled -> відкинутиgroupPolicy? allowlist -> групу дозволено? ні -> відкинутиrequireMention? так -> згадано? ні -> зберегти лише для контекстузгадка/відповідь/команда/особисте повідомлення -> запит користувачаповідомлення в постійно активній групі -> запит користувача або подія кімнати, якщо це налаштовано

Видимі відповіді

Для звичайних запитів у групах і каналах OpenClaw типово використовує messages.groupChat.visibleReplies: "automatic": остаточний текст асистента публікується в кімнаті як видима відповідь.

Використовуйте messages.groupChat.visibleReplies: "message_tool", якщо в спільній кімнаті агент має сам вирішувати, коли говорити, викликаючи message(action=send). Це найкраще працює з моделями, які надійно використовують інструменти (наприклад, GPT-5.6 Sol). Якщо модель не викликає інструмент і повертає змістовний остаточний текст, OpenClaw зберігає цей текст приватним замість публікації в кімнаті.

Використовуйте "automatic" для моделей або середовищ виконання, які ненадійно дотримуються доставлення лише через інструменти: звичайний остаточний текст публікується безпосередньо в кімнаті, а агент усе ще може викликати message(action=send) для файлів, зображень або інших вкладень, які неможливо передати разом з остаточним текстом.

Якщо інструмент повідомлень недоступний згідно з активною політикою інструментів, OpenClaw повертається до автоматичних видимих відповідей замість того, щоб без пояснень приховувати відповідь. openclaw doctor попереджає про цю невідповідність.

Для прямих чатів і будь-яких інших вихідних подій messages.visibleReplies: "message_tool" застосовує ту саму глобальну поведінку лише через інструменти; messages.groupChat.visibleReplies залишається конкретнішим перевизначенням для групових і канальних кімнат. Для прямих звернень у внутрішньому WebChat типово використовується автоматичне доставлення остаточної відповіді, щоб Pi й Codex мали однаковий контракт видимої відповіді.

Режим лише через інструменти замінює старий підхід, за якого модель змушували відповідати NO_REPLY у більшості пасивних звернень. У режимі лише через інструменти запит не визначає контракт NO_REPLY; відсутність видимої дії просто означає, що інструмент повідомлень не викликано.

Прив’язки розмов, якими керують плагіни, є винятком. Щойно плагін прив’язує гілку й приймає вхідне звернення, повернена плагіном відповідь стає видимою відповіддю прив’язки; для неї не потрібен message(action=send). Ця відповідь є результатом роботи середовища виконання плагіна, а не приватним остаточним текстом моделі.

Індикатори набору тексту й надалі надсилаються для прямих групових запитів. Фонові події постійно активних кімнат, коли їх увімкнено, залишаються суворо беззвучними, якщо агент не викликає інструмент повідомлень.

Типово сеанси приховують докладні підсумки щодо інструментів і перебігу виконання. Використовуйте /verbose on (або /verbose full), щоб показувати їх у поточному сеансі під час налагодження, і /verbose off, щоб повернутися до поведінки лише з остаточною відповіддю. Стан докладного виведення визначається окремо для кожного сеансу й однаково працює в прямих чатах, групах, каналах і темах форуму.

Щоб надсилати незгадані повідомлення з постійно активних груп як фоновий контекст кімнати замість запитів користувача, використовуйте Фонові події кімнати:

{  messages: {    groupChat: {      unmentionedInbound: "room_event",    },  },}

Типове значення — unmentionedInbound: "user_request". Повідомлення зі згадками, команди, запити на переривання та особисті повідомлення залишаються запитами користувача.

Щоб вимагати надсилання видимого виведення через інструмент повідомлень для запитів у групах і каналах:

{  messages: {    groupChat: {      visibleReplies: "message_tool",    },  },}

Щоб вимагати цього для кожного вихідного чату:

{  messages: {    visibleReplies: "message_tool",  },}

Gateway застосовує зміни конфігурації messages без перезапуску після збереження файлу. Перезапуск потрібен лише тоді, коли перезавантаження конфігурації вимкнено (gateway.reload.mode: "off").

Звернення з командами обходять visibleReplies: "message_tool" і завжди відповідають видимо: як вбудовані команди з косою рискою (Discord, Telegram та інші середовища з вбудованою підтримкою команд), так і авторизовані текстові команди /... публікують відповідь у вихідному чаті. Неавторизовані текстові звернення /... у групах залишаються доступними лише через інструмент повідомлень; звичайні звернення в чаті дотримуються налаштованого типового значення.

Видимість контексту та списки дозволених

За безпеку груп відповідають два різні механізми:

• Авторизація активації: хто може активувати агента (groupPolicy, groups, groupAllowFrom, списки дозволених для окремих каналів).
• Видимість контексту: який додатковий контекст передається моделі (текст відповіді або цитати, історія гілки, метадані пересилання).

Типово OpenClaw зберігає контекст у отриманому вигляді: списки дозволених визначають, хто може активувати дії, а не те, які цитовані чи історичні фрагменти бачить модель. Щоб також фільтрувати додатковий контекст, налаштуйте contextVisibility:

Налаштуйте це для окремого каналу (channels.<channel>.contextVisibility), облікового запису (channels.<channel>.accounts.<accountId>.contextVisibility) або глобально (channels.defaults.contextVisibility). Канали, що отримують додатковий контекст (Discord, Feishu, iMessage, Matrix, Microsoft Teams, Signal, Slack, Telegram, WhatsApp), застосовують політику під час формування вхідного контексту; невідомі комбінації політик закривають доступ і вилучають контекст.

Якщо потрібно...

Про повторно використовувані списки дозволених відправників див. Групи доступу.

Ключі сеансів

• Групові сеанси використовують ключі сеансів agent:<agentId>:<channel>:group:<id> (кімнати й канали використовують agent:<agentId>:<channel>:channel:<id>).
• Теми форуму Telegram додають :topic:<threadId> до ідентифікатора групи, тому кожна тема має власний сеанс.
• Прямі чати використовують основний сеанс (або окремі сеанси для кожного відправника, якщо налаштовано session.dmScope).
• Heartbeat виконуються в налаштованому сеансі Heartbeat (типово — в основному сеансі агента); групові сеанси не запускають власні Heartbeat.

Схема: особисті повідомлення + публічні групи (один агент)

Так, це добре працює, якщо ваш «особистий» трафік — це особисті повідомлення, а «публічний» — групи.

Причина: у режимі одного агента особисті повідомлення зазвичай потрапляють до ключа основного сеансу (agent:main:main), тоді як групи завжди використовують ключі неосновних сеансів (agent:main:<channel>:group:<id>). Якщо ввімкнути ізоляцію за допомогою mode: "non-main", ці групові сеанси виконуватимуться в налаштованому ізольованому середовищі, а основний сеанс особистих повідомлень залишатиметься на хості. Якщо не вибрати інше середовище, типовим є Docker.

Це забезпечує один «мозок» агента (спільний робочий простір і пам’ять), але два режими виконання:

• Особисті повідомлення: усі інструменти (хост)
• Групи: ізольоване середовище й обмежені інструменти

{  agents: {    defaults: {      sandbox: {        mode: "non-main", // групи/канали є неосновними -> в ізольованому середовищі        scope: "session", // найсильніша ізоляція (один контейнер на групу/канал)        workspaceAccess: "none",      },    },  },  tools: {    sandbox: {      tools: {        // Якщо allow не порожній, усе інше заблоковано (deny однаково має перевагу).        allow: ["group:messaging", "group:sessions"],        deny: ["group:runtime", "group:fs", "group:ui", "nodes", "cron", "gateway"],      },    },  },}

{  agents: {    defaults: {      sandbox: {        mode: "non-main",        scope: "session",        workspaceAccess: "none",        docker: {          binds: [            // hostPath:containerPath:mode            "/home/user/FriendsShared:/data:ro",          ],        },      },    },  },}

Пов’язані матеріали:

• Ключі конфігурації та типові значення: Конфігурація Gateway
• Налагодження причин блокування інструмента: Ізольоване середовище, політика інструментів і підвищені привілеї
• Докладніше про підключення каталогів: Ізоляція

Відображувані мітки

• Мітки інтерфейсу використовують displayName, коли він доступний, у форматі <channel>:<token>.
• #room зарезервовано для кімнат і каналів; групові чати використовують g-<slug> (нижній регістр, пробіли -> -, зберігати #@+._-). Дуже довгі непрозорі ідентифікатори скорочуються до стабільного токена, щоб повні ідентифікатори маршрутів не потрапляли до інтерфейсу.

Політика груп

Керуйте обробкою повідомлень груп і кімнат окремо для кожного каналу:

{  channels: {    whatsapp: {      groupPolicy: "disabled", // "open" | "disabled" | "allowlist"      groupAllowFrom: ["+15551234567"],    },    telegram: {      groupPolicy: "disabled",      groupAllowFrom: ["123456789"], // числовий ідентифікатор користувача Telegram (під час налаштування @username перетворюється на ідентифікатор)    },    signal: {      groupPolicy: "disabled",      groupAllowFrom: ["+15551234567"],    },    imessage: {      groupPolicy: "disabled",      groupAllowFrom: ["chat_id:123"],    },    msteams: {      groupPolicy: "disabled",      groupAllowFrom: ["user@org.com"],    },    discord: {      groupPolicy: "allowlist",      guilds: {        GUILD_ID: { channels: { help: { enabled: true } } },      },    },    slack: {      groupPolicy: "allowlist",      channels: { "#general": { enabled: true } },    },    matrix: {      groupPolicy: "allowlist",      groupAllowFrom: ["@owner:example.org"],      groups: {        "!roomId:example.org": { enabled: true },        "#alias:example.org": { enabled: true },      },    },  },}

Коротка ментальна модель (порядок оцінювання групових повідомлень):

Вимога згадки (за замовчуванням)

Групові повідомлення потребують згадки, якщо це не перевизначено для окремої групи. Значення за замовчуванням розташовані для кожної підсистеми в *.groups."*".

Відповідь на повідомлення бота вважається неявною згадкою, коли канал надає метадані відповіді; цитування повідомлення бота також може вважатися згадкою в каналах, що надають метадані цитування. Поточні вбудовані випадки: Discord, Microsoft Teams, QQBot, Slack, Telegram, WhatsApp і персональний Zalo.

{  channels: {    whatsapp: {      groups: {        "*": { requireMention: true },        "123@g.us": { requireMention: false },      },    },    telegram: {      groups: {        "*": { requireMention: true },        "123456789": { requireMention: false },      },    },    imessage: {      groups: {        "*": { requireMention: true },        "123": { requireMention: false },      },    },  },  agents: {    list: [      {        id: "main",        groupChat: {          mentionPatterns: ["@openclaw", "openclaw", "\\+15555550123"],          historyLimit: 50,        },      },    ],  },}

Обмеження області налаштованих шаблонів згадок

Налаштовані mentionPatterns — це резервні тригери на основі регулярних виразів. Використовуйте їх, коли платформа не надає нативної згадки бота або коли потрібно, щоб звичайний текст, наприклад openclaw:, вважався згадкою. Нативні згадки платформи обробляються окремо: коли Discord, Slack, Telegram, Matrix, Signal або інший канал може підтвердити, що повідомлення явно згадує бота, ця нативна згадка все одно спрацьовує, навіть якщо налаштовані шаблони регулярних виразів заборонено.

За замовчуванням налаштовані шаблони згадок застосовуються всюди, де канал передає дані про провайдера та розмову до механізму виявлення згадок. Щоб широкі шаблони не активували агента в кожній групі, обмежте їхню область для кожного каналу за допомогою channels.<channel>.mentionPatterns.

Використовуйте mode: "deny", коли шаблони згадок на основі регулярних виразів мають бути за замовчуванням вимкнені для каналу, а потім увімкніть їх у певних кімнатах за допомогою allowIn:

{  messages: {    groupChat: {      mentionPatterns: ["\\bopenclaw\\b", "\\bops bot\\b"],    },  },  channels: {    slack: {      mentionPatterns: {        mode: "deny",        allowIn: ["C0123OPS"],      },    },  },}

Використовуйте стандартний mode: "allow" (або не вказуйте mode), коли шаблони згадок на основі регулярних виразів мають застосовуватися широко, а потім вимкніть їх у галасливих кімнатах за допомогою denyIn:

{  messages: {    groupChat: {      mentionPatterns: ["\\bopenclaw\\b"],    },  },  channels: {    telegram: {      mentionPatterns: {        denyIn: ["-1001234567890", "-1001234567890:topic:42"],      },    },  },}

Визначення політики:

Підтримувана нині політика обмеження області регулярних виразів:

У конфігураціях каналів на рівні облікового запису можна налаштувати таку саму політику в channels.<channel>.accounts.<accountId>.mentionPatterns, якщо канал підтримує кілька облікових записів. Для цього облікового запису політика облікового запису має перевагу над політикою каналу верхнього рівня.

Обмеження інструментів для групи/каналу (необов’язково)

Деякі конфігурації каналів підтримують обмеження інструментів, доступних у певній групі/кімнаті/каналі.

• tools: дозволяє/забороняє інструменти для всієї групи (allow, alsoAllow, deny; заборона має перевагу).
• toolsBySender: перевизначення для окремих відправників у групі. Використовуйте явні префікси ключів: channel:<channelId>:<senderId>, id:<senderId>, e164:<phone>, username:<handle>, name:<displayName> і шаблон "*". Ідентифікатори каналів використовують канонічні ідентифікатори каналів OpenClaw; псевдоніми на кшталт teams нормалізуються до msteams. Застарілі ключі без префіксів усе ще приймаються, зіставляються лише як id: і спричиняють запис попередження про застарілість до журналу.

Порядок визначення (найконкретніше правило має перевагу):

Приклад (Telegram):

{  channels: {    telegram: {      groups: {        "*": { tools: { deny: ["exec"] } },        "-1001234567890": {          tools: { deny: ["exec", "read", "write"] },          toolsBySender: {            "id:123456789": { alsoAllow: ["exec"] },          },        },      },    },  },}

Списки дозволених груп

Коли налаштовано channels.whatsapp.groups, channels.telegram.groups або channels.imessage.groups, ключі діють як список дозволених груп. Використовуйте "*", щоб дозволити всі групи, водночас задавши типову поведінку щодо згадок.

Поширені сценарії (скопіюйте та вставте):

{  channels: { whatsapp: { groupPolicy: "disabled" } },}

{  channels: {    whatsapp: {      groups: {        "123@g.us": { requireMention: true },        "456@g.us": { requireMention: false },      },    },  },}

{  channels: {    whatsapp: {      groups: { "*": { requireMention: true } },    },  },}

{  channels: {    whatsapp: {      groupPolicy: "allowlist",      groupAllowFrom: ["+15551234567"],      groups: { "*": { requireMention: true } },    },  },}

Активація (лише власником)

Власники груп можуть перемикати активацію окремо для кожної групи за допомогою окремого повідомлення:

• /activation mention
• /activation always

/activation — це основна команда з доступом лише для власника, яка застосовується тільки в групових чатах. Власником вважається відправник, який відповідає commands.ownerAllowFrom; списки allowFrom каналу керують лише звичайним доступом до каналу та команд. Збережений режим перевизначає requireMention цієї групи в каналах, які його враховують (Google Chat, QQBot, Telegram, WhatsApp), а вступ системного запиту для групи всюди відображає активний режим.

Поля контексту

Вхідні корисні навантаження груп задають:

• ChatType=group
• GroupSubject (якщо відомо)
• GroupMembers (якщо відомо)
• WasMentioned (результат перевірки згадки)
• Теми форумів Telegram також містять MessageThreadId і IsForum.

Системний запит агента містить вступ для групи на першому кроці нового групового сеансу (і після зміни /activation). Він нагадує моделі відповідати як людина, зводити до мінімуму порожні рядки, дотримуватися звичайних інтервалів у чаті та не вводити буквальні послідовності \n. Канали, заявлений режим таблиць яких не зберігає нативні або необроблені таблиці, також не рекомендують використовувати таблиці Markdown. Назви груп і позначення учасників, отримані з каналів, відтворюються як ненадійні метадані в огородженому блоці, а не як вбудовані системні інструкції.

Особливості iMessage

• Для маршрутизації або додавання до списку дозволених віддавайте перевагу chat_id:<id>.
• Перегляд списку чатів: imsg chats --limit 20.
• Групові відповіді завжди надсилаються назад до того самого chat_id.

Системні запити WhatsApp

Канонічні правила системних запитів WhatsApp, зокрема визначення групових і прямих запитів, поведінку символу підстановки та семантику перевизначення облікового запису, див. у WhatsApp.

Особливості WhatsApp

Поведінку лише для WhatsApp (додавання історії, подробиці обробки згадок) див. у розділі Групові повідомлення.

Пов’язане

• Групи розсилки
• Маршрутизація каналів
• Групові повідомлення
• Сполучення