OpenClaw ne répond pas

Un agent OpenClaw qui reste muet est la plainte la plus fréquente après le coût, et le diagnostic tient presque toujours à l’une de huit choses. Le projet livre désormais un parcours de triage qui mène à un diagnostic en deux minutes environ. Le voici en langage clair, suivi des causes qui remplissent les forums, et de ce qui change quand quelqu’un d’autre exploite la passerelle pour vous.

Les soixante premières secondes

Suivez l’échelle dans l’ordre : triage, état, sonde de la passerelle, état de la passerelle, doctor, sonde des canaux, puis les journaux en continu. Un système sain se lit ainsi : joignable, environnement en cours d’exécution, sonde de connectivité ok, aucune erreur bloquante du doctor, et chaque canal signalant un transport actif. La commande de triage écrit un diagnostic expurgé que vous pouvez confier à un agent, à un forum ou au support.

Les suspects habituels

• Appairage en attente : un expéditeur inconnu lui a écrit et personne n’a approuvé la demande, il l’ignore donc à dessein. La version en production, c’est une passerelle coincée dans une boucle de reconnexion qui réclame un appairage.
• Filtrage par mention dans un groupe : il ignore les messages de groupe tant qu’il n’est pas mentionné, et le dit dans les journaux.
• Une liste d’autorisation qui ne correspond pas : l’expéditeur, le canal ou le modèle est filtré par la politique. Un modèle absent de la liste fait échouer en silence les tâches planifiées et les sous-agents.
• Le profil d’outils : un profil minimal n’autorise presque rien, il répond donc mais ne peut pas agir.
• Le fournisseur : une limite de débit, un identifiant expiré comme un jeton de test Google OAuth, ou un refus, visibles dans les journaux sous la forme d’un 429 ou d’un 403.
• Un échec de livraison qui ressemble à un échec de tâche : une tâche planifiée marquée en échec avec un 401 côté Telegram ou côté passerelle alors que le travail lui-même a réussi.
• Une extension ou un canal désactivé après une mise à jour : l’assistant tourne, mais la porte par laquelle il répondait est fermée.
• La passerelle elle-même : arrêtée, en cours de redémarrage, ou tuée faute de mémoire sur un petit hôte.

Il est resté là pendant deux heures sans rien faire.

Lent n’est pas bloqué

Une réponse qui arrive avec des minutes de retard, c’est en général un modèle saturé, un long contexte relu, ou un tour de battement de cœur qui occupe la session. Le battement de cœur d’OpenClaw explique ce dernier cas, et pourquoi c’est aussi la raison pour laquelle un agent inactif ne l’est jamais tout à fait.

Ce qui change sur un hébergement géré

L’échelle ci-dessus suppose un shell sur la machine. Sur Diali, il n’y a pas de machine : le fil d’activité montre le provisionnement, les mises à jour et les événements de canal, le tableau de bord propose pause, redémarrage et réinstallation, et la passerelle est surveillée pour vous. L’appairage, les listes d’autorisation et le profil d’outils restent à vous, parce que c’est de la politique, pas de la plomberie. OpenClaw hébergé sur Diali décrit le reste.

Avant de poster sur un forum

• Lancez le triage et joignez sa sortie ; c’est la première chose que tout le monde vous demandera.
• Vérifiez l’appairage et le filtrage par mention avant de reconnecter quoi que ce soit.
• Cherchez dans les journaux les trois signatures : mention requise, demande d’appairage, bloqué.
• Si c’est lent plutôt que muet, regardez d’abord le fournisseur et le battement de cœur.

Et si le mot passerelle, dans tout cela, est la partie que vous n’avez jamais comprise, La passerelle OpenClaw, expliquée est l’explication.