OpenClaw-Dashboard: Überprüfen Sie vier Schichten, bevor Sie sich auf Grün verlassen

Die kurze Antwort lautet: Ein OpenClaw Dashboard , das geladen wird, ist noch kein Beweis dafür, dass ein Agent gesund ist. Behandeln Sie die Control UI als vier separate Kontrollen: die Browseroberfläche ist geladen, das Gateway akzeptiert eine authentifizierte WebSocket Verbindung, das Dashboard zeigt den beabsichtigten Agent und den aktuellen Auslauf an, und das versprochene Ergebnis existiert. Nur die letzte Bedingung schließt die Aufgabe. Diese Unterscheidung ist wichtig, weil jede Schicht grün sein kann, während die nächste gebrochen ist. Statische Assets können während der WebSocket ist getrennt renderen. Ein Gateway kann antworten, während die gewählte Sitzung einem anderen Agenten gehört. Ein Cron Run kann akzeptiert werden, aber nicht abgeschlossen. Eine Sitzung kann complete sagen, während die Datei, die Nachricht, die Bereitstellung oder andere Lieferwerte fehlen. Die praktische Standardfunktion besteht darin, die offizielle Control UI über einen privaten Pfad zu öffnen, neue maschinenlesbare Beweise zu sammeln und bei der ersten fehlgeschlagenen Schicht zu stoppen. Das Dashboard darf nicht öffentlich dargestellt werden: OpenClaw dokumentiert es als Admin Oberfläche mit Chat , Konfigurations und Ausführungsgenehmigungen. Öffnen Sie die Control UI, dann beweisen Sie die Gateway Verbindung Für ein lokales Gateway lebt das dokumentierte Dashboard bei http://127.0.0.1:18789/ , es sei denn, gateway.controlUi.basePath ändert den Pfad. Der sicherste normale Eingangspunkt ist die CLI: Bei einem Kopflosen Gastgeber verwenden Sie: Kleben Sie keine gekennzeichnete Dashboard URL in ein Ticket, ein Shell Transcript, einen Artikel oder einen Chat. Das offizieller Leitfaden für das Dashboard empfiehlt Localhost, Tailscale Serve oder einen SSH Tunnel und erklärt das unterstützte Token, das Passwort, die Tailscale Identität und die vertrauenswürdigen Proxy Authentifizierungswege. Ein neuer nicht loopback Browser kann auch das Paarung von Geräten erfordern. Pairing Fehler, Authentifizierungs Fehler und Reachability Fehler sind unterschiedliche Vorfälle; das Drehen eines Tokens repariert nicht alle drei. Die Browser Anwendung spricht direkt mit dem Gateway WebSocket auf demselben Port. Diese Architektur schafft die erste nützliche Grenze: Oberflächennachweis: die HTTP Antwort und JavaScript Anwendung geladen. Verbindung Beweise: Die WebSocket authentifizierten und aktuellen RPCs gelingen. Eine Rendered Schale beweist nur das erste Element. Die Control UI kann während einer abgebrochenen Verbindung sichtbar bleiben, während sie mit Backkoff erneut versucht. Dieses Verhalten ist für einen Betreiber hilfreich, aber es bedeutet, dass ich das Dashboard noch sehe. Es ist kein Live Gesundheitstest. Fragen Sie stattdessen das laufende Gateway nach aktuellen Beweisen: status deep verlangt eine Live Sonde. health json gibt einen maschinenlesbaren Gesundheits Snapshot zurück, der ok , ts , durationMs , Kanalzustand, Agentverfügbarkeit und eine Zusammenfassung der Sitzung Store enthält. Zeichnen Sie das Zeitstempel mit dem Urteil auf. Ein früherer ok: true ohne Frischheitsregel ist ein veraltetes grünes Licht. Prüfung von vier Beweislagen in Reihenfolge Verwenden Sie eine Vorrangsregel: Lassen Sie niemals einen späteren Erfolg einen früheren Unbekannten verbergen. Die vier Schichten beantworten unterschiedliche Fragen. Schicht Die Frage Mindestbeweise Was sie nicht beweist Oberfläche der Benutzeroberfläche Hat der Browser die Control UI empfangen und ausgeführt? Erwarteter HTTP Status, Anwendungsregistrierung, korrekter Basisweg Gateway Authentifizierung oder Zugänglichkeit des Agenten Das Tor Ist dieser Browser jetzt auf ein Live Gateway authentifiziert? Erfolgreiche aktuelle RPC, Gesundheitszeitstempel, erforderlicher Betreiberbereich Richtige Agentin, aktuelle Aufgabe oder abgeschlossene Arbeit Arbeitsumfang Ist die Ansicht mit dem beabsichtigten Agenten, der kanonischen Sitzung und dem erwarteten Lauf verbunden? Agent ID, Sitzungsschlüssel, Ausführungs ID, Aktualisierungszeit, Zustand, Eigentümer warten Das externe Lieferwert existiert Ergebnis Hat der gewünschte Effekt oder das gewünschte Artefakt seine Annahmeregel überstanden? Bestimmungsortbezogene Quittung mit Prüfer und Uhrzeit Zukunftsstabilität, es sei denn, ein Fenster ist erforderlich Der Befehl verhindert drei häufige Fehler. Erstens ist die gespeicherte Aktivität keine Lebenskraft. Die OpenClaw Gesundheitsleitfaden warnt explizit, dass Sitzung Reihen aus gespeichertem Gespräch Zustand kommen und nicht Provider Socket Livität sind. Eine kürzlich aussehende Sitzung ist nützlich als Arbeitsnachweis, kann aber keine Kanal oder Gateway Sonde ersetzen. Zweitens ist die Reichweite Teil der Gesundheit. Multi Agent Control UI Setups können Agentenbereich wechseln, und jedes Fenster kann seine eigene Sitzung halten. Bevor Sie den Fortschritt beurteilen, erfassen Sie die erwartete agentId , die ausgewählte agentId und die kanonische sessionKey . Wenn sie nicht einverstanden sind, ist das Urteil WRONG AGENT SCOPE , nicht der Agent ist leere. Dies ist besonders wichtig, nachdem Sie einen tiefen Link öffnen, Browserprofile ändern oder zu einer Split Ansicht zurückkehren. Drittens ist eine akzeptierte Arbeit nicht abgeschlossen. Die Gateway Protokoll beschreibt die cron.run als Quellen Stil. Ein Kunde, der eine Vollendung benötigt, muss die zurückgegebene runId behalten und die cron.runs abfragen. Die Funktionsschaltfläche des Dashboards beweist daher, dass eine Anfrage angenommen wurde, nicht, dass der isolierte Agent abgeschlossen ist. Verwenden Sie die gleiche Disziplin beim Warten. Ein Lauf wartet legitim, wenn die Abhängigkeit bekannt ist, der richtige Eigentümer benachrichtigt wurde, eine Frist besteht und die Sitzung wieder aufgenommen werden kann. Es steckt fest, wenn kein bedeutender Fortschritt sichtbar ist und keine gültige Abhängigkeit die Pause erklärt. Wenn man eine eigene Wartezeit wieder aufnimmt, kann die Arbeit doppelt erfolgen oder der Zustand, der für die Weiterführung erforderlich ist, verworfen werden. Wiederholen Sie das Tor gegen unangenehme Fälle Ich baute einen kleinen deterministischen Klassifikator um diese Präzedenzlage herum. Das Gerät enthält sechs absichtlich unterschiedliche Zustände: 1. die geladene Seite, aber kein authentifizierter Gateway RPC erfolgte; 2. Das Gateway sagt gesund, aber seine Beweise sind fünf Minuten alt. 3. die Sicht ist frisch, zeigt aber auf den falschen Agenten; 4. die geplante Sitzung mit einem Eigentümer und einer Frist wartet; 5. der Lauf sagt abgeschlossen, hat aber keine Ergebnisbestätigung; 6. Der Lauf ist frisch, korrekt ausgelegt, vollständig und mit einer Quittung beglaubigt. Führen Sie es mit: Der feste Bericht lautet: Der Klassifizierer verwendet ein 60 Sekunden Beweisfenster für das Gerät. Das ist ein Beispiel, nicht ein universelles OpenClaw Standard. Ein zwei minütiger interaktiver Lauf und eine tägliche Forschungsarbeit benötigen unterschiedliche Verfallsrichtlinien. Setzen Sie das Fenster von der erwarteten Aktualisierungsrate, den Kosten der Untersuchung und den Schaden, wenn Sie auf veraltete Beweise reagieren. Bewahren Sie die gewählte Schwelle neben dem Ergebnis. Der wichtige Teil ist die Reihenfolge: Dieses Skript bestätigt die Form und Vorrang der Beweise. Es beweist nicht, dass ein Quittung ehrlich ist. Eine Quittung benötigt einen zielgerichteten Verifikator: Hash und Existenz für eine Datei, HTTP und Inhaltskontrollen für eine Seite, Provider ID und Lieferzustand für eine Nachricht, Testleistung für eine Codeänderung oder eine Abfrage gegen das System, das einen externen Nebeneffekt besitzt. Reparieren Sie die erste fehlerhafte Schicht, nicht das sichtbarste Symptom Wenn die Prüfung scheitert, nutzen Sie die engste sichere Maßnahme. Urteil Wahrscheinliche Grenze Nächste Aktion UI UNREACHABLE HTTP, Basis Pfad, Browser Bundel oder Host Zugriff Überprüfen Sie den dokumentierten URL und Gateway Prozess, bevor Sie die Agentenkonfiguration ändern GATEWAY UNVERIFIED WebSocket erreichbarkeit, auth, pairing oder umfang Führen Sie einen tiefen Status/Gesundheits Sond durch und folgen Sie dem genauen Grund 1008 STALE GATEWAY EVIDENCE Altes Cache Snapshot Erfrischen; halten Sie das Urteil unbekannt, bis neue Beweise kommen WRONG AGENT SCOPE Der ausgewählte Agent/Sitzung unterscheidet sich von der Aufgabe Löschen Sie den kanonischen Agent und die Sitzung, dann lesen Sie den Fortschritt erneut WAITING OWNED Gültige externe oder menschliche Abhängigkeit Halten Sie den Eigentümer, die Frist und den Status sichtbar OUTCOME UNVERIFIED Die Ausführung wurde vor der Bestimmungsortüberprüfung beendet Durchführen Sie die Akzeptanzprüfung; nicht abschließen HEALTHY Alle erforderlichen Beweise sind frisch und eingehend. Zeitstempeln aufbewahren, Identität ausführen und das Ergebnisreceit erhalten Diese Regel begrenzt auch die Autorität. Die Control UI kann Konfiguration bearbeiten, Cron Aufgaben ausführen, Aufgaben stornieren und Genehmigungen verwalten. Eine Diagnosefehler erlaubt diese Mutationen nicht automatisch. Erklären Sie die fehlgeschlagenen Schichten, schlagen Sie die kleinste reversible Aktion vor und verlangen Sie eine ausdrückliche Genehmigung, wenn die Aktion den Zustand ändert. Für Fernzugriff, halten Sie die Grenze der Administratorin intakt. Die offiziellen Dokumente bevorzugen privaten Zugang über Localhost, Tailscale Serve oder einen SSH Tunnel. Nicht fix Dashboard Reichbarkeit durch öffentliche Aufdeckung der Control UI oder Deaktivierung der Geräte Authentifizierung. Eine Verfügbarkeitsreparatur, die die Steuerungsschicht schwächt, ist keine gesunde Erholung. Das Dashboard ist ein Beweis, nicht das Ergebnis. Das nützliche Betriebsmodell ist nun kompakt: die Browseroberfläche zeigt an, ob die Bedieneroberfläche geladen ist; die Gateway Sonde zeigt an, ob die Kontrollflächenbeweise aktuell sind; die ausgewählte Agentin, die Sitzung und die Durchführung identifizieren die beurteilte Arbeit; Die Ergebnisbestätigung beweist, ob die Aufgabe des Benutzers tatsächlich abgeschlossen ist. Bewahren Sie diese Grenzen, auch wenn ein künftiger Dashboard sie auf einem Bildschirm kombiniert. Eine einzelne Karte kann mehrere Signale anzeigen, sollte jedoch ihre Herkunft oder Zeitstempel nicht in einen unqualifizierten grünen Zustand zusammenbrechen. Die beabsichtigte Rolle von Sidewisp ist eine gesundheitliche Schicht um Agente, die weiterhin in Systemen wie OpenClaw laufen. Sidewisp befindet sich derzeit in einer privaten Vorschauphase. Die Produktionsüberwachungsadapter und die Wiederherstellungsmotor werden im Allgemeinen nicht versandt, daher beschreibt dieser Artikel eine Betriebsmethode und ein reproduzierbares Artefakt, nicht eine aktuelle automatisierte Sidewisp Integration. Wenn diese Beweisgrenze den stillen Fehlern entspricht, die Sie fangen müssen, können Sie sich der privaten Vorschau von der Sidewisp Website anschließen. Quellen OpenClaw Dashboard, gegen OpenClaw 2026.7.1 2 geprüft OpenClaw Steuerungsschnittstelle, gegen OpenClaw 2026.7.1 2 geprüft OpenClaw Gesundheitskontrollen, gegen OpenClaw 2026.7.1 2 geprüft OpenClaw Gateway Protokoll, gegen OpenClaw 2026.7.1 2 geprüft OpenClaw Dashboard CLI, gegen OpenClaw 2026.7.1 2 geprüft