OpenClaw no responde

Un agente de OpenClaw que se queda parado es la queja más habitual después del costo, y el diagnóstico casi siempre es una de ocho cosas. El proyecto incluye ahora un flujo de triaje que te lleva a un diagnóstico en unos dos minutos. Aquí lo tienes en lenguaje sencillo, seguido de las causas que llenan los foros y de lo que cambia cuando otra persona gestiona el Gateway por ti.

Los primeros sesenta segundos

Recorre la escalera en orden: triage, status, gateway probe, gateway status, doctor, channels probe y, después, sigue los logs. Un sistema sano se ve así: accesible, runtime en ejecución, sonda de conectividad en ok, ningún error bloqueante de doctor y todos los canales informando de un transporte activo. El comando triage escribe un diagnóstico saneado que puedes pasar a un agente, a un foro o al soporte.

Los sospechosos habituales

• Emparejamiento pendiente: un remitente desconocido le escribió y nadie aprobó la solicitud, así que lo ignora por diseño. La versión en producción es un Gateway atascado en un bucle de reconexión con el error pairing required.
• Filtro por mención en un grupo: descarta los mensajes de grupo hasta que se le menciona, y lo indica en los logs.
• Una lista de permitidos que no coincide: el remitente, el canal o el modelo están filtrados por la política. Un modelo que no está en la lista de permitidos hace que las tareas cron y los subagentes fallen en silencio.
• El perfil de herramientas: un perfil minimal no permite casi nada, así que responde pero no puede actuar.
• El proveedor: un límite de tasa, una credencial caducada, como un token de prueba de Google OAuth, o un rechazo, visibles en los logs como un 429 o un 403.
• Un fallo de entrega que parece un fallo de la tarea: una tarea cron marcada como fallida con un 401 del lado de Telegram o del gateway, aunque el trabajo en sí se completó.
• Un plugin o un canal desactivado tras una actualización, de modo que el asistente está en marcha, pero la puerta por la que respondía está cerrada.
• El propio Gateway: caído, reiniciándose o terminado por falta de memoria en un host pequeño.

Se quedó ahí parado 2 horas sin hacer nada.

Lento no es lo mismo que atascado

Una respuesta que llega con minutos de retraso suele deberse a un modelo ocupado, a un contexto largo que se vuelve a leer o a un turno de heartbeat que ocupa la sesión. El heartbeat de OpenClaw explica esto último, y por qué es también la razón de que un agente inactivo nunca esté del todo inactivo.

Qué cambia en un alojamiento gestionado

La escalera anterior supone un shell en la máquina. En Diali no hay máquina: el registro de actividad muestra el aprovisionamiento, las actualizaciones y los eventos de canal, el panel tiene pausar, reiniciar y reinstalar, y el Gateway se vigila por ti. El emparejamiento, las listas de permitidos y el perfil de herramientas siguen siendo cosa tuya, porque son política, no fontanería. OpenClaw alojado en Diali describe el resto.

Antes de publicar en un foro

• Ejecuta triage y adjunta su salida; es lo primero que te pedirá cualquiera que te ayude.
• Comprueba el emparejamiento y el filtro por mención antes de reconectar nada.
• Busca en los logs las tres firmas: mention required, pairing request, blocked.
• Si es lento en lugar de estar en silencio, mira primero el proveedor y el heartbeat.

Y si la palabra Gateway es, en todo esto, la parte que nunca entendiste, la explicación está en este artículo sobre el Gateway de OpenClaw.