OpenClaw Dashboard: Auditar cuatro capas antes de confiar en el verde

La respuesta corta es: un panel OpenClawZ que carga aún no es evidencia de que un agente sea saludable. Trate la interfaz de usuario de control como cuatro controles separados: la superficie del navegador está cargada, la puerta de entrada aceptó una conexión WebSocket autenticada, el panel de control muestra el agente previsto y la ejecución actual, y el resultado prometido existe. Sólo la última condición cierra la tarea. Esa distinción es importante porque cada capa puede ser verde mientras que la siguiente se rompe. Los activos estáticos pueden renderizar mientras el WebSocket está desconectado. Una puerta de entrada puede responder mientras la sesión seleccionada pertenece a otro agente. Una ejecución cron puede ser aceptada pero no terminada. Una sesión puede decir complete mientras el archivo, mensaje, implementación u otro entregable falta. El defecto práctico es abrir la interfaz de control oficial a través de un camino privado, recopilar evidencia nueva legible por máquina y detenerse en la primera capa fallida. No exponga el panel de control públicamente: OpenClaw lo documenta como una superficie de administración con chat, configuración y aprobaciones de ejecución. Abre la interfaz de usuario de control, luego prueba la conexión Gateway Para una puerta de entrada local, el panel documentado vive en http://127.0.0.1:18789/ a menos que gateway.controlUi.basePath cambie la ruta. El punto de entrada normal más seguro es el CLI: En un anfitrión sin cabeza, utilice: No pongan una URL del tablero de instrumentos tokenizado en un boleto, una transcripción de shell, un artículo o un chat. El Guía oficial del tablero de instrumentos recomienda localhost, Tailscale Serve o un túnel SSH y explica el token, contraseña, identidad de Tailscale y caminos de autenticación de proxy de confianza. Un nuevo navegador no loopback también puede requerir el emparejamiento de dispositivos. El fracaso de emparejamiento, el fracaso de autenticación y el fracaso de accesibilidad son diferentes incidentes; girar un token no repara los tres. La aplicación del navegador habla directamente con el Gateway WebSocket en el mismo puerto. Esa arquitectura crea el primer límite útil: Prueba de superficie: la respuesta HTTP y la aplicación JavaScript cargada. Prueba de conexión: las RPCs WebSocket autenticadas y actuales tienen éxito. Una cáscara renderizada prueba sólo el primer artículo. La interfaz de usuario de control puede permanecer visible durante una conexión caída mientras se retoma con retroceso. Ese comportamiento es útil para un operador, pero significa que todavía puedo ver el tablero no es una prueba de salud en vivo. Pregunte a la puerta de entrada en funcionamiento por la evidencia actual en su lugar: status deep solicita una sonda en vivo. health json devuelve una instantánea de salud legible por máquina que incluye ok , ts , durationMs , estado del canal, disponibilidad del agente y un resumen de la sesión de la tienda. Graba el sello de tiempo con el veredicto. Un ok: true anterior sin una regla de frescura es una luz verde obsoleta. Auditoría de cuatro capas de pruebas en orden Utilice una regla de prioridad: nunca deje que un éxito que parece más tarde oculte un desconocido antes. Las cuatro capas responden a preguntas diferentes. Capa Pregunta de la Comisión Evidencias mínimas Lo que no demuestra Superficie de la interfaz de usuario ¿El navegador recibió y ejecutó la interfaz de control? Estatus HTTP esperado, registro de la aplicación, recorrido de base correcto Autenticación de la puerta de entrada o accesibilidad del agente Puerta de entrada ¿Este navegador está autenticado a una puerta de entrada en vivo ahora? RPC de corriente exitosa, sello de tiempo de salud, alcance requerido del operador Agente correcto, tarea actual o trabajo terminado Capacidad de trabajo ¿Está el punto de vista vinculado al agente previsto, la sesión canónica y la carrera esperada? Identificación del agente, llave de sesión, ID de ejecución, tiempo de actualización, estado, propiedad espera Existe el producto externo El resultado ¿El efecto o artefacto solicitado ha aprobado su regla de aceptación? Recibo específico de destino con verificador y hora Estabilidad futura a menos que se requiera una ventana La orden evita tres errores comunes. En primer lugar, la actividad almacenada no es vitalidad. El Guía de salud OpenClaw advierte explícitamente que las filas de sesión provienen del estado de conversación almacenado y no son la vida del socket del proveedor. Una sesión de aspecto reciente es una prueba de trabajo útil, pero no puede reemplazar a un canal o una sonda Gateway. En segundo lugar, el alcance es parte de la salud. Las configuraciones de interfaz de control multi agente pueden cambiar el alcance del agente, y cada panel puede mantener su propia sesión. Antes de juzgar el progreso, captura el agentId esperado, el agentId seleccionado y el sessionKey canónico. Si no están de acuerdo, el veredicto es WRONG AGENT SCOPE , no el agente está inactivo. Esto es especialmente importante después de abrir un enlace profundo, cambiar perfiles de navegador o volver a una vista dividida. En tercer lugar, el trabajo aceptado no es un trabajo terminado. El Protocolo de puerta de entrada describe a cron.run como un estilo de cola. Un cliente que necesite completar debe guardar el runId devuelto y la encuesta cron.runs . El botón del tablero de control que funciona demuestra, por tanto, que se ha aceptado una solicitud, no que el agente aislado ha terminado. Usa la misma disciplina para esperar. Una carrera está legítimamente esperando cuando se conoce la dependencia, se ha notificado al propietario adecuado, existe un plazo, y la sesión puede reanudarse. Se queda atascado cuando no se ve ningún progreso significativo y ninguna dependencia válida explica la pausa. Reiniciar una espera de propiedad puede duplicar el trabajo o descartar el estado necesario para continuar. Repite la puerta contra casos incómodos Construí un pequeño clasificador determinista alrededor de esta prioridad. El dispositivo contiene seis estados deliberadamente diferentes: 1. la página se cargó, pero no se logró el RPC de Gateway autenticado; 2. La puerta dice que es saludable, pero su evidencia es de cinco minutos. 3. la vista es fresca pero apunta al agente equivocado; 4. la sesión prevista está esperando con un propietario y fecha límite; 5. la carrera dice que está completa pero no tiene recibo de resultado; 6. la carrera es nueva, correctamente definida, completa y respaldada por un recibo. Ejecutar con: El informe fijo es: El clasificador utiliza una ventana de pruebas de 60 segundos para el dispositivo. Ese es un ejemplo, no un OpenClaw por defecto universal. Una carrera interactiva de dos minutos y un trabajo diario de investigación requieren diferentes políticas de vencimiento. Establezca la ventana de la cadencia de actualización esperada, el costo de la investigación y el daño de actuar sobre evidencia obsoleta. Guarde el umbral elegido junto al resultado. La parte importante es el ordenamiento: Este guión valida la forma y la prioridad de la evidencia. No demuestra que un recibo sea honesto. Un recibo necesita un verificador específico de destino: hash y existencia de un archivo, comprobadores HTTP y de contenido de una página, ID del proveedor y estado de entrega de un mensaje, salida de prueba para un cambio de código o una consulta contra el sistema que posee un efecto secundario externo. Repara la primera capa fallida, no el síntoma más visible Cuando la auditoría falla, utilice la medida más segura. El veredicto Limitación probable La siguiente acción UI UNREACHABLE HTTP, ruta base, paquete de navegador o acceso al host Verifique la URL documentada y el proceso de Gateway antes de cambiar la configuración del agente GATEWAY UNVERIFIED Accesibilidad, autor, emparejamiento o alcance de WebSocket Realice una sonda profunda de estado / salud y siga la razón exacta 1008 STALE GATEWAY EVIDENCE Vieja instantánea almacenada en caché Refrescar; mantener el veredicto desconocido hasta que llegue nueva evidencia WRONG AGENT SCOPE El agente/sesión seleccionado difiere de la tarea Resolver el agente canónico y la sesión, luego volver a leer el progreso WAITING OWNED Dependencia externa o humana válida Mantenga visible el propietario, la fecha límite y el estado de reanudación OUTCOME UNVERIFIED La ejecución terminó antes de la verificación del destino Ejecutar la verificación de aceptación; no aclarar la finalización HEALTHY Todas las pruebas requeridas son frescas y de alcance Mantener sellos de tiempo, ejecutar la identidad y el recibo del resultado Esta regla también limita la autoridad. La interfaz de usuario de control puede editar configuración, ejecutar trabajos cron, cancelar tareas y administrar aprobaciones. Un fallo en el diagnóstico no autoriza automáticamente esas mutaciones. Explicar la capa fallida, proponer la acción más pequeña reversible y requerir la aprobación explícita cuando el estado de cambio de acción. Para el acceso remoto, mantenga intacto el límite del administrador. Los documentos oficiales prefieren el acceso privado a través de localhost, Tailscale Serve o un túnel SSH. No fije la accesibilidad del panel de control exponiendo públicamente la interfaz de usuario de control o desactivando la autenticación del dispositivo. Una reparación de disponibilidad que debilita el plano de control no es una recuperación saludable. El tablero es evidencia, no el resultado. El modelo de operación útil es ahora compacto: la superficie del navegador muestra si la interfaz del operador está cargada; la sonda Gateway muestra si la evidencia del plano de control es actual; el agente seleccionado, la sesión y la ejecución identifican el trabajo que se juzga; el recibo del resultado demuestra si la tarea del usuario se ha completado efectivamente. Mantenga esos límites incluso si un futuro tablero los combina en una pantalla. Una sola tarjeta puede mostrar varias señales, pero no debe desmoronar su procedencia o timestamps en un estado verde no calificado. El papel previsto de Sidewisp es una capa de salud alrededor de agentes que continúan funcionando en sistemas como OpenClaw. Sidewisp se encuentra actualmente en versión preliminar privada. Sus adaptadores de monitoreo de producción y motor de recuperación no se envían generalmente, por lo que este artículo describe un método de operador y un artefacto reproducible, no una integración automática actual de Sidewisp. Si este límite de pruebas coincide con los fallos silenciosos que necesita capturar, puede unirse a la vista previa privada desde el sitio Sidewisp. Fuentes Tabla de control OpenClaw, inspeccionado contra OpenClaw 2026.7.1 2 OpenClaw Interfaz de control, inspeccionado contra OpenClaw 2026.7.1 2 OpenClaw Control de salud, inspeccionado contra OpenClaw 2026.7.1 2 Protocolo de entrada OpenClaw, inspeccionado contra OpenClaw 2026.7.1 2 OpenClaw Panel de control CLI, inspeccionado contra OpenClaw 2026.7.1 2