2026-08-01T05:02:04.315Z
OpenClaw Dashboard: Audit quattro strati prima di fidarsi di Green
Separare la superficie dell'interfaccia utente di controllo, il gateway autenticato, l'agente selezionato e l'esecuzione, e verificare il risultato con un riproducibile audit sanitario di sei casi.
La risposta corta è: un dashboard OpenClawZ che carica non è ancora prova che un agente sia sano. Trattare l'interfaccia utente Control come quattro controlli separati: la superficie del browser caricata, il Gateway ha accettato una connessione WebSocket autenticata, la dashboard mostra l'agente previsto e l'esecuzione corrente, e il risultato promesso esiste. Solo l'ultima condizione chiude il compito. Questa distinzione è importante perché ogni strato può essere verde mentre l'altro è rotto. Le risorse statiche possono renderare mentre il WebSocket è disconnesso. Un Gateway può rispondere mentre la sessione selezionata appartiene ad un altro agente. Una cron run può essere accettata ma non terminata. Una sessione può dire complete mentre manca il file, il messaggio, la distribuzione o altri risultati. Il default pratico è aprire l'interfaccia utente ufficiale di controllo attraverso un percorso privato, raccogliere nuove prove leggibili dalla macchina e fermarsi al primo livello fallito. Non esporre pubblicamente il pannello di controllo: OpenClaw lo documenta come superficie di amministrazione con chat, configurazione e approvazioni di esecuzione. Apri l'interfaccia utente Control, poi prova la connessione Gateway Per un Gateway locale, la scheda di controllo documentata vive a http://127.0.0.1:18789/ a meno che gateway.controlUi.basePath non cambie il percorso. Il punto di ingresso normale più sicuro è il CLI: Su un ospite senza testa, utilizzare: Non incollare un'URL del dashboard con token in un biglietto, una trascrizione di shell, un articolo o una chat. Il guida ufficiale del cruscotto raccomanda localhost, Tailscale Serve o un tunnel SSH e spiega il token supportato, la password, l'identità Tailscale e i percorsi di autenticazione trusted proxy. Un nuovo browser non loopback può richiedere anche l'appariamento dei dispositivi. Il fallimento dell'accoppiamento, il fallimento dell'autenticazione e il fallimento di accessibilità sono incidenti diversi; ruotare un token non risolve tutti e tre. L'applicazione del browser parla direttamente al Gateway WebSocket sulla stessa porta. Questa architettura crea il primo confine utile: Evidenza di superficie: la risposta HTTP e l'applicazione JavaScript caricata. Dodice di connessione: i RPC WebSocket autenticati e attuali hanno successo. Una conchiglia resa prova solo il primo elemento. L'interfaccia utente di controllo può rimanere visibile durante una connessione abbandonata mentre riprova con backkoff. Questo comportamento e' utile per un operatore, ma significa che posso ancora vedere che il cruscotto non e' un test di salute in diretta. Chiedi al Gateway in esecuzione le prove attuali: status deep richiede una sonda in diretta. health json restituisce un'istantanea di salute leggibile dalla macchina che include ok , ts , durationMs , stato del canale, disponibilità dell'agente e un riassunto delle sessioni. Registrate il timestamp con il verdetto. Una precedente ok: true senza regola di freschezza è una luce verde obsoleta. Audito di quattro strati di prove in ordine Utilizzare una regola di priorità: non lasciare mai che un successo che sembra più tardi nasconda un precedente sconosciuto. I quattro strati rispondono a domande diverse. Strato Interrogazione Minime prove Cosa non dimostra Superficie dell'interfaccia utente Il browser ha ricevuto e eseguito l'interfaccia utente Control? Lo stato HTTP previsto, la registrazione dell'applicazione, il percorso di base corretto Autenticazione del gateway o accessibilità dell'agente Portata Questo browser e' autenticato a un Gateway in diretta ora? RPC di corrente di successo, timestamp sanitario, ambito operativo richiesto Agente corretto, attività attuale o lavoro completato Portata di lavoro La visione è legata all'agente previsto, alla sessione canonica e alla corsa prevista? Identificazione dell'agente, chiave di sessione, ID di esecuzione, tempo di aggiornamento, stato, proprietà aspettare Il consegnabile esterno esiste Risultato L'effetto o l'artefatto richiesto ha superato la sua regola di accettazione? Risultato specifico della destinazione con verificatore e orario Stabilità futura a meno che non sia necessaria una finestra L'ordine previene tre errori comuni. In primo luogo, l'attività immagazzinata non è vitalità. La Guida sanitaria OpenClaw avverte esplicitamente che le righe di sessione provengono dallo stato di conversazione memorizzato e non sono la vita di socket del provider. Una sessione di aspetto recente è una prova utile del lavoro, ma non può sostituire un canale o una sonda Gateway. In secondo luogo, la portata fa parte della salute. Le impostazioni multi agente Control UI possono cambiare la portata dell'agente, e ogni pannello può tenere la propria sessione. Prima di valutare il progresso, catturare il previsto agentId , il selezionato agentId e il canonico sessionKey . Se non sono d'accordo, il verdetto è WRONG AGENT SCOPE , non l'agente è inattivo. Questo è particolarmente importante dopo aver aperto un collegamento profondo, modificato i profili del browser o tornato a una visualizzazione divisa. In terzo luogo, il lavoro accettato non è un lavoro finito. La Protocollo Gateway descrive la cron.run come uno stile di coda. Un cliente che ha bisogno di completare deve mantenere la runId restituita e il sondaggio cron.runs . Il pulsante del cruscotto funzionante dimostra quindi che una richiesta è stata accettata, non che l'agente isolato è finito. Usa la stessa disciplina per aspettare. Una corsa è legittimamente in attesa quando la dipendenza è conosciuta, il proprietario giusto è stato notificato, esiste una scadenza e la sessione può riprendere. Si blocca quando non si vede alcun progresso significativo e nessuna valida dipendenza spiega la pausa. Riprendere un'attesa di proprietà può duplicare il lavoro o scartare lo stato necessario per continuare. Riproduci il cancello contro casi scomodi Ho costruito un piccolo classificatore deterministico intorno a questa priorità. Il dispositivo contiene sei stati deliberatamente diversi: 1. la pagina caricata ma nessun RPC Gateway autenticato è riuscito; 2. Il Gateway dice che e' sano, ma le sue prove sono di cinque minuti. 3. la vista è fresca ma indica l'agente sbagliato; 4. la sessione prevista è in attesa con un proprietario e una scadenza; 5. la corsa dice completa ma non ha ricevuta di risultato; 6. la corsa è fresca, corretto, completa e corroborata da una ricevuta. Fate partire con: La relazione fissa è: Il classificatore utilizza una finestra di prova di 60 secondi per il dispositivo. Questo è un esempio, non un default universale OpenClaw. Una corsa interattiva di due minuti e un lavoro di ricerca giornaliero richiedono politiche di scadenza diverse. Imposta la finestra sulla cadenza di aggiornamento prevista, il costo della sonda e il danno di agire su prove obsolete. Conservare la soglia scelta accanto al risultato. La parte importante è l'ordine: Questa sceneggiatura convalida la forma e la priorità delle prove. Non dimostra che una ricevuta sia onesta. Una ricevuta ha bisogno di un verificatore specifico per la destinazione: hash e esistenza per un file, controlli HTTP e contenuti per una pagina, ID del provider e stato di consegna per un messaggio, uscita di test per una modifica di codice o una query contro il sistema che possiede un effetto collaterale esterno. Ripara il primo strato fallito, non il sintomo più visibile Quando l'audit fallisce, usi le misure di sicurezza più restrittive. Verdicto Limitazione probabile Azione successiva UI UNREACHABLE HTTP, percorso base, bundle browser o accesso host Verificare l'URL documentato e il processo Gateway prima di cambiare la configurazione dell'agente GATEWAY UNVERIFIED Accessibilità, autore, abbinamento o portata di WebSocket Eseguire una sonda profonda di stato/sanità e seguire l'esatta ragione 1008 STALE GATEWAY EVIDENCE Una vecchia immagine in cache Raggiornare; mantenere il verdetto sconosciuto fino all'arrivo di nuove prove WRONG AGENT SCOPE L'agente/sessione selezionata differisce dal compito Risolvere l'agente canonico e la sessione, poi rileggere il progresso WAITING OWNED Valida dipendenza esterna o umana Tenere visibile il proprietario, la scadenza e riprendere lo stato OUTCOME UNVERIFIED L'esecuzione è terminata prima della verifica della destinazione Eseguire il controllo di accettazione; non accertare il completamento HEALTHY Tutte le prove richieste sono fresche e scoperte Conservazione dei timestamp, esecuzione dell'identità e ricevimento del risultato Questa regola limita anche l'autorità. L'interfaccia utente Control può modificare la configurazione, eseguire lavori cron, annullare le attività e gestire le approvazioni. Un fallimento diagnostico non autorizza automaticamente queste mutazioni. Spiegare il livello fallito, proporre la più piccola azione reversibile e richiedere l'approvazione esplicita quando l'azione cambia stato. Per l'accesso remoto, mantenete intatto il confine dell'amministratore. I documenti ufficiali preferiscono l'accesso privato tramite localhost, Tailscale Serve o un tunnel SSH. Non correggere l'accessibilità della scheda di controllo esponendo pubblicamente l'interfaccia utente di controllo o disattivando l'autenticazione del dispositivo. Una riparazione di disponibilità che indebolisce il piano di controllo non è un recupero sano. Il cruscotto è la prova, non il risultato. Il modello operativo utile è ora compatto: la superficie del browser mostra se l'interfaccia dell'operatore è caricata; la sonda Gateway mostra se le prove del piano di controllo sono attuali; l'agente selezionato, la sessione e la corsa identificano il lavoro da giudicare; la ricevuta del risultato dimostra se l'utente ha effettivamente completato il compito. Tenete questi confini anche se un futuro dashboard li unisce su uno schermo. Una singola carta può visualizzare diversi segnali, ma non dovrebbe far crollare la loro provenienza o i timestamp in un unico stato verde non qualificato. Il ruolo previsto di Sidewisp è uno strato di salute attorno agli agenti che continuano a funzionare in sistemi come OpenClaw. Sidewisp è attualmente in anteprima privata. Gli adattatori di monitoraggio della produzione e il motore di recupero non sono generalmente spediti, quindi questo articolo descrive un metodo operatore e un artefatto riproducibile, non una corrente integrazione automatizzata Sidewisp. Se questo limite di prove corrisponde ai fallimenti silenziosi che devi catturare, puoi unirti alla visualizzazione privata dal sito Sidewisp. Fonti Dispositivo di controllo OpenClaw, ispezionato contro OpenClaw 2026.7.1 2 OpenClaw UI di controllo, ispezionato contro OpenClaw 2026.7.1 2 Controlli sanitari OpenClaw, ispezionato contro OpenClaw 2026.7.1 2 Protocollo di ingresso OpenClaw, ispezionato contro OpenClaw 2026.7.1 2 OpenClaw Tabella di controllo CLI, ispezionato contro OpenClaw 2026.7.1 2