Skip to main content
OpenClaw применяет одинаковые правила для групп во всех каналах с поддержкой групп, включая Discord, iMessage, Matrix, Microsoft Teams, QQBot, Signal, Slack, Telegram, WhatsApp и Zalo. Для постоянно активных комнат, которые должны незаметно предоставлять контекст, пока агент явно не отправит видимое сообщение, см. Фоновые события комнаты.

Введение для начинающих (2 минуты)

OpenClaw «живёт» в ваших собственных учётных записях мессенджеров. Отдельного пользователя-бота WhatsApp нет: если вы состоите в группе, OpenClaw может видеть эту группу и отвечать в ней. Поведение по умолчанию:
  • Группы ограничены (groupPolicy: "allowlist"); отправители в группах блокируются, пока их не добавят в список разрешённых.
  • Для ответов требуется упоминание, если вы не отключили проверку упоминаний для группы.
  • Итоговый текст ответа автоматически публикуется в комнате (visibleReplies: "automatic").
Иными словами, отправители из списка разрешённых могут активировать OpenClaw, упомянув его.
Кратко
  • Доступ к личным сообщениям контролируется параметром *.allowFrom.
  • Доступ к группам контролируется параметром *.groupPolicy и списками разрешённых (*.groups, *.groupAllowFrom).
  • Запуск ответа контролируется проверкой упоминаний (requireMention, /activation).
Краткая схема обработки группового сообщения:

Видимые ответы

Для обычных запросов в группах и каналах 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, чтобы вернуться к режиму только итоговых ответов. Состояние подробного вывода задаётся отдельно для каждого сеанса и одинаково работает в личных чатах, группах, каналах и темах форумов. Чтобы отправлять сообщения без упоминания из постоянно активной группы как незаметный контекст комнаты, а не как запросы пользователя, используйте Фоновые события комнаты:
Значение по умолчанию — unmentionedInbound: "user_request". Сообщения с упоминанием, команды, запросы на прерывание и личные сообщения остаются запросами пользователя. Чтобы видимый вывод для запросов в группах и каналах обязательно проходил через инструмент сообщений:
Чтобы это требование применялось ко всем исходным чатам:
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. Так вы получаете один «мозг» агента (общее рабочее пространство и память), но два режима выполнения:
  • Личные сообщения: полный набор инструментов (хост)
  • Группы: песочница и ограниченный набор инструментов
Если нужны полностью раздельные рабочие пространства или персоны («личное» и «публичное» никогда не должны смешиваться), используйте второго агента и привязки. См. Маршрутизация между несколькими агентами.
Связанные материалы:

Отображаемые метки

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

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

Настройте обработку сообщений групп и комнат отдельно для каждого канала:
  • groupPolicy настраивается отдельно от требования упоминания (которое требует @упоминаний).
  • WhatsApp/Telegram/Signal/iMessage/Microsoft Teams/Zalo: используйте groupAllowFrom (резервный вариант: явный allowFrom).
  • Signal: groupAllowFrom может соответствовать либо идентификатору входящей группы Signal, либо телефону/UUID отправителя.
  • Подтверждения связывания личных сообщений (записи хранилища *-allowFrom) применяются только к доступу через личные сообщения; авторизация отправителей в группах по-прежнему задаётся явно списками разрешений групп.
  • Discord: для списка разрешений используется channels.discord.guilds.<id>.channels.
  • Slack: для списка разрешений используется channels.slack.channels.
  • Matrix: для списка разрешений используется channels.matrix.groups. Используйте идентификаторы комнат (!room:server) или псевдонимы (#alias:server); ключи с именами комнат сопоставляются только при наличии channels.matrix.dangerouslyAllowNameMatching: true, а неразрешённые записи игнорируются во время выполнения. Используйте channels.matrix.groupAllowFrom для ограничения отправителей; также поддерживаются списки разрешений users для отдельных комнат.
  • Групповые личные сообщения управляются отдельно (channels.discord.dm.*, channels.slack.dm.*: groupEnabled, groupChannels).
  • Telegram: списки разрешённых отправителей принимают только числовые идентификаторы пользователей ("123456789"; префиксы telegram:/tg: удаляются без учёта регистра). Записи @username не сопоставляются во время выполнения, и в журнал записывается предупреждение; при настройке @username преобразуется в идентификаторы. Отрицательные идентификаторы чатов следует указывать в channels.telegram.groups, а не в списках разрешённых отправителей.
  • Значение по умолчанию — groupPolicy: "allowlist"; если список разрешённых групп пуст, групповые сообщения блокируются.
  • Безопасность во время выполнения: если блок провайдера полностью отсутствует (channels.<provider> отсутствует), групповая политика в закрытом режиме переключается на allowlist вместо наследования channels.defaults.groupPolicy, а Gateway один раз для каждой учётной записи записывает в журнал сведения о резервном поведении.
Краткая концептуальная модель (порядок проверки групповых сообщений):
1

groupPolicy

groupPolicy (open/disabled/allowlist).
2

Списки разрешений групп

Списки разрешений групп (*.groups, *.groupAllowFrom, список разрешений конкретного канала).
3

Требование упоминания

Требование упоминания (requireMention, /activation).

Требование упоминания (по умолчанию)

Для групповых сообщений требуется упоминание, если это не переопределено для конкретной группы. Значения по умолчанию задаются для каждой подсистемы в *.groups."*". Ответ на сообщение бота считается неявным упоминанием, если канал предоставляет метаданные ответа; цитирование сообщения бота также может считаться упоминанием в каналах, предоставляющих метаданные цитирования. Текущие встроенные варианты: Discord, Microsoft Teams, QQBot, Slack, Telegram, WhatsApp и персональный Zalo.

Ограничение области настроенных шаблонов упоминаний

Настроенные mentionPatterns — это резервные триггеры в виде регулярных выражений. Используйте их, когда платформа не предоставляет нативное упоминание бота или когда обычный текст, например openclaw:, должен считаться упоминанием. Нативные упоминания платформы обрабатываются отдельно: когда Discord, Slack, Telegram, Matrix, Signal или другой канал может подтвердить, что сообщение явно упоминает бота, такое нативное упоминание всё равно срабатывает, даже если настроенные шаблоны регулярных выражений запрещены. По умолчанию настроенные шаблоны упоминаний применяются везде, где канал передаёт сведения о провайдере и беседе механизму обнаружения упоминаний. Чтобы широкие шаблоны не активировали агента в каждой группе, ограничьте их область для каждого канала с помощью channels.<channel>.mentionPatterns. Используйте mode: "deny", если шаблоны упоминаний в виде регулярных выражений должны быть по умолчанию отключены для канала, а затем включите их для определённых комнат с помощью allowIn:
Используйте значение по умолчанию mode: "allow" (или опустите mode), если шаблоны упоминаний в виде регулярных выражений должны применяться широко, а затем отключите их в шумных комнатах с помощью denyIn:
Разрешение политики: Поддерживаемая на данный момент политика области регулярных выражений: Конфигурации каналов на уровне учётной записи могут задавать ту же политику в channels.<channel>.accounts.<accountId>.mentionPatterns, если канал поддерживает несколько учётных записей. Для этой учётной записи политика уровня учётной записи имеет приоритет над политикой верхнего уровня канала.
  • mentionPatterns — безопасные шаблоны регулярных выражений без учёта регистра; недопустимые шаблоны и небезопасные формы с вложенным повторением игнорируются (с предупреждением).
  • Приоритет шаблонов: agents.list[].groupChat.mentionPatterns (полезно, когда несколько агентов используют одну группу) переопределяет messages.groupChat.mentionPatterns; если не задано ни одно из значений, шаблоны формируются на основе имени/эмодзи идентичности агента.
  • Требование упоминания применяется только тогда, когда обнаружение упоминания возможно (настроены нативные упоминания или mentionPatterns).
  • Добавление группы или отправителя в список разрешений не отключает требование упоминания; задайте для requireMention этой группы значение false, если срабатывать должны все сообщения.
  • Контекст запроса автоматического группового чата при каждом ходе содержит разрешённую инструкцию о безмолвном ответе; файлы рабочей области не должны дублировать механику NO_REPLY.
  • В группах, где разрешены автоматические безмолвные ответы, чистые пустые ходы модели или ходы только с рассуждениями считаются безмолвными, что эквивалентно NO_REPLY. В личные чаты никогда не передаётся указание NO_REPLY, а групповые ответы только через инструмент сообщений остаются безмолвными, поскольку message(action=send) не вызывается.
  • Для фонового постоянно активного общения в группах по умолчанию применяется семантика пользовательского запроса. Задайте messages.groupChat.unmentionedInbound: "room_event", чтобы вместо этого отправлять его как тихий контекст. Примеры настройки см. в разделе Фоновые события комнаты.
  • События комнаты не сохраняются как фиктивные пользовательские запросы, а приватный текст ассистента из событий комнаты без инструмента сообщений не воспроизводится в истории чата.
  • Значения Discord по умолчанию задаются в channels.discord.guilds."*" (их можно переопределить для отдельной гильдии/канала).
  • Контекст истории группы во всех каналах оформляется единообразно. В группах с требованием упоминания сохраняются ожидающие пропущенные сообщения; в постоянно активных группах также могут сохраняться недавние обработанные сообщения комнаты, если канал это поддерживает. Используйте messages.groupChat.historyLimit как глобальное значение по умолчанию и channels.<channel>.historyLimit (или channels.<channel>.accounts.*.historyLimit) для переопределений. Чтобы отключить, задайте 0.

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

Некоторые конфигурации каналов позволяют ограничивать доступные инструменты внутри определённой группы/комнаты/канала.
  • tools: разрешение/запрет инструментов для всей группы (allow, alsoAllow, deny; запрет имеет приоритет).
  • toolsBySender: переопределения для отдельных отправителей внутри группы. Используйте явные префиксы ключей: channel:<channelId>:<senderId>, id:<senderId>, e164:<phone>, username:<handle>, name:<displayName> и подстановочный знак "*". Идентификаторы каналов используют канонические идентификаторы каналов OpenClaw; псевдонимы, например teams, нормализуются в msteams. Устаревшие ключи без префикса по-прежнему принимаются, сопоставляются только как id: и приводят к записи предупреждения об устаревании в журнал.
Порядок разрешения (наиболее конкретное правило имеет приоритет):
1

Групповые toolsBySender

Соответствие toolsBySender группы/канала.
2

Групповые tools

tools группы/канала.
3

Стандартные toolsBySender

Соответствие toolsBySender по умолчанию ("*").
4

Стандартные tools

tools по умолчанию ("*").
Пример (Telegram):
Ограничения инструментов для групп/каналов применяются в дополнение к глобальной политике и политике инструментов агента (запрет всегда имеет приоритет). Некоторые каналы используют разную вложенность для комнат/каналов (например, Discord guilds.*.channels.*, Slack channels.*, Microsoft Teams teams.*.channels.*).

Списки разрешённых групп

Если настроен параметр channels.whatsapp.groups, channels.telegram.groups или channels.imessage.groups, его ключи действуют как список разрешённых групп. Используйте "*", чтобы разрешить все группы, сохранив при этом стандартное поведение для упоминаний.
Распространённая ошибка: одобрение сопряжения в личных сообщениях — не то же самое, что авторизация группы. Для каналов, поддерживающих сопряжение в личных сообщениях, хранилище сопряжений открывает доступ только к личным сообщениям. Для групповых команд по-прежнему требуется явная авторизация отправителя в группе через списки разрешений в конфигурации, например groupAllowFrom, или через документированный резервный параметр конфигурации этого канала.
Типовые варианты (можно скопировать и вставить):

Активация (только владельцем)

Владельцы групп могут переключать активацию для каждой группы отдельным сообщением:
  • /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 (добавление истории и особенности обработки упоминаний), описано в разделе Групповые сообщения.

Связанные материалы