Когда смотришь демо OpenClaw, кажется: «поставил, подключил Telegram — и готово». На практике всё чуть интереснее: сам агент поднимается быстро, а дальше начинается инженерная часть — сеть, токены, cron и связность нод.

Ниже — честный разбор, что у меня ломалось, почему это происходило и как я это чинил.

Почему это не «просто чат-бот»

OpenClaw — это не только LLM. Это связка компонентов:

  • Gateway
  • ноды / relay на устройствах
  • cron-раннер
  • канал доставки (Telegram и т.д.)
  • внешние источники данных (RSS, web_fetch, MCP)

По факту это мини-распределённая система. А проблемы тут типичные для любой автоматики: auth, сетевые зависимости, таймауты, наблюдаемость.

Сложность №1: device token mismatch

Один из самых неприятных сценариев: всё вроде работало, потом часть команд начинает отвечать unauthorized / device token mismatch.

Почему так бывает

Обычно после перепривязки, ротации токена или рассинхрона между локальным конфигом и тем, что ожидает gateway.

Что помогло

  • проверить текущий статус gateway и нод
  • синхронизировать токены
  • перезапустить gateway
  • повторно проверить cron list и nodes status

Вывод: токен-слой нужно воспринимать как часть инфраструктуры, а не как разовую настройку.

Сложность №2: ноды paired, но offline

Коварная ситуация: в панели видно, что нода привязана, но по факту disconnected.

Что это значит

Пара есть, живого канала нет. Чаще всего проблема не в OpenClaw как таковом, а в сети / relay / туннеле.

Практический урок

Смотреть нужно не только на paired, а именно на connected/offline статус.

«Привязан» ≠ «работает».

Сложность №3: SSH-туннель как точка отказа

Если gateway доступен через ssh -L ..., появляется скрытая зависимость: уснул/перезагрузился хост — и всё отвалилось.

Что с этим делать

Поднимать туннель как сервис, а не вручную:

  • systemd (Linux)
  • launchd (macOS)

Иначе рано или поздно будет классическое: «вчера работало, утром всё оффлайн».

Сложность №4: cron run timeout не всегда означает падение

Самая вводящая в заблуждение история.

Запускаешь cron run, видишь:

gateway timeout after 60000ms

и кажется, что задача упала. Но затем прилетает успешный результат.

Что происходит на самом деле

Это таймаут ожидания ответа клиентом, а не таймаут выполнения самой job. Если задача выполняется дольше 60 секунд, ручной вызов может вернуть timeout, а сама job спокойно завершится в фоне.

Практический вывод

Разделяй:

  • timeout ручного вызова
  • реальный статус выполнения job (ok/error в run history)

Как я теперь проверяю, что cron действительно рабочий

Вместо «дёргать force-run и нервничать» — короткий smoke-test:

  1. Создаю одноразовую job (at на +1–2 минуты)
  2. Лёгкий payload (до 20–30 секунд)
  3. Жду фактическую доставку в Telegram
  4. Проверяю run history

Так проверяется весь pipeline end-to-end:

cron → agentTurn → announce

Без ложной паники от таймаутов ручного запуска.

Визуально: где обычно ломается OpenClaw

gallery/01-token-mismatch.png gallery/02-nodes-offline.png gallery/03-ssh-tunnel-spof.png gallery/04-cron-timeout.png gallery/05-smoke-test.png

Что в итоге реально важно

После всей возни главный вывод очень простой:

  1. Сначала связность, потом интеллект
  2. Сначала сервисы и автоподъём, потом ручные команды
  3. Сначала end-to-end проверка, потом усложнение сценариев

OpenClaw отлично работает и в быту, и в проде — если относиться к нему как к системе, а не как к «боту в чате».

Мини-чеклист после любой настройки OpenClaw

openclaw nodes status
openclaw cron list

Если ноды offline — сначала лечим сеть/туннель. Если всё зелёное — запускаем короткий smoke-test и только потом добавляем тяжёлые cron-задачи.

Если будет интересно, во второй части могу разобрать production-ready шаблон конфига для домашнего сетапа: Pi + Mac node + Telegram.