OpenClaw Gateway

Ciao, sono Alex di DEV STORIES DOT EU. OpenClaw Gateway, episodio 1 di 11. Sei lontano dalla scrivania, ma hai bisogno di una rapida code review. Mandi un messaggio dal telefono e, pochi secondi dopo, ti arriva un'analisi dettagliata, generata interamente da un server privato in esecuzione sulla tua macchina locale. L'architettura Personal AI Gateway è ciò che rende possibile questo setup completamente self-hosted. La maggior parte dei chatbot IA costringe i tuoi dati personali a passare attraverso un layer di orchestrazione di terze parti. Se vuoi connettere un'app di messaggistica a un modello linguistico, in genere ti affidi a un servizio cloud per fare da collante tra le API. Questo espone le tue query private e introduce latenza. L'architettura OpenClaw Gateway elimina il servizio intermedio eseguendo tutto all'interno di un singolo processo self-hosted. Questo processo fa da ponte dedicato. Si posiziona direttamente tra le tue interfacce di messaggistica quotidiane e il runtime IA che hai scelto. Tracciamo il percorso esatto di un messaggio per capire il flusso della logica. Mandi un code snippet dal telefono usando WhatsApp. Sulla tua macchina locale, il processo gateway è già in esecuzione. Mantiene connessioni persistenti con le tue app di messaggistica utilizzando librerie specifiche. Per WhatsApp, il gateway utilizza la libreria Baileys per gestire la connessione socket diretta. Per Telegram, si affida al framework grammY. Quando il tuo messaggio raggiunge il server locale, arriva incapsulato in una struttura dati specifica del protocollo. Un evento WhatsApp ha una forma del payload completamente diversa da un evento Telegram. Il gateway fa immediatamente il parsing di questi messaggi in arrivo. Rimuove i wrapper specifici della piattaforma, estrae il raw text e l'identificativo del mittente, e li impacchetta in un oggetto interno standardizzato. Ecco il punto chiave. Nel momento in cui il tuo messaggio raggiunge il runtime IA, il motore non sa da dove provenga il testo. Il runtime opera in modo completamente indipendente da Baileys o grammY. Vede solo una richiesta pulita e uniforme. L'IA elabora il tuo code snippet, genera la review e restituisce una risposta in plain text al gateway. Il gateway quindi inverte il flusso. Controlla il marcatore di origine allegato alla richiesta iniziale. Se hai fatto la domanda tramite WhatsApp, il gateway formatta la risposta dell'IA in una struttura compatibile con Baileys e la invia sul socket direttamente al tuo telefono. Se la richiesta proviene da Telegram, utilizza grammY per inviare la risposta. Mantenere tutto questo all'interno di un singolo processo self-hosted riduce drasticamente la complessità operativa. Non devi fare il deploy di microservizi multipli, configurare message queue o esporre endpoint locali a webhook esterni solo per instradare un messaggio di testo. Un'unica applicazione isolata gestisce i socket di rete, esegue la logica di normalizzazione e invoca il motore IA. Poiché il gateway unifica internamente più canali, il contesto della conversazione rimane centralizzato. Puoi iniziare il troubleshooting di un bug su Telegram mentre cammini, e fare una domanda di follow-up più tardi su WhatsApp. Il gateway garantisce che il runtime IA conservi la cronologia completa, indipendentemente dall'app mobile che apri. Il vantaggio più significativo di questa architettura è il controllo assoluto sui tuoi input e output attraverso qualsiasi interfaccia di messaggistica, interamente sul tuo hardware. Se ti piace il podcast e vuoi supportare lo show, puoi cercare DevStoriesEU su Patreon. Questo è tutto per questo episodio. Grazie per l'ascolto e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. OpenClaw Gateway, episodio 2 di 11. Il tuo bot di lavoro e il tuo bot assistente personale non dovrebbero mai condividere la stessa memoria, eppure avviare un'istanza server separata per ogni nuova persona del bot è un incubo operativo. È esattamente questo il problema che il Multi-Agent Routing risolve. Spesso gli ascoltatori confondono questo setup con un'architettura SaaS multi-tenant. Chiariamo subito questo punto. Il Multi-Agent Routing non è progettato per ospitare bot diversi per migliaia di clienti esterni. Esiste invece per organizzare le varie personas di un singolo proprietario, o per collegare chat di gruppo specifiche a bot specifici creati su misura, il tutto facendoli girare in modo efficiente sotto un unico tetto. Per far funzionare tutto ciò, il sistema separa rigorosamente due concetti. Devi capire la differenza tra un account ID e un agent ID. L'account ID è l'umano. È l'identificativo della persona che invia il messaggio. L'agent ID è il bot. Definisce la specifica persona, il model e le istruzioni con cui l'umano sta parlando. Un singolo umano con un solo account ID parlerà regolarmente con diversi agent ID nel corso della giornata. Sull'OpenClaw Gateway, diversi agent isolati girano fianco a fianco. Non condividi i memory state tra di loro. Ogni agent ID ha il suo workspace dedicato e il suo session store distinto. Quando un messaggio in entrata arriva al Gateway, il sistema deve capire esattamente quale workspace isolato debba riceverlo. Lo fa usando regole di routing conosciute come binding. I binding sono mapping deterministici. Analizzano gli esatti metadati allegati a un messaggio in entrata ed eseguono il routing di conseguenza. Ogni messaggio in entrata si porta dietro un payload di dati di connessione. Questo include il canale, come WhatsApp o Telegram. Include l'account ID del mittente. Può anche includere un peer identifier, che potrebbe indicare una specifica stanza di chat di gruppo. Sei tu a configurare i binding per valutare questi metadati. Ad esempio, puoi creare un binding che stabilisce che qualsiasi messaggio in arrivo sul canale WhatsApp venga instradato direttamente a un agent ID veloce e di uso quotidiano. Questo agent gestisce task veloci, liste della spesa o semplici ricerche web. Nella stessa identica configurazione, imposti un altro binding che stabilisce che qualsiasi messaggio in arrivo via Telegram venga instradato a un agent ID più potente, che fa girare un model più grande come Opus per lavori di deep coding. Il flusso logico è lineare. Il Gateway riceve un messaggio Telegram. Legge i metadati del canale e il tuo account ID. Controlla i binding, trova la regola che corrisponde a Telegram e inoltra il payload all'agent ID di Opus. L'agent Opus si sveglia nel suo workspace isolato. Fa una query al suo session store dedicato per recuperare la history della conversazione. Non ha assolutamente accesso alla lista della spesa che hai appena inviato all'agent WhatsApp. Ecco il punto chiave. Il Multi-Agent Routing trasforma un singolo Gateway in un centralino deterministico, usando i metadati del canale e dell'utente per garantire che la persona giusta gestisca sempre la richiesta corretta, senza mai contaminare le loro memorie. Come sempre, grazie per l'ascolto. Ci vediamo al prossimo episodio.

Ciao, sono Alex di DEV STORIES DOT EU. OpenClaw Gateway, episodio 3 di 11. Hai mai desiderato poter letteralmente scrivere un'anima per la tua IA, magari facendola rispondere esclusivamente come un'aragosta spaziale scontrosa? In OpenClaw, raggiungere questo livello di controllo del personaggio richiede zero codice. Avviene interamente tramite plain text, il che ci porta all'agent workspace e ai system prompt. Un agent in OpenClaw è definito dal suo workspace. Questo workspace è semplicemente una directory che contiene un set specifico di file di bootstrap in markdown. Invece di seppellire il tuo system prompt all'interno della logica dell'applicazione o in complessi campi di database, OpenClaw espone le istruzioni principali come documenti leggibili e versionabili. Quando l'applicazione gira, OpenClaw legge questi file per costruire il system prompt monolitico che guida il large language model. La costruzione si basa su quattro documenti principali. Il primo è il file markdown agents. Questo documento stabilisce l'identità di base, gli obiettivi primari e i rigidi confini operativi dell'agent. Pensalo come la job description di base. Dice al modello cosa deve ottenere e quali argomenti deve evitare del tutto. Il secondo documento è il file markdown soul. È qui che vivono la personalità, il tono e lo stile conversazionale. Questo è esattamente il punto in cui istruisci il modello a comportarsi come un'aragosta spaziale scontrosa. Scrivi direttive esplicite dicendo all'agent di lamentarsi del gelido vuoto dello spazio, di usare metafore sui crostacei e di comportarsi in modo generalmente infastidito dalle richieste umane. Isolando la personalità dalla logica di base, puoi scambiare il tono del tuo agent senza rischiare la sua affidabilità funzionale. Il terzo componente è il file markdown tools. Questo testo spiega le capacità esterne a disposizione dell'agent. Descrive quali funzioni il modello può triggerare, i parametri richiesti per quelle funzioni e come interpretare logicamente i risultati. Fa da ponte tra il ragionamento interno del modello e la tua vera e propria codebase. L'ultimo documento è il file markdown user. Questo file inietta contesto sulla persona che interagisce con l'agent. Può contenere le preferenze dell'utente, i livelli di competenza tecnica o i vincoli dell'account. Questo assicura che l'agent adatti le sue risposte allo specifico essere umano dall'altra parte della chat, piuttosto che offrire consigli generici. Ecco il punto chiave. OpenClaw prende i contenuti di questi quattro file e li concatena insieme. Questa stringa combinata diventa il system prompt finale. Il dettaglio cruciale è che questo prompt viene iniettato nella context window a ogni singolo turno conversazionale. Il modello non legge questi file una volta sola allo startup per poi tenerli in qualche modo in un banco di memoria separato. Legge l'intero blocco concatenato ogni volta che l'utente invia un nuovo messaggio. Questa scelta architetturale detta come devi scrivere i file del tuo workspace. Poiché l'intero testo del workspace viene anteposto a ogni singola interazione, il tuo conteggio dei token salirà in modo aggressivo. Se scrivi una backstory di tre pagine nel file soul, paghi il costo di elaborazione per quelle tre pagine ogni volta che l'utente dice semplicemente ciao. Cosa ancora più importante, i system prompt di grandi dimensioni consumano i limiti disponibili della context window. Un workspace appesantito ruba spazio alla vera e propria cronologia della conversazione, portando il modello a dimenticare le parti precedenti della chat molto più velocemente. Devi essere spietato quando editi i documenti del tuo workspace. Rimuovi le istruzioni ridondanti. Usa un linguaggio preciso. Se una regola nel file agents non viene mai triggerata, cancellala. Il system prompt non è uno step di configurazione una tantum. È una tassa ricorrente sulla tua context window e sul tuo budget API, pagata a ogni singolo turno della conversazione. Mantienilo snello, e il tuo agent rimarrà concentrato. Grazie per l'ascolto. Statemi bene, tutti.

Ciao, sono Alex di DEV STORIES DOT EU. OpenClaw Gateway, episodio 4 di 11. Fai il deploy di un nuovo chatbot nel workspace della tua azienda. Alice gli chiede di riassumere gli appunti della sua riunione privata e, cinque minuti dopo, il bot li cita per sbaglio a Bob. Il tuo agent ha appena fatto un leak di dati perché tratta tutti nel workspace come se fossero la stessa identica persona. Per risolvere questo problema devi capire il Session Management e la DM Isolation. Prima di sistemare questa sovrapposizione, dobbiamo chiarire un malinteso comune. Gli ingegneri spesso confondono le session keys con gli authentication token. Non sono la stessa cosa. Le session keys non sono barriere di sicurezza. Sono semplicemente dei selettori di routing. Dicono al sistema OpenClaw quale blocco di history della conversazione recuperare dal database e iniettare nel prompt. Se devi limitare chi può parlare con il tuo agent, usi una vera e propria autenticazione. Le session keys servono solo a tenere separato il testo. Ogni interazione con un agent OpenClaw avviene all'interno di una sessione. La sessione contiene la history della conversazione e il context attivo a breve termine. Di default, OpenClaw fa il routing di tutto il traffico attraverso un'unica session key condivisa chiamata main. Se fai girare uno script da terminale in locale o un assistente personale solo per te, questo comportamento di default funziona perfettamente. Tutto il tuo context rimane in un unico thread continuo. Ma se colleghi quello stesso identico agent a una piattaforma multiutente, l'impostazione di default salta. Ogni utente che parla con il bot scrive nella stessa identica history main. L'agent legge il prompt di Alice, genera una risposta e la salva. Quando Bob invia un messaggio dieci secondi dopo, l'agent legge l'input di Bob insieme al precedente input di Alice. È qui che la situazione si fa interessante. Puoi prevenire questa sovrapposizione usando le impostazioni di DM Isolation. Quando configuri l'integrazione con la piattaforma, cambi la strategia di routing della sessione dal default a per-channel-peer. Quando abiliti per-channel-peer, OpenClaw smette di fare il routing del traffico verso la sessione main. Invece, genera dinamicamente una session key univoca per ogni messaggio in arrivo. Lo fa combinando l'identificatore del canale della piattaforma con l'identificatore dell'utente. Ora, quando Alice scrive al bot in un canale specifico, OpenClaw costruisce una session key univoca per lei e per quel canale. Quando Bob scrive al bot, il suo identificatore utente genera una session key completamente diversa. Il sistema carica uno state pulito e vuoto per Bob. I loro context sono completamente isolati. Se Alice parla con il bot in un canale completamente diverso, ottiene una sessione nuova anche lì. Queste sessioni non mantengono lo state per sempre. OpenClaw gestisce il cleanup delle sessioni attraverso due eventi specifici di lifecycle. Il primo è un idle reset. Se una particolare sessione non riceve nuovi messaggi per una durata configurata, il sistema elimina il context. La volta successiva che l'utente invia un messaggio, riparte da zero. Il secondo meccanismo di cleanup è un hard daily reset. Indipendentemente da quanto sia attiva una conversazione, OpenClaw purga forzatamente tutti i context di sessione esattamente alle 4:00 del mattino, server time. Questo reset giornaliero funge da step automatizzato di garbage collection. Assicura che la memoria venga liberata e che le conversazioni long-running non consumino silenziosamente enormi quantità di context token nel corso di settimane di utilizzo. Quando fai il deploy di agent in ambienti di gruppo, non dare mai per scontato che la piattaforma gestisca la separazione degli utenti per te. Mappare esplicitamente le tue session keys al corretto user boundary è l'unico modo per prevenire context leak accidentali. Questo è tutto per questo episodio. Grazie per aver ascoltato, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. OpenClaw Gateway, episodio 5 di 11. Le context window dell'IA non sono infinite, ma la tua conversazione spesso deve esserlo. Quando una sessione di lunga durata sbatte contro un muro, la soluzione standard è iniziare a scartare completamente i messaggi più vecchi, facendo dimenticare improvvisamente all'agente dei passaggi di setup cruciali. Gestire i limiti di contesto con la Compaction risolve questo problema, condensando elegantemente le chat più vecchie in riassunti densi prima ancora di superare il limite. Prima di guardare come funziona, non confondere questa operazione con il session pruning. Il session pruning è un'operazione separata che elimina solo i tool result in eccesso. La Compaction opera direttamente sulla conversation history principale. Pensa a una sessione di coding di lunga durata. L'agente ha generato boilerplate, letto file locali e fatto debugging di errori logici per un'ora. Ogni interazione fa salire il token count. Se il sistema raggiunge l'hard limit del language model sottostante, l'API rifiuta la request e la sessione va in crash. Ti serve un modo per recuperare spazio senza rompere la logica dell'assistente. OpenClaw gestisce questa cosa tramite il Context Engine. Il Context Engine gestisce l'intero flusso di messaggi tra l'utente e il modello. All'interno di questo engine, c'è uno specifico lifecycle point chiamato compact. Questa fase fa da valvola di sicurezza automatica per il context overflow. L'engine monitora attivamente il token usage della conversazione corrente. Sei tu a definire una soglia massima di token nella tua configurazione. Finché la conversazione resta sotto questa soglia, i messaggi passano normalmente. Quando il token count si avvicina al limite, l'engine attiva automaticamente un memory flush tramite il lifecycle point compact. Quando parte il flush, il sistema divide la message history in due sezioni. Separa i messaggi più recenti da quelli più vecchi e storici. I messaggi recenti restano completamente intatti. L'engine preserva le parole esatte del botta e risposta immediato, così l'agente non perde il filo del discorso o la sintassi esatta della funzione su cui stai lavorando attivamente. Ecco il punto chiave. I messaggi più vecchi non vengono scartati. Vengono invece dirottati verso un processo di summarization secondario. Questo processo legge il grosso della conversazione iniziale e lo condensa in un breve testo riassuntivo. Questo testo cattura gli obiettivi originali, le decisioni architetturali prese all'inizio e le regole stabilite, ripulendo il tutto dai riempitivi della conversazione e dalle iterazioni obsolete del codice. L'engine quindi ristruttura la memoria attiva. Sostituisce il grande blocco di messaggi raw più vecchi con questo singolo blocco riassuntivo. Il nuovo prompt strutturato contiene prima il blocco riassuntivo, seguito dai messaggi recenti parola per parola. Il token count totale crolla drasticamente. L'agente capisce comunque il contesto storico leggendo il riassunto, e può continuare a eseguire il task attivo leggendo i messaggi recenti. La conversazione prosegue liscia senza alcun intervento manuale. Un context management efficace non significa conservare ogni singola parola che hai digitato, ma comprimere sistematicamente il passato in modo che l'agente abbia il massimo spazio per ragionare sul presente. Per questo episodio è tutto. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. OpenClaw Gateway, episodio 6 di 11. Mettere un'IA in un workspace Slack condiviso con accesso al terminal sembra un incidente di sicurezza garantito, a meno che tu non definisca rigorosamente chi è autorizzato a dirle cosa fare. Oggi parliamo di Security e Trust Boundaries. La regola fondamentale dell'OpenClaw Gateway è che opera su un trust model da assistente personale. Molti sviluppatori danno per scontato che gli AI gateway abbiano sistemi di autorizzazione user-level complessi e integrati. OpenClaw no. OpenClaw non è progettato per un isolamento multi-tenant ostile. Non cerca di separare in modo sicuro gli utenti malintenzionati l'uno dall'altro su una singola instance condivisa. Invece, l'intero Gateway agisce come un singolo boundary che rappresenta un unico operatore fidato. Il sistema presuppone che chiunque possa comunicare con il Gateway sia autorizzato ad agire per conto del proprietario. Pensalo come una workstation sbloccata. Se la tua instance di OpenClaw è configurata con un tool che modifica l'infrastruttura, chiunque possa comunicare con quella instance può innescare quella modifica. Il modello AI in sé non ha il concetto di user role o access token. Vede solo uno stream di testo in entrata. Questo ci porta al grave rischio dei canali condivisi. Se colleghi il tuo Gateway a un gruppo Telegram pubblico o a un canale Slack di un team numeroso, ogni singolo utente in quel canale è ora all'interno del tuo trust boundary. L'IA tratta ogni messaggio che legge come un'istruzione valida. Se un utente esterno digita un attacco di prompt injection nella chat, sta dirottando l'autorità delegata del tool del tuo bot. Il Gateway non è in grado di distinguere tra te che chiedi un system status e un attaccante che inganna il modello per fargli eseguire uno shell script distruttivo. L'autorità appartiene al bot, ma il controllo appartiene a chi fornisce il prompt. Se hai una connessione esposta, come un bot Telegram, devi metterla in sicurezza. Primo, disattiva i tool con privilegi elevati per quello specifico profilo Gateway. Non dare a un bot accessibile pubblicamente l'accesso al tuo file system locale o ad API interne sensibili. Mantieni il suo toolset limitato ad azioni read-only o innocue. Secondo, restringi il layer di comunicazione. Configura la connessione per accettare messaggi diretti solo da specifici utenti associati, ignorando di fatto completamente le chat di gruppo e gli sconosciuti. Limitando chi può inserire testo e quali tool il bot può eseguire, metti in sicurezza il boundary. Per verificare di non aver lasciato porte aperte, usa la command line utility integrata. Esegui il comando openclaw security audit. Questo tool scansiona la tua configurazione attiva del Gateway e controlla due rischi principali. Primo, controlla la tua network exposure. Ti avviserà se la tua instance è in ascolto su interfacce pubbliche anziché essere associata in modo sicuro a localhost. Secondo, segnala i tool permissivi. L'audit ti avviserà se hai funzionalità ad alto rischio, come l'arbitrary code execution, abilitate contemporaneamente alle integrazioni con chat pubbliche. Ecco il punto chiave. Il boundary della sicurezza del tuo sistema è esattamente il boundary di chi può inviare testo ai tuoi modelli. Se non puoi limitare il pubblico, devi limitare i tool. Grazie per aver passato qualche minuto con me. Alla prossima, stammi bene.

Ciao, sono Alex di DEV STORIES DOT EU. OpenClaw Gateway, episodio 7 di 11. Dare a un modello di IA l'accesso raw alla command-line sembra una scorciatoia per distruggere il sistema. Ma cosa succederebbe se l'agent potesse eseguire automaticamente comandi innocui di data-parsing, chiedendo esplicitamente il tuo permesso prima di toccare qualcosa di distruttivo? L'Exec tool e le Runtime Approvals gestiscono esattamente questo equilibrio. L'Exec tool permette a un agent OpenClaw di eseguire comandi shell per interagire con il sistema. Quando l'agent decide che deve eseguire un comando, punta direttamente alla macchina host o a un container sandbox designato. Usare un container sandbox limita il blast radius per l'esecuzione generale. Tuttavia, a volte l'agent ha davvero bisogno di interagire con il tuo file system locale, leggere i tuoi log locali o avviare processi locali. Eseguire comandi sull'host è un'operazione potente, ed è esattamente per questo che esiste il modello di autorizzazione. OpenClaw usa un sistema di autorizzazione a due livelli per farti mantenere il controllo senza rallentare inutilmente l'agent. Il primo livello si basa sui safe bin. Sono binari specifici che metti esplicitamente in whitelist come innocui, come jq per fare il parsing di JSON o grep per cercare testo. Se l'agent chiama un comando che usa solo questi safe bin, il Gateway lo esegue immediatamente. Non ci sono prompt, e l'agent mantiene il suo slancio. Il secondo livello intercetta tutto il resto. Se l'agent tenta un'esecuzione shell completa o prova a usare un binario che non è nella safe list, il Gateway intercetta la richiesta. Ferma l'agent e innesca il sistema di Runtime Approvals. Appare un prompt nella UI del tuo Gateway o nella tua companion app. Puoi revisionare l'esatta stringa di comando che l'agent vuole eseguire. Se approvi, il Gateway esegue il comando e restituisce l'output all'agent. Se lo rifiuti, il comando non viene mai eseguito. Invece, l'agent riceve un errore di esecuzione negata, e deve trovare un altro modo per procedere o chiederti chiarimenti. Ecco il punto chiave di come questo si traduce in pratica. Mettiamo che l'agent debba analizzare un file di log enorme. Chiama grep per estrarre gli errori. Questo viene eseguito all'istante. Poi, deve compilare il progetto, quindi tenta di eseguire npm run build come processo in background. Il Gateway ferma l'agent e manda un ping alla tua companion app. Leggi il comando, ti rendi conto che ha senso e premi approva. La build parte in background. Più tardi, l'agent decide di fare pulizia tentando di eliminare un file sorgente. Il Gateway ti manda un altro ping. Tu neghi la richiesta. Il tuo file rimane intatto, e l'agent impara che non ha i permessi per quell'azione. C'è un vincolo di sicurezza rigoroso che devi conoscere quando esegui comandi sull'host. Il Gateway rifiuta esplicitamente qualsiasi tentativo di sovrascrivere la variabile d'ambiente path. Questo previene l'hijacking. Senza questo blocco, un prompt malevolo potrebbe ingannare l'agent facendogli ridefinire il path, facendo in modo che un nome di un safe bin come grep esegua uno script distruttivo nascosto in una cartella diversa. Dato che il path è bloccato, la lista dei safe bin rimane assoluta. Il vero potere dell'Exec tool non è solo che l'IA può eseguire comandi, ma che il modello di sicurezza a livelli forza un umano nel loop solo quando la posta in gioco è alta, lasciando l'agent completamente autonomo per il lavoro di routine. Se vuoi aiutare a mandare avanti lo show, puoi cercare DevStoriesEU su Patreon. Per questo episodio è tutto. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. OpenClaw Gateway, episodio 8 di 11. Vuoi che il tuo agent manipoli le immagini usando un command-line tool. Di solito, questo significa scrivere wrapper Python, definire schema e sperare che il language model capisca i parametri. Ma in realtà non hai bisogno di codice per insegnare a un'IA una nuova capability. Ti basta un file di testo. Oggi ci concentriamo su come insegnare agli agent usando le Skill in OpenClaw. Una Skill in OpenClaw è essenzialmente un manuale di istruzioni. Si tratta di un semplice file di testo chiamato SKILL punto md, formattato secondo lo standard AgentSkills. Non è un binary compilato e non è uno script Python. È un documento Markdown che dice all'agent esattamente come orchestrare i tool esistenti. All'interno di questo file, scrivi istruzioni step-by-step. Definisci lo scopo della skill, i tool che usa e la sequenza di azioni che l'agent deve eseguire. Se stai creando una skill di image processing chiamata image-lab, il tuo file SKILL punto md spiegherà come formattare gli argomenti da command-line per ridimensionare o ritagliare un'immagine. L'agent legge questo file e traduce le tue istruzioni in inglese in precise esecuzioni da command-line. Una skill è inutile se il tool sottostante manca dal sistema. OpenClaw previene questi errori usando il load-time gating. Questo ti permette di definire dei prerequisiti, così il tuo agent non tenta mai di usare software che non è installato. Gestisci questo aspetto dichiarando i requirements nella configurazione della skill. Per la skill image-lab, potresti aver bisogno di uno specifico package manager per eseguire i comandi. Lo specifichi usando la property requires punto bins, elencando il nome dell'eseguibile, come uv. Puoi anche richiedere specifiche environment variables usando la property requires punto env, che assicura la presenza di una API key o di un path di configurazione prima che la skill si attivi. Quando OpenClaw si avvia, valuta questi gate. Controlla l'environment locale per cercare il binary uv e qualsiasi variabile richiesta. Se mancano, OpenClaw salta silenziosamente la skill. Il sistema non andrà in crash e l'agent non avrà allucinazioni su comandi non supportati. Semplicemente, opererà senza le capability di image-lab. Ecco il punto chiave. OpenClaw deve fornire queste skill valide al language model in modo efficiente. Prende tutte le skill che hanno superato i check a load-time e le compila in una lista XML compatta. Questo blocco XML viene iniettato direttamente nel system prompt dell'agent. I language model sono altamente ottimizzati per il parsing dei tag XML. Formattando il manuale di istruzioni in questo modo, l'agent separa nettamente la sua persona principale dalla logica rigorosa e step-by-step definita nelle tue skill. Non devi scrivere ogni skill da solo. OpenClaw si integra con ClawHub, il registry ufficiale per le skill create dalla community. Se hai bisogno che il tuo agent operi su uno specifico database o su una cloud utility, puoi cercare su ClawHub e installare una skill esistente. Viene scaricata nel tuo environment, passa attraverso gli stessi check a load-time e viene iniettata automaticamente nel system prompt. L'aspetto più prezioso dell'architettura Skills è il disaccoppiamento delle capability dal codice. Puoi riprogrammare completamente il modo in cui il tuo agent risolve problemi complessi multi-step semplicemente modificando un file Markdown, senza mai modificare la logica della tua applicazione o compilare una nuova build. Grazie per aver passato qualche minuto con me. Alla prossima, stammi bene.

Ciao, sono Alex di DEV STORIES DOT EU. OpenClaw Gateway, episodio 9 di 11. Il tuo agente sta cercando di estrarre dati da una pagina web, ma non si limita a fare il parsing di raw HTML. Deve renderizzare una dashboard React dinamica, cliccare un bottone e aspettare che carichi un chart. Devi dare all'agente un'interfaccia web completamente funzionale, ma non vuoi assolutamente che faccia casini con i tuoi tab aperti o che ti rubi il controllo del mouse. Il Managed Browser Tool gestisce esattamente questo. Questo tool dà al tuo agente la capacità di cliccare, digitare, navigare e catturare visivamente esattamente quello che vedrebbe un umano. Fa girare un vero ambiente browser per interagire con applicazioni renderizzate lato client, bypassando le limitazioni delle semplici richieste HTTP. Per tenere al sicuro il tuo workspace, il Managed Browser Tool usa diversi profili operativi. Il default è il profilo openclaw isolato. Quando l'agente usa questo profilo, il tool avvia un'istanza Chromium dedicata e completamente separata. Ha i suoi cookie, il suo local storage e la sua history vuota. L'agente naviga nel suo browser dedicato. Può compilare form e cliccare nei menu senza mai toccare la tua sessione Chrome personale. Tuttavia, a volte un agente ha bisogno di accedere a tool interni dove sei già autenticato. Per questo, il tool fornisce il profilo user. Invece di partire da zero, il profilo user si attacca alla tua sessione Chrome esistente, dove hai già fatto il login. Si connette tramite il DevTools Protocol attraverso il Model Context Protocol. Questo permette all'agente di sfruttare i tuoi login token attivi per quel task specifico, senza chiederti di passare le credenziali direttamente all'AI. Ecco il punto chiave. Dare a un agente AI un browser automatizzato all'interno del tuo ambiente introduce rischi di sicurezza immediati. Per mitigare la cosa, il controllo del Managed Browser Tool è strettamente loopback-only. L'agente comunica con il browser interamente tramite l'interfaccia di loopback locale. Cosa ancora più importante, ogni request di navigazione è protetta dalla policy di Server-Side Request Forgery. Questa policy assicura che l'agente non possa usare la sua istanza del browser come proxy per scansionare silenziosamente le porte della tua rete locale o chiamare servizi interni non autorizzati. Pensa allo scenario della dashboard React. Per prima cosa, l'agente lancia un comando per avviare il browser usando il profilo isolato di default. Naviga all'URL della dashboard e aspetta attivamente che i componenti JavaScript vengano montati e che il DOM si stabilizzi. Poi, individua l'elemento specifico del chart usando un selettore CSS e triggera un evento click per espandere la vista. Infine, lancia un comando di screenshot. Il browser cattura il frame renderizzato e restituisce l'image buffer direttamente al gateway. Dare un browser a un agente non dovrebbe mai significare consegnargli le chiavi della tua rete interna o della tua sessione Chrome personale. Il Managed Browser Tool mantiene l'agente altamente capace, ma strettamente contenuto. Per questo episodio è tutto. Alla prossima!

Ciao, sono Alex di DEV STORIES DOT EU. OpenClaw Gateway, episodio 10 di 11. Chiedi alla tua IA di fare lo scrape di un sito web complesso o di macinare migliaia di righe di log, e poi rimani lì seduto. Fissi un indicatore che gira per dieci minuti, senza poter fare un'altra domanda finché il task non finisce. Per risolvere questo problema bloccante, usi i sub-agent effimeri. Un sub-agent effimero è un background worker temporaneo e isolato. Invece di fare direttamente i calcoli pesanti, il tuo main chat agent delega il lavoro. Lo fa usando uno specifico system tool chiamato sessions spawn. Quando il main agent incontra un task enorme, attiva questo tool. Gli passa un prompt chiaro, eventuali file di contesto necessari e le istruzioni specifiche per il job. Questa azione crea una chat session completamente nuova e invisibile, che gira interamente in background. Dato che questa sessione è isolata, il tuo main agent viene liberato immediatamente. Puoi continuare a parlare con il tuo assistente principale, fare domande non correlate o assegnare altri task mentre il sub-agent macina i dati pesanti di nascosto. Vediamo uno scenario concreto. Butti un enorme error log del server nella tua chat principale e chiedi un security audit. Processare quel log riga per riga con il tuo LLM principale e più potente richiede molto tempo e brucia un sacco di token costosi. Invece, il tuo main agent delega il job. Ecco il punto chiave. Quando chiama sessions spawn, il main agent può specificare un modello completamente diverso per il background task. Può assegnare un LLM più economico e veloce al sub-agent. Questo background worker usa il modello più veloce per macinare la ripetitiva analisi dei log. Il main agent rimane responsive usando il modello smart, mentre il sub-agent fa il lavoro sporco usando il modello veloce. Quando il sub-agent finisce finalmente di fare il parsing di quei log, ha bisogno di un modo per restituire i dati. Lo fa annunciando il suo risultato finale risalendo la chain. Il sub-agent prende il suo summary compilato e inietta un messaggio direttamente indietro nella chat originale che ha fatto la richiesta. Vedi semplicemente apparire un nuovo messaggio dal sub-agent con la tua analisi dei log completata, pronta per essere discussa da te e dal main agent. Questa architettura è conosciuta come orchestrator pattern, e si basa su regole relative alla nesting depth. Lo scenario che abbiamo appena visto è a nesting depth uno. L'utente parla con il main agent, e il main agent fa lo spawn di un sub-agent. OpenClaw supporta anche la nesting depth due. In uno scenario a depth due, il tuo sub-agent che fa il parsing dei log potrebbe incontrare un payload pesantemente codificato nei log. Può quindi fare lo spawn di un suo sub-agent solo per decodificare quello specifico payload. Quell'agent di secondo livello decodifica il testo, lo ripassa al primo sub-agent, che poi completa l'analisi dei log e riporta il tutto alla tua chat principale. Il sistema limita rigorosamente il tutto a depth due. Questo hard limit previene loop ricorsivi incontrollati in cui gli agent continuano a fare lo spawn di altri agent all'infinito, prosciugando le tue risorse di compute. I sub-agent effimeri cambiano radicalmente il modo in cui interagisci con un'interfaccia a prompt. Smetti di trattare il tuo LLM come un singolo thread bloccato e inizi a trattarlo come un asynchronous task manager. Per questo episodio è tutto. Alla prossima!

Ciao, sono Alex di DEV STORIES DOT EU. OpenClaw Gateway, episodio 11 di 11. Un vero assistente non resta semplicemente inattivo ad aspettare che tu digiti un comando. Controlla proattivamente i tuoi sistemi e ti avvisa quando qualcosa richiede effettivamente la tua attenzione. Passare da un loop reattivo di prompt e risposta a un agent autogestito richiede meccanismi di scheduling ed esecuzione specifici. Questo ci porta ai workflow di automazione proattiva. OpenClaw gestisce l'automazione basata sul tempo usando due meccanismi distinti. Il primo è l'Heartbeat. Il secondo è Cron. Gli sviluppatori spesso li confondono perché entrambi triggerano azioni automaticamente in base al tempo, ma hanno ruoli architetturali completamente diversi per quanto riguarda lo stato e l'isolamento della sessione. L'Heartbeat è un loop periodico che gira continuamente all'interno della tua sessione principale attiva. È pensato per controlli di routine continui in cui il tuo contesto attuale è importante. Ecco il punto chiave. Dato che l'Heartbeat opera all'interno della tua sessione corrente, ha accesso diretto alla tua interfaccia attiva. Pensa a uno scenario in cui vuoi monitorare la tua inbox per cercare messaggi urgenti. Configuri un Heartbeat per eseguire un controllo ogni trenta minuti. Se rileva un'email critica, l'Heartbeat può inviare immediatamente un alert in linguaggio naturale direttamente nel tuo stream di conversazione attivo. Agisce come un thread in background continuo attaccato al tuo stato utente corrente, permettendo interruzioni immediate e contestuali. Cron funziona in modo completamente diverso. È pensato per job precisi e schedulati che richiedono un isolamento completo. Se vuoi che il sistema compili un briefing mattutino giornaliero completo da varie fonti di dati esattamente alle sei del mattino, usi Cron. Quando una schedulazione Cron scatta, OpenClaw non usa la tua chat attiva. Invece, avvia una sessione in background completamente isolata. Recupera i dati necessari, gestisce il lavoro analitico pesante in modo silenzioso e traccia l'intero job internamente come Background Task. Questo significa che l'elaborazione pesante non inquina la context window della tua chat desktop attiva. Una volta completato il job, il briefing finale viene salvato ed è pronto per essere recuperato quando fai il login. L'Heartbeat condivide lo stato con te, mentre Cron gira in modalità headless e isolata. I trigger basati sul tempo sono solo una parte del workflow. OpenClaw si affida a Hook e Standing Order come strumenti complementari per completare il loop di automazione. Mentre Heartbeat e Cron dettano quando un'azione deve avvenire in base all'orologio, gli Hook gestiscono i trigger esterni event-driven. Un Hook espone un endpoint in ascolto che i sistemi esterni possono chiamare. Se un log critico del server indica un errore, un sistema esterno può chiamare un Hook di OpenClaw, svegliando l'assistente per analizzare immediatamente l'errore senza aspettare il successivo impulso schedulato dell'Heartbeat. Gli Standing Order forniscono le regole operative persistenti per tutte queste run autonome. Quando quel job Cron isolato si sveglia alle sei del mattino, non c'è nessun utente presente a guidare il suo output. Gli Standing Order definiscono il formato esatto, la profondità analitica e le regole di priorità che l'assistente deve rispettare mentre lavora in completa autonomia. Combinando Heartbeat periodici per il monitoraggio attivo, job Cron isolati per task pesanti schedulati e Standing Order persistenti per governare il comportamento non guidato, cambi radicalmente la natura dell'applicazione. Smetti di costruire una semplice interfaccia di chat e inizi a fare il deploy di un vero assistente autonomo. Dato che questo è l'ultimo episodio della nostra serie su OpenClaw, ti incoraggio vivamente a esplorare la documentazione ufficiale, a provare a configurare questi background task hands-on, o a visitare devstories dot eu per suggerire argomenti per la nostra prossima serie. Grazie per aver passato qualche minuto con me. Alla prossima, stammi bene.