Volevo un dashboard che mostrasse cosa stanno facendo i miei agenti IA. Non un monitoraggio di livello Grafana con metriche e avvisi — ho già quello. Volevo qualcosa che potessi consultare a colpo d’occhio sul mio telefono e sapere: quali agenti sono attivi, su cosa stanno lavorando, quanto hanno speso oggi e se qualcosa richiede la mia attenzione.
Così ne ho costruito uno in React. Un’applicazione a pagina singola che si connette ai dati di OpenClaw e li mostra in un dashboard chiaro e ottimizzato per mobile. Mi ci è voluto un weekend per codificarlo ed è diventato la prima cosa che controllo ogni mattina.
Cosa mostra il dashboard
Pannello 1: Stato degli agenti
Una lista di tutti gli agenti configurati con il loro stato attuale: attivo (verde), inattivo (giallo), errore (rosso). Ogni agente mostra l’ora della sua ultima attività e una descrizione in una riga di cosa ha fatto di recente. Vedo a colpo d’occhio che l’agente di briefing mattutino è partito alle 8, che l’agente di monitoraggio ha controllato i server alle 8:15, e che l’agente email è inattivo in attesa di nuovi messaggi.
Pannello 2: Attività del giorno
Una vista cronologica di tutte le azioni degli agenti oggi. Codificata a colori a seconda del tipo: blu per le chiamate ai modelli IA, verde per le esecuzioni degli strumenti, arancione per le interazioni degli utenti, rosso per gli errori. Scorrevole. Mostra le attività più recenti per prime.
È qui che scopro i problemi. Un raggruppamento di voci rosse significa che si sta ripetendo un errore. Un’assenza nella timeline indica che un lavoro atteso non si è verificato. Una barra blu anormalmente lunga significa che una chiamata API ha impiegato molto più tempo del solito.
Pannello 3: Monitoraggio dei costi
Il totale accumulato di oggi, confrontato con la media giornaliera. Dettagliato per modello e per agente. Un mini grafico a barre mostra gli ultimi 7 giorni per confrontare le tendenze.
Pannello 4: Azioni richieste
Elementi che richiedono il mio intervento: bozze di email in attesa di approvazione, contenuti segnalati in moderazione, attività fallite da rivedere, avvisi di budget. Ogni elemento ha un pulsante di azione: approva, rifiuta o vedi i dettagli.
Questo pannello è il cuore del dashboard. Tutto il resto è informativo, questo è interattivo.
La stack tecnica
Frontend: React con Vite. Nessuna libreria di componenti — solo CSS puro con flexbox/grid. Il pacchetto totale è inferiore a 200KB. Caricamento istantaneo, anche in 4G su mobile.
Fonte dei dati: file di log di OpenClaw, analizzati e serviti da una leggera API Express. L’API legge i log, estrae i dati pertinenti e li fornisce in JSON. Circa 200 righe di codice.
Hosting: Sulla stessa macchina di OpenClaw. La compilazione React produce file statici serviti dall’API Express. Non è necessario un server web separato.
Autenticazione: Auth di base con un solo ID/password. Non è un’applicazione multiutente — è il mio dashboard personale. Un’autenticazione semplice è sufficiente.
Costruire il layer dei dati
La parte più difficile non è stata il frontend React, ma estrarre dati puliti da OpenClaw.
I log di OpenClaw sono testo semi-strutturato. Ho scritto un parser che estrae:
– I timestamp di tutti gli eventi
– Il numero di token delle chiamate API
– I nomi degli strumenti e il loro tempo di esecuzione
– I messaggi di errore e gli stack trace
– Gli identificativi di sessione per raggruppare eventi correlati
Il parser viene eseguito ogni 30 secondi, elabora le nuove voci del log e memorizza i dati estratti in un database SQLite. L’API interroga SQLite, il che è abbastanza veloce per un dashboard mono-utente.
Codice totale della pipeline di dati: circa 300 righe di JavaScript. Non molto elegante, ma affidabile.
L’esperienza mobile
Ho progettato specificamente per una consultazione mobile-first. Il layout è una colonna unica che impila i quattro pannelli verticalmente. Ogni pannello può essere ripiegato — di solito lascio aperti il pannello 1 e il pannello 4, e ripiego i pannelli 2 e 3 a meno che non ne abbia bisogno.
Le scelte chiave di design:
– Grandi aree cliccabili (niente piccoli pulsanti)
– Colori ad alto contrasto (leggibili in pieno sole)
– Dati minimi per pannello (mostrare il riepilogo, non il dettaglio)
– Pull-to-refresh (interazione mobile naturale)
Funzionalità aggiunte successivamente
Azioni rapide. Dal dashboard, posso: riavviare OpenClaw, mettere in pausa/riprendere agenti specifici, approvare elementi in attesa, avviare manualmente attività pianificate. Questi pulsanti mi evitano di collegarmi in SSH per le operazioni quotidiane.
Vista storica. Un selettore di data che mostra l’attività di qualsiasi giorno precedente. Utile per sapere “cosa è successo ieri mentre dormivo?”
Proiezioni dei costi. Basate sugli ultimi 7 giorni di utilizzo, il dashboard prevede i costi mensili. Questa stima si aggiorna quotidianamente ed è stata precisa fino al 10%.
Cosa farei diversamente
Utilizzare WebSockets invece del polling. Il dashboard interroga l’API ogni 30 secondi per gli aggiornamenti. I WebSockets permetterebbero aggiornamenti in tempo reale senza questo sovraccarico. Non l’ho fatto perché 30 secondi sono sufficienti per le mie necessità, ma è il miglioramento ovvio.
Aggiungere un’integrazione per le notifiche. Per ora, gli avvisi passano tramite Grafana/Slack. Fare in modo che il dashboard invii direttamente notifiche push consentirebbe di centralizzare i miei canali di avviso.
Iniziare più semplice. Ho costruito troppo la prima versione con funzionalità di cui non avevo bisogno (costo per agente e ora, grafici storici, ricerca nei log). Le funzioni che utilizzo davvero ogni giorno sono: panoramica dello stato, elementi che richiedono un’azione, azioni rapide. Avrei potuto fare una v1 utile in poche ore invece di un weekend.
🕒 Published: