OpenClaw Telegram: отдельный бот команды, список допущенных и ручной тест

Telegram-канал в OpenClaw — это отдельный бот команды: он подключается к Gateway по токену от BotFather и отвечает только тем людям и группам, которых вы допустили: через парное подтверждение или по списку числовых идентификаторов. Доступ делится на личные сообщения и группы, и у каждого свои правила. Подключайте канал после того, как Gateway уже работает и вы решили, какие поручения агент вправе принимать из чата.

Бот и токен

Для команды заведите отдельного бота командой /newbot в BotFather и оставьте в стороне бота, который уже обслуживает клиентов или другой сервис. Отдельный бот даёт отдельный токен, а значит и отдельную остановку. По документации по настройке Telegram токен добавляют командой openclaw channels add --channel telegram --token <bot-token> либо записывают в поле botToken файла ~/.openclaw/openclaw.json. Есть и поле tokenFile: оно принимает обычный файл, символьную ссылку Gateway отвергает.

Транспортом по умолчанию служит долгий опрос (long polling), и входящий адрес для Telegram открывать нужды нет. Режим вебхука существует как отдельный вариант, но для первого запуска он добавляет сертификат и публичный адрес, то есть лишнюю поверхность. Если ботов несколько, явно задайте channels.telegram.defaultAccount: иначе OpenClaw выберет первый аккаунт по нормализованному идентификатору.

Токен бота — секрет того же класса, что пароль. Храните его в менеджере секретов, а в чат команды и в тикеты кладите только имя бота. Запись об изменении должна называть владельца токена и место хранения. Общую схему входа, действий и допуска рабочего чата мы разбирали в статье про ИИ-агента в рабочем Telegram-чате; здесь речь о настройках самого канала OpenClaw.

Кто допущен

Допуск описывают пять параметров, и их полезно держать перед глазами одной таблицей. Личные сообщения и группы настраиваются независимо: страница про контроль доступа прямо предупреждает, что парное подтверждение открывает только личные сообщения, а группы требуют отдельного списка.

Режим open уместен для публичного бота, а для агента, у которого есть инструменты, он слишком широк. Идентификатор сотрудника проще всего получить из ответа бота при первом обращении: ответ с кодом подтверждения содержит числовой идентификатор отправителя. Есть и другие пути: команда openclaw logs --follow и метод getUpdates Bot API. Список ведите в файле под ревью, чтобы добавление человека было видно в истории изменений.

Скрытый риск лежит в содержимом сообщений. Пересланные тексты, вложения и цитаты из чужих чатов остаются данными, даже если выглядят как приказ. Поручение имеет вес, когда его написал допущенный сотрудник от своего имени. Об этом правиле стоит напомнить команде письменно.

Маршрут сообщений

Маршрутизацию задаёт сам Gateway, и права выбирать канал ответа у модели нет: ответ возвращается туда, откуда пришло сообщение, и у каждой группы своя сессия. Если агентов несколько, документация описывает маршрутизацию по агентам с изолированными сессиями. Привязку канала или аккаунта к агенту выбирайте исходя из ролей: бот поддержки и бот аналитики разделяются по аккаунтам, и тогда у каждого свой токен, свой список допущенных и свой набор инструментов.

• Личные сообщения подходят для поручений, где есть персональные данные сотрудника или клиента: переписка остаётся между человеком и агентом.
• Группа подходит для общих запросов, которые видит вся команда, например «сводка по вчерашним заявкам».
• Режим приватности бота в Telegram по умолчанию ограничивает видимость сообщений. Его меняют командой /setprivacy в BotFather или делают бота администратором группы; после смены бота удаляют из группы и добавляют снова.
• Для записи в учётные системы агенту выдают отдельный узкий доступ, а подтверждение действия сотрудник вносит в самой системе.

Отдельно продумайте ответы в группе. Когда бот отвечает на упоминание, его текст видят все участники, поэтому сводки с персональными данными клиентов в общий чат направлять запрещено: агент отправляет их в личные сообщения запросившему сотруднику. Договорённость о том, что допустимо писать при всех, а что только лично, фиксируют в одном абзаце закреплённого сообщения группы.

Для сравнения: если нужно принять заявку и передать диалог оператору, подойдёт сценарий из статьи про n8n и Telegram, где последовательность шагов задана заранее. В OpenClaw агент рассуждает по ходу беседы, поэтому ограничения вы ставите на инструменты и допуск, а ветки диалога играют второстепенную роль.

Ручной тест

Проверку проводит человек и записывает результат: так видно, что именно получил посторонний. Нужны два аккаунта: сотрудник из списка и посторонний, которого вы намеренно оставили вне списка.

1. Запустите openclaw channels status --probe и убедитесь, что канал готов, а токен принят.
2. Напишите боту с аккаунта, которого нет в списке. При политике pairing придёт код подтверждения; при allowlist бот молчит. Запишите, что произошло.
3. Одобрите нужный запрос командами openclaw pairing list telegram и openclaw pairing approve telegram <CODE>, затем переведите dmPolicy в allowlist и внесите идентификатор в allowFrom.
4. Повторите сообщение от сотрудника и от постороннего. Первый получает ответ, второй остаётся без ответа.
5. Внесите сотрудника в groupAllowFrom, добавьте бота в разрешённую группу и в соседнюю, которой нет в списке. Упоминание бота в первой даёт ответ, во второй тишину.

Результат теста оформите короткой таблицей: аккаунт, место, действие, фактический исход. Такую запись легко сверить при следующем обновлении Gateway, когда поведение канала могло измениться. Если исход отличается от ожидаемого, остановите канал и разберите журнал, а правку конфигурации вносите только после того, как причина названа.

Gateway следит за файлом конфигурации и применяет часть правок сам, а изменения каналов могут потребовать перезапуска. После каждой правки возвращайтесь к шагу 4: лишние двери должны оставаться закрытыми. Журнал канала смотрите через openclaw logs --follow; в нём видны запросы на подтверждение и идентификаторы отправителей, и это самый быстрый способ заметить чужую попытку.

Остановка канала

Остановку описывают до запуска, задолго до первого происшествия. Работают три уровня, и каждый проверяется отдельно: параметр enabled со значением false в разделе канала, перевод dmPolicy и groupPolicy в disabled и отзыв токена командой /revoke в BotFather. Первый уровень гасит канал в Gateway, второй закрывает входящие сообщения, третий лишает старый токен силы даже при его утечке.

Проверка остановки такая же ручная, как проверка допуска. После выключения напишите боту с аккаунта сотрудника: бот должен молчать. Выпустите новый токен в BotFather, внесите его в менеджер секретов и убедитесь, что статус канала снова показывает готовность. Запись в журнале изменений называет причину и время остановки, а также того, кто разрешил запуск обратно.

Решение об остановке принимает человек, и права на него стоит раздать заранее: владелец токена, администратор Gateway и руководитель команды. Остальные сотрудники пишут им, и сообщение «бот отвечает странно» считается достаточным поводом для паузы.

Частые вопросы