Hermes Agent e le alternative a OpenClaw: quale scegliere nel 2026

Tra Hermes Agent e le altre alternative a OpenClaw, la scelta dipende dal problema da risolvere: configurazione, manutenzione, permessi o hosting. Questi 7 progetti rispondono a esigenze diverse: NanoClaw punta anzitutto sull'isolamento, ZeroClaw semplifica il runtime e OpenHands si rivolge ai team di sviluppo; NemoClaw può cambiare il modo in cui viene eseguito OpenClaw senza sostituirlo.

Verifica effettuata sui repository e sulla documentazione ufficiale dei progetti l'11 novembre 2026. Il confronto si basa sulla documentazione: non sono stati svolti test con accesso agli account né audit di sicurezza. Le date riportate sotto indicano l'ultima release del repository; le descrizioni delle funzionalità seguono la documentazione corrente del codice sorgente, che può essere più avanzata della versione distribuita.

Se la migrazione non è ancora decisa, conviene partire dalla recensione di OpenClaw: aiuta a distinguere una funzionalità mancante da una scelta di deployment che si potrebbe modificare.

Alternative a OpenClaw: il confronto a colpo d'occhio

Il punto di partenza è il lavoro che si vuole continuare a svolgere. Un assistente via chat, un aiutante sul desktop e un centro di controllo per lo sviluppo rispondono a esigenze diverse, anche se tutti e tre possono eseguire comandi.

La seconda tabella va letta prima di concedere accesso a file o account. Una sandbox limita ciò che il codice in esecuzione può raggiungere. Una richiesta di approvazione stabilisce se un'azione può partire.

La cronologia dei tag di NemoClaw contiene le note della release di prodotto corrente. La pagina GitHub Releases mostra invece una prerelease del toolchain CI del 1 ottobre 2026. Non è la release attuale dell'applicazione.

Sono progetti di software libero: i costi operativi riguardano il modello e la macchina, non una licenza software. L'analisi dei costi di OpenClaw chiarisce questa distinzione.

Quattro scelte rapide

Il deployment più leggero: ZeroClaw. Il binario unico precompilato è indicato quando l'obiettivo è eliminare le dipendenze del runtime. È una valutazione del confezionamento del software, non una classifica basata su misurazioni della RAM: un modello locale o il browser possono comunque determinare gran parte dei requisiti della macchina.

La scelta più sicura per come documenta l'isolamento: NanoClaw. Per sostituire un assistente personale via chat, il confine del container e il gateway esterno per le credenziali ne fanno la proposta predefinita più convincente di questo confronto. La raccomandazione riguarda quel preciso impianto progettuale: non dimostra che abbia meno vulnerabilità di ogni concorrente.

L'opzione locale più semplice per chi non sviluppa: Goose. L'app desktop nativa evita di fare del terminale l'interfaccia di tutti i giorni. Prima di assegnargli un lavoro, occorre cambiare la modalità di approvazione: la facilità d'uso non implica accessi limitati.

La scelta per un team di sviluppo: OpenHands. Il suo centro di controllo è adatto al lavoro sui repository e alle automazioni su backend diversi. Per un team operativo non tecnico che non può gestire l'hosting, è più pertinente la sezione sui servizi gestiti qui sotto.

Hermes Agent e le altre alternative: quale problema risolvono?

Hermes Agent: mantenere l'assistente personale, cambiare il sistema che lo gestisce

Hermes Agent è l'agente personale di Nous Research, pensato per memoria persistente, skill riutilizzabili e attività pianificate. È adatto a chi vuole un assistente che ricordi le preferenze e porti avanti i compiti tra una conversazione e l'altra, senza ricominciare ogni volta da zero. Chi gestisce un'attività da solo potrebbe usarlo per ricerche periodiche, conservando le istruzioni che rendono utili quei resoconti. Va scelto per la continuità, senza aspettarsi che scompaiano le responsabilità di hosting.

Ideale per: Un assistente personale in cui memoria e procedure hanno un ruolo centrale.
Punto di forza: Skill apprese e un percorso documentato di importazione da OpenClaw.
Manutentori e licenza: Nous Research; MIT.
Deployment: Linux, macOS, Windows nativo o WSL2; backend di esecuzione locali e remoti.

Il repository di Hermes documenta un importatore ufficiale per impostazioni, memorie e skill di OpenClaw. Consente di vedere un'anteprima della migrazione e richiede un'opzione esplicita per trasferire i segreti. È più utile di una generica promessa di compatibilità: prima di autorizzare il nuovo agente ad agire, si può controllare ciò che verrà trasferito.

La documentazione sulla sicurezza distingue autorizzazione dei messaggi, approvazione dei comandi pericolosi e isolamento in container. Il backend di esecuzione conta. Scegliere un backend locale non equivale a scegliere Docker; inoltre, le liste di autorizzazione della piattaforma stabiliscono chi può parlare con l'agente, non ciò che l'agente può raggiungere una volta ammesso.

Per un report settimanale, conviene importare prima istruzioni e dati di esempio. L'esecuzione pianificata va lasciata disattivata finché non è chiaro come vengono segnalate le azioni negate. Per i contesti non presidiati e cron, la documentazione prevede il rifiuto predefinito dei comandi pericolosi: un processo può quindi fermarsi dove una sessione interattiva chiederebbe conferma.

OpenClaw o Hermes: quando vale la pena cambiare?

Il passaggio ha senso quando memoria, procedure riutilizzabili o percorso di importazione risolvono un problema quotidiano. Se il solo problema è un workspace troppo ampio, è meglio correggere prima lo spazio di lavoro e i confini dell'esecuzione, senza presumere che un altro agente li migliori. Il confronto approfondito tra Hermes Agent e OpenClaw affronta questa scelta più specifica.

NanoClaw: partire dal confine del container

NanoClaw è un assistente orientato alla messaggistica che esegue gli agenti in container Docker. Il codice attuale è mantenuto nell'organizzazione nanocoai, alla quale rimanda il vecchio repository qwibitai. Per chi vuole un assistente via chat che lavori su una cartella volutamente limitata, questo progetto è più facile da valutare rispetto a un agente con accesso all'intera postazione. Il compromesso riguarda la gestione: personalizzare significa spesso modificare il proprio fork.

Ideale per: Agenti personali o di gruppi ben separati, con accesso circoscritto ai file.
Punto di forza: Mount espliciti e un gateway per le credenziali esterno all'agente.
Manutentori e licenza: Collaboratori di nanocoai/NanoClaw; MIT.
Deployment: macOS o Linux, oppure Windows tramite WSL2, con Docker.

Il repository attuale di NanoClaw descrive un host Node e Claude Agent SDK come provider predefinito dell'agente. Le skill per i canali e per i provider alternativi aggiungono i componenti necessari. L'ultima release contrassegnata da un tag precede il README v2 corrente: occorre quindi confrontare le istruzioni della revisione che si installa, senza considerare ogni funzionalità del sorgente attuale come garantita dalla release.

Il modello di sicurezza di NanoClaw identifica nei container il confine principale. Gli agenti operano senza privilegi root e vedono le directory montate. Per montare directory aggiuntive serve una lista di autorizzazione esterna, che gli agenti non possono modificare. Le credenziali API effettive restano fuori dai container e vengono iniettate dal gateway delle credenziali.

Per un assistente che prepara report commerciali, la preparazione cambia: si rende visibile una cartella di esportazione circoscritta, non la directory home dell'operatore. Quando le informazioni devono restare separate, occorrono workspace distinti per i diversi gruppi. Le sessioni all'interno di un gruppo di agenti condividono la memoria del gruppo: una nuova conversazione non crea automaticamente un nuovo confine di riservatezza.

Nanobot: scegliere Python per adattare l'agente

Nanobot è il framework Python di HKUDS per agenti personali, con interfacce via browser, terminale e app di chat. È adatto a un operatore tecnico che vuole esaminare ed estendere il sistema che gestisce report, file e attività pianificate. Un piccolo progetto di automazione interna può partire da una directory di prova e da un compito circoscritto sui documenti. Va scelto perché Python e il suo flusso di lavoro sono adatti alle proprie esigenze, non perché un codice breve dimostri maggiore sicurezza.

Ideale per: Chi sviluppa in Python e mantiene un agente personale o interno.
Punto di forza: Gestione di file, memoria e pianificazione con un'interfaccia browser.
Manutentori e licenza: HKUDS e collaboratori; MIT.
Deployment: Python su macOS, Linux o Windows.

Il dettaglio decisivo è nella documentazione di configurazione di Nanobot: i valori predefiniti generali mostrano la restrizione al workspace disattivata e l'impostazione della sandbox della shell vuota. Contano anche il progetto selezionato nel browser e la modalità di accesso. È necessario esaminare la configurazione effettiva, senza presumere che aprire un progetto confini ogni strumento al suo interno.

Per la produzione, i manutentori raccomandano la restrizione al workspace insieme a una sandbox della shell: Bubblewrap su Linux o Seatbelt su macOS. Questi backend limitano l'accesso al filesystem, ma non alla rete. Su Windows, la documentazione segnala con un avviso che i comandi della shell vengono eseguiti senza sandbox del sistema operativo.

Un prototipo per l'area amministrazione e finanza richiede quindi decisioni separate sui file leggibili e sui servizi raggiungibili. Poter leggere un report non significa che l'agente debba avere le credenziali per aggiornare il sistema contabile. Meglio partire da copie dei dati di ingresso e controllare il risultato prima di collegare gli account aziendali.

ZeroClaw: eliminare lo stack del runtime, senza eludere le scelte sui permessi

ZeroClaw è un runtime per agenti personali distribuito come singolo binario Rust. Tra questi progetti è il più indicato quando il problema è l'insieme di runtime di linguaggio e servizi che circondano l'agente. Chi gestisce un homelab può usare il binario precompilato e mantenere esplicita la configurazione di provider, canali e workspace. Serve comunque qualcuno che comprenda quelle impostazioni.

Ideale per: Un responsabile con competenze tecniche che cerca una distribuzione più semplice del runtime.
Punto di forza: Un binario nativo precompilato che non richiede runtime Node o Python.
Manutentori e licenza: ZeroClaw Labs e community; MIT OR Apache-2.0.
Deployment: Linux, macOS e Windows, con guide per ulteriori piattaforme.

Il repository di ZeroClaw indica l'autonomia supervisionata come impostazione predefinita: le operazioni a rischio medio richiedono approvazione, quelle ad alto rischio vengono bloccate. Documenta inoltre una dashboard, canali di messaggistica e workflow attivati da eventi. Può quindi sostituire utilmente un assistente sempre attivo, andando oltre una semplice chat nel terminale.

Prima di definire isolata l'installazione, occorre leggere le regole di selezione della sandbox. Nel runtime nativo, la selezione automatica può arrivare a non usare alcuna sandbox del sistema operativo se i controlli sui backend disponibili falliscono. La release Linux standard non include tutti i backend sandbox opzionali citati nell'elenco generale delle funzionalità.

È questa verifica a cambiare la raccomandazione: potendo accertare il confine attivo, la distribuzione di ZeroClaw è interessante. Se invece si vuole partire da un isolamento evidente senza indagare la disponibilità dei backend, NanoClaw è il candidato più chiaro tra gli agenti personali.

NVIDIA NemoClaw: mantenere l'agente, cambiarne il perimetro operativo

NVIDIA NemoClaw è uno stack di riferimento per eseguire gli agenti supportati nelle sandbox NVIDIA OpenShell. Va approfondito quando il lavoro svolto dall'agente soddisfa già le esigenze, ma serve un diverso livello di esecuzione e di policy di rete. OpenClaw resta l'agente predefinito; la documentazione corrente elenca anche Hermes e LangChain Deep Agents Code. Definirlo una semplice alternativa a OpenClaw non ne coglie lo scopo.

Ideale per: Chi gestisce l'infrastruttura e valuta le policy attorno a un agente supportato.
Punto di forza: Gestione del ciclo di vita delle sandbox e delle policy di rete e inferenza.
Manutentori e licenza: NVIDIA; Apache-2.0.
Deployment: Linux; macOS Apple Silicon e Windows WSL2 con limitazioni documentate.

I prerequisiti di piattaforma ne fanno una scelta operativa più impegnativa dell'installazione di un piccolo binario. Il repository definisce il progetto alpha e indica che i manutentori rispondono secondo disponibilità, senza garanzie. Un fornitore dal nome noto non equivale a un contratto di assistenza per la produzione.

La documentazione delle policy di rete descrive una configurazione di base con destinazioni autorizzate e decisioni dell'operatore per quelle non elencate. Le credenziali dell'inferenza gestita restano fuori dalla sandbox. Il livello scelto, però, modifica il perimetro: Personal consente un accesso ampio alla rete e può permettere l'uscita dei dati dal workspace senza un'approvazione specifica per la destinazione.

Per un CTO, un progetto pilota utile è un'integrazione circoscritta con endpoint esplicitamente necessari. Insieme al risultato vanno registrati il livello selezionato e le configurazioni predefinite autorizzate. La sola presenza della parola “sandbox” nel diagramma architetturale non giustifica l'approvazione di una configurazione. L'approfondimento su OpenShell descrive il livello sottostante.

Goose: lavorare dal desktop, poi definire i poteri dell'agente

Goose è un agente generico con app desktop native, interfaccia a riga di comando e API. Il repository attuale appartiene alla community Agentic AI Foundation presso la Linux Foundation; i vecchi link al repository Block rimandano a quello attuale. È la mia scelta per l'interfaccia locale di chi vuole aiuto con ricerca, scrittura o file senza passare la giornata nel terminale. Il desktop rende l'interazione più semplice, ma da solo non limita gli strumenti.

Ideale per: Un singolo operatore che desidera un'interfaccia desktop.
Punto di forza: Strumenti e approvazioni configurabili in un'app nativa.
Manutentori e licenza: Community AAIF Goose; Apache-2.0.
Deployment: macOS, Linux e Windows.

Il repository attuale di Goose documenta il modello di provider ed estensioni. Le estensioni sono pacchetti di strumenti che permettono all'agente di agire su file o servizi collegati. Ogni estensione attivata cambia il lavoro che può tentare di svolgere.

Due dichiarazioni dei manutentori determinano se risponde al motivo della migrazione. La guida alle modalità dei permessi indica Autonomous come modalità predefinita. Una correzione nell'annuncio della sandbox macOS precisa inoltre che quella sandbox sperimentale è stata rimossa: il server che esegue gli strumenti opera con i permessi dell'utente, senza sandbox a livello di sistema operativo.

Goose è quindi una scelta di praticità, poco adatta a chi cambia soprattutto per ottenere maggiore isolamento.

1. 1

   Scegliere un primo compito circoscritto

   Usare una copia degli appunti di una riunione e chiedere una bozza delle azioni da intraprendere. Meglio evitare che il primo compito sia una modifica a un account reale.

2. 2

   Cambiare la modalità predefinita

   In Settings → Chat → Default Mode, scegliere Manual Approval. Le sessioni esistenti mantengono la propria modalità: va controllata anche quella che si sta per usare.

3. 3

   Esaminare ogni strumento attivato

   Nei permessi degli strumenti dell'estensione, selezionare Ask Before o Never Allow dove opportuno. Prima di ampliare gli accessi, verificare la bozza e ogni azione richiesta.

La guida ai permessi degli strumenti spiega i controlli per singolo strumento. Sono regole di approvazione: non creano una sandbox del sistema operativo.

OpenHands: portare lo sviluppo in un centro di controllo per agenti

OpenHands è un sistema di agenti per lo sviluppo software. Il repository principale attuale presenta Agent Canvas, un centro di controllo per agenti e automazioni. È adatto a un team che delega lavoro sui repository, gestione delle issue o attività di sviluppo ricorrenti su backend di esecuzione diversi. Un responsabile di piattaforma può organizzare questi lavori separatamente dall'assistente desktop personale di un dipendente. Se l'esigenza iniziale era solo un compagno di chat privato, si sta passando a un'altra categoria di prodotto.

Ideale per: Team di sviluppo che assegnano attività di programmazione e automazione.
Punto di forza: Un centro di controllo per backend locali, remoti e cloud.
Manutentori e licenza: Collaboratori del progetto OpenHands; MIT per il repository confrontato.
Deployment: Host locale o percorsi con Docker su macOS, Linux e Windows.

Il repository di OpenHands è particolarmente esplicito sulle opzioni di avvio. L'installazione diretta esegue il server dell'agente sulla macchina con pieno accesso al filesystem. Le modalità di avvio con Docker offrono un confine diverso, inclusa un'opzione che assegna a ogni conversazione il proprio container.

I container per conversazione non isolano in sandbox i servizi esterni di Canvas e automazione. Non separano nemmeno i file quando le conversazioni montano intenzionalmente lo stesso workspace dell'host. Per lavorare in parallelo sui repository, workspace distinti sono dunque un requisito operativo, non una preferenza organizzativa puramente estetica.

Prima di aggiungere colleghi, il team deve individuare un responsabile per l'accesso ai backend e per gli endpoint esposti. Il primo lavoro va limitato a una copia del repository e a un risultato verificabile. Il successo consiste nel permettere a un manutentore di esaminare la modifica e ripristinare il workspace, non semplicemente nell'ottenere dall'agente una dichiarazione di completamento.

Permessi e sandbox risolvono problemi diversi

L'approvazione risponde alla domanda “questa azione può essere eseguita?”. La sandbox risponde a “che cosa potrà raggiungere una volta avviata?”. Per un agente capace di scrivere file o eseguire una shell servono entrambe le risposte.

Si pensi a un armadio per attrezzature chiuso a chiave. La chiave stabilisce chi può aprirlo; il contenuto dell'armadio determina ciò che sarà disponibile dopo l'apertura. Un pulsante di approvazione su un host senza restrizioni non rende più piccolo l'armadio.

Prima della migrazione, per un compito reale vanno elencati cartelle leggibili, cartelle scrivibili, servizi raggiungibili e credenziali. L'installazione proposta va poi confrontata con quell'elenco. La guida generale agli agenti AI open source è utile quando i requisiti portano oltre questa selezione di assistenti personali.

Agenti gestiti per chi non vuole occuparsi dell'hosting

Quando il problema è gestire la macchina, conviene acquistare un servizio con un flusso di lavoro gestito. Anche un pacchetto open source più leggero lascia a qualcuno la responsabilità di aggiornamenti, disponibilità e ripristino.

Runable: ricerche e risultati pronti in un servizio gestito

Runable è adatto a chi deve fare ricerche, preparare documenti e presentazioni o costruire un sito, anziché mantenere il runtime di un agente locale. Le sue pagine descrivono anche flussi di lavoro da assistente personale tramite canali di comunicazione. Per chi guida un'azienda e chiede una sintesi di ricerca e una presentazione, c'è una sovrapposizione significativa con il lavoro che potrebbe svolgere un assistente OpenClaw.

Prezzi: Piano iniziale gratuito con 1,500 crediti giornalieri sulla pagina dei prezzi di Runable, controllata l'11 novembre 2026. Le cifre dei piani a pagamento non sono state visualizzate in modo affidabile durante la lettura della pagina pubblica: prima di abbonarsi, occorre confermare importo e periodo di fatturazione.

Va scelto per il risultato da ottenere. Non si deve presumere che un agente gestito mantenga l'accesso al filesystem locale, le skill esistenti o l'esatta configurazione di messaggistica. Bisogna verificare lo specifico servizio collegato e l'output necessario.

Viktor: il lavoro gestito entra nelle conversazioni del team

Viktor è adatto a un team operativo che vuole ottenere report e lavorare con strumenti collegati da Slack, Microsoft Teams o email. Il sito descrive approvazioni degli strumenti scelte dall'amministratore. Un report ricorrente per il team è quindi un punto di partenza più naturale rispetto a chiedere a ogni dipendente di mantenere una propria installazione dell'agente.

Prezzi: Piano iniziale gratuito con crediti fino a $100 sulla pagina dei prezzi di Viktor, controllata l'11 novembre 2026. La pagina mostrava diverse configurazioni del piano Team a pagamento: l'importo selezionato va verificato al checkout, senza trattare una singola cifra visualizzata come prezzo iniziale valido per tutti.

Il limite principale è il contesto condiviso. Le FAQ pubbliche di Viktor indicano che il workspace condivide un'istanza e il contesto, e sconsigliano di inserire informazioni personali sensibili nei messaggi diretti. Un workspace gestito non è automaticamente un insieme di assistenti personali privati. È adatto quando il lavoro condiviso del team è l'obiettivo; se serve una rigida separazione della memoria per utente, occorre fermarsi.

Come sono stati selezionati i progetti

Il confronto usa quattro criteri: se il progetto conserva la funzione necessaria, chi lo mantiene, quali accessi concede la configurazione documentata e se esistono un repository attuale e una cronologia delle release. Per tutti e sette i progetti richiesti erano disponibili fonti ufficiali aggiornate: nessuno è stato sostituito.

La verifica ha riguardato titolarità dei repository, licenze, piattaforme, riepiloghi delle release e pagine di sicurezza o configurazione collegate. La data di una release segnala manutenzione, non misura l'affidabilità. La documentazione del sorgente corrente può descrivere funzionalità successive a una release, soprattutto quando lo specifica il README: prima di trasformare questo confronto in un piano di installazione, va fissata la versione scelta.

Non è stato effettuato l'accesso ad alcun account e non è stato messo in esecuzione alcun agente. Le raccomandazioni derivano dai confini documentati, non da misurazioni delle prestazioni o classifiche delle vulnerabilità.

Le scelte da evitare

Evitare Goose se il motivo del passaggio è l'isolamento integrato a livello di sistema operativo. La comodità del desktop è utile, ma i manutentori dichiarano esplicitamente che il server degli strumenti non è isolato in sandbox.

Evitare NemoClaw se l'obiettivo è smettere di gestire infrastrutture. Cambia il modo in cui vengono eseguiti gli agenti supportati e aggiunge meccanismi per il ciclo di vita. Inoltre, resta in fase alpha.

Evitare una configurazione di Nanobot o ZeroClaw non verificata se serve la certezza dell'isolamento della shell. Entrambi documentano impostazioni o comportamenti di ripiego che rendono decisiva l'installazione effettiva.

Evitare OpenHands per sostituire una semplice chat personale. La complessità del suo centro di controllo per lo sviluppo è giustificata solo quando serve quel tipo di lavoro.

Il primo passo del lunedì è piccolo: scegliere il progetto che rimuove l'ostacolo principale, copiare un dato di ingresso a basso rischio in un workspace dedicato e richiedere un risultato verificabile. Gli accessi vanno ampliati solo quando quel flusso di lavoro lo richiede.

La mappa degli strumenti AI per chi guida un'azienda aiuta a collocare l'agente scelto nel resto del proprio flusso di lavoro.

Domande frequenti

Qual è la migliore alternativa a OpenClaw?

NanoClaw è il candidato più convincente di questa selezione per un agente personale di messaggistica che abbia l'isolamento al centro del progetto. Hermes Agent è adatto a memoria persistente e skill, ZeroClaw a una distribuzione più semplice e OpenHands al lavoro di sviluppo. Prima del nome, vanno scelti il compito e il perimetro di esecuzione.

Esistono alternative più sicure a OpenClaw?

Diversi progetti documentano controlli di isolamento e permessi che meritano una valutazione, ma questo non stabilisce una classifica universale di sicurezza. Vanno confrontati runtime effettivo, mount dei file, credenziali, policy di rete e impostazioni predefinite di approvazione. I container di NanoClaw e le policy OpenShell di NemoClaw rispondono a esigenze di deployment diverse.

C'è un'alternativa a OpenClaw più semplice da usare?

Goose è la scelta desktop locale per chi vuole un'interfaccia grafica e sa gestire i permessi degli strumenti. Se si vuole evitare del tutto la manutenzione di un server, Runable è adatto a ricerche e risultati in un servizio gestito, mentre Viktor è pensato per attività lavorative condivise. Prima della migrazione, occorre verificare il flusso di lavoro e i confini dei dati.