Tableau de bord OpenClaw: vérifier les quatre couches avant de faire confiance au vert

La réponse courte est: un tableau de bord OpenClawZ qui charge n'est pas encore une preuve qu'un agent est en bonne santé. Traitez l'interface utilisateur de contrôle comme quatre contrôles distincts: la surface du navigateur est chargée, la passerelle a accepté une connexion WebSocket authentifiée, le tableau de bord affiche l'agent prévu et l'exécution courante, et le résultat promis existe. Seule la dernière condition conclut la tâche. Cette distinction est importante parce que chaque couche peut être verte tandis que la couche suivante est cassée. Les actifs statiques peuvent être rendus pendant que le WebSocket est déconnecté. Une passerelle peut répondre pendant que la session sélectionnée appartient à un autre agent. Une exécution cron peut être acceptée mais pas terminée. Une session peut dire complete alors que le fichier, le message, le déploiement ou tout autre délivrable manque. Le défaut pratique est d'ouvrir l'interface utilisateur officielle de contrôle via un chemin privé, de recueillir de nouvelles preuves lisibles par machine et de s'arrêter à la première couche échouée. Ne pas exposer le tableau de bord publiquement: OpenClaw le documente comme une surface d'administration avec des autorisations de chat, de configuration et d'exécution. Ouvrez l'interface utilisateur de contrôle, puis prouvez la connexion Gateway Pour une passerelle locale, le tableau de bord documenté vit à http://127.0.0.1:18789/ à moins que gateway.controlUi.basePath ne modifie le chemin. Le point d'entrée normal le plus sûr est le CLI: Sur un hôte sans tête, utilisez: Ne collez pas une URL du tableau de bord sélectionné dans un ticket, une transcription de shell, un article ou un chat. Le guide officiel du tableau de bord recommande localhost, Tailscale Serve ou un tunnel SSH et explique le jeton, le mot de passe, l'identité Tailscale et les chemins d'authentification de proxy de confiance pris en charge. Un nouveau navigateur non loopback peut également nécessiter l'association des appareils. L'échec de l'accouplement, l'échec de l'authentification et l'échec de la disponibilité sont des incidents différents; la rotation d'un jeton ne répare pas les trois. L'application de navigateur parle directement au Gateway WebSocket sur le même port. Cette architecture crée la première frontière utile: Evidence de surface: la réponse HTTP et l'application JavaScript chargée. E preuve de connexion: les RPC WebSocket authentifiés et actuels réussissent. Une coquille rendue ne prouve que le premier élément. L'interface utilisateur de contrôle peut rester visible lors d'une connexion abandonnée pendant qu'elle tente à nouveau avec le backoff. Ce comportement est utile pour un opérateur, mais cela signifie que je peux toujours voir le tableau de bord n'est pas un test de santé en direct. Demandez à la passerelle en cours d' exécution des preuves actuelles: status deep demande une sonde en direct. health json renvoie un instantané de santé lisible par machine comprenant ok , ts , durationMs , l'état du canal, la disponibilité de l'agent et un résumé de la séance de magasin. Enregistrez le timestamp avec le verdict. Un ok: true précédent sans règle de fraîcheur est un feu vert vieilli. Audit de quatre couches de preuve dans l'ordre Utilisez une règle de priorité: ne laissez jamais un succès apparenté plus tard cacher un précédent inconnu. Les quatre couches répondent à des questions différentes. Couche La question est posée Les preuves minimales Ce qu'il ne prouve pas Surface de l'interface utilisateur Le navigateur a t il reçu et exécuté l'interface utilisateur du contrôle ? Statut HTTP attendu, enregistrement de l'application, chemin de base correct L'authentification de la passerelle ou l'accessibilité de l'agent La porte d'entrée Ce navigateur est il authentifié à une passerelle en direct ? RPC de courant réussi, timestamp de santé, portée requise de l'opérateur Un agent correct, une tâche en cours ou un travail achevé Scope du travail Le point de vue est il lié à l'agent prévu, à la séance canonique et à la course attendue? Identification de l'agent, clé de session, ID d'exécution, heure de mise à jour, état, propriété attend Le livrable externe existe Le résultat L'effet ou l'artefact demandé a t il adopté sa règle d'acceptation? Réception spécifique à la destination avec vérificateur et heure Stabilité future sauf si une fenêtre est nécessaire L'ordre empêche trois erreurs courantes. Premièrement, l'activité stockée n'est pas la vitalité. Le Guide de santé OpenClaw prévient explicitement que les lignes de session proviennent de l'état de conversation stocké et ne sont pas la durée de vie des prises fournisseurs. Une séance récente est une preuve de travail utile, mais elle ne peut pas remplacer un canal ou une sonde Gateway. Deuxièmement, la portée fait partie de la santé. Les configurations de l'interface utilisateur de contrôle multi agents peuvent changer la portée de l'agent, et chaque panneau peut tenir sa propre session. Avant d'évaluer les progrès, saisissez le agentId attendu, le agentId sélectionné et le sessionKey canonique. S'ils ne sont pas d'accord, le verdict est WRONG AGENT SCOPE , pas l'agent est inactif. Cela est particulièrement important après avoir ouvert un lien profond, changé les profils de navigateur ou retourné à une vue divisée. Troisièmement, le travail accepté n'est pas un travail fini. Le Protocole de passerelle décrit le cron.run comme un style de rangement. Un client qui a besoin d'être complété doit conserver le runId retourné et l'enquête cron.runs . Le bouton fonctionnant du tableau de bord prouve donc que la demande a été acceptée, et non que l'agent isolé a terminé. Utilisez la même discipline pour attendre. Une course attend légitimement lorsque la dépendance est connue, que le propriétaire est averti, qu'un délai existe et que la session peut reprendre. Il est bloqué lorsqu'aucun progrès significatif n'est visible et qu'aucune dépendance valide n'explique la pause. Réinitialiser une attente propriétaire peut dupliquer le travail ou jeter l'état nécessaire pour continuer. Retournez la porte contre les cas inconvenients J'ai construit un petit classificateur déterministe autour de cette priorité. L'appareil contient six états délibérément différents: 1. la page chargée mais aucune RPC Gateway authentifiée n'a réussi; 2. Le Gateway dit que c'est sain, mais les preuves sont de cinq minutes. 3. la vue est fraîche, mais elle pointe vers le mauvais agent; 4. la séance prévue est attendue avec un propriétaire et une date limite; 5. la course est complète mais n'a pas de reçu de résultat; 6. la course est fraîche, bien définie, complète et accompagnée d'un reçu. Faites le avec: Le rapport fixe est le suivant: Le classificateur utilise une fenêtre de preuve de 60 secondes pour le dispositif. C'est un exemple, pas un OpenClaw par défaut universel. Une course interactive de deux minutes et un travail de recherche quotidien nécessitent des politiques d'expiration différentes. Définissez la fenêtre de la cadence de mise à jour attendue, le coût de l'exploration et le dommage d'agir sur des preuves périmées. Conservez le seuil choisi à côté du résultat. La partie importante est l'ordre: Ce script valide la forme et la priorité des preuves. Cela ne prouve pas qu'un reçu est honnête. Un reçu a besoin d'un vérificateur spécifique à la destination: hash et existence pour un fichier, vérification HTTP et de contenu pour une page, identifiant du fournisseur et état de livraison pour un message, sortie de test pour un changement de code ou requête contre le système qui possède un effet secondaire externe. Réparer la première couche ratée, pas le symptôme le plus visible Lorsque l'audit échoue, utilisez la mesure la plus étroite et la plus sûre. Le verdict Limite probable L'action suivante UI UNREACHABLE HTTP, chemin de base, paquet de navigateur ou accès à l'hôte Vérifiez l'URL et le processus Gateway documentés avant de modifier la configuration de l'agent GATEWAY UNVERIFIED Accès WebSocket, auteur, pairing ou portée Exécutez une enquête approfondie sur l'état/santé et suivez la raison exacte 1008 STALE GATEWAY EVIDENCE Une ancienne photo caché Réfléchissez; gardez le verdict inconnu jusqu'à ce que de nouvelles preuves arrivent WRONG AGENT SCOPE L'agent/session sélectionnée diffère de la tâche Résolvez l'agent canonique et la session, puis lisez à nouveau les progrès WAITING OWNED Une dépendance extérieure ou humaine valide Gardez le propriétaire, la date limite et l'état de reprise visibles OUTCOME UNVERIFIED L'exécution a pris fin avant la vérification de la destination Exécuter la vérification de l'acceptation; ne pas confirmer la finition HEALTHY Toutes les preuves requises sont fraîches et à portée de main. Conserver les timestamps, exécuter l'identité et recevoir le résultat Cette règle limite aussi l'autorité. L'interface utilisateur du contrôle peut modifier la configuration, exécuter des tâches cron, annuler des tâches et gérer les approbations. Une erreur de diagnostic n'autorise pas automatiquement ces mutations. Expliquer la couche ratée, proposer la plus petite action réversible et exiger l'approbation explicite lorsque l'action change d'état. Pour l'accès à distance, gardez intacte la limite de l'administrateur. Les docs officiels préfèrent l'accès privé via localhost, Tailscale Serve ou un tunnel SSH. Ne pas corriger l'accessibilité du tableau de bord en exposant publiquement l'interface utilisateur de contrôle ou en désactivant l'authentification de l'appareil. Une réparation de disponibilité qui affaiblit le plan de contrôle n'est pas une récupération saine. Le tableau de bord est la preuve, pas le résultat. Le modèle d'exploitation utile est désormais compact: la surface du navigateur indique si l'interface de l'opérateur est chargée; la sonde Gateway montre si les preuves du plan de contrôle sont actuelles; l'agent sélectionné, la séance et la course identifient le travail qui est jugé; le reçu de l'expérience prouve que la tâche de l'utilisateur a effectivement été terminée. Gardez ces limites même si un tableau de bord futur les combine sur un seul écran. Une seule carte peut afficher plusieurs signaux, mais elle ne doit pas réduire leur provenance ou leurs timestamps à un état vert non qualifié. Le rôle prévu de Sidewisp est une couche de santé autour d'agents qui continuent à fonctionner dans des systèmes tels que OpenClaw. Sidewisp est actuellement en préversion privée. Ses adaptateurs de surveillance de la production et son moteur de récupération ne sont généralement pas expédiés, donc cet article décrit une méthode d'opérateur et un artefact reproductible, et non une intégration automatique actuelle de Sidewisp. Si cette limite de preuve correspond aux échecs silencieux que vous devez capturer, vous pouvez rejoindre l'aperçu privé depuis le site Sidewisp. Les sources Tableau de bord OpenClaw, inspecté contre OpenClaw 2026.7.1 2 OpenClaw Interface utilisateur de commande, inspecté contre OpenClaw 2026.7.1 2 OpenClaw Contrôles de santé, inspecté contre OpenClaw 2026.7.1 2 Le protocole de passerelle OpenClaw, inspecté contre OpenClaw 2026.7.1 2 Tableau de bord OpenClaw CLI, inspecté contre OpenClaw 2026.7.1 2