I 7 backend di sandbox di Hermes Agent: quando scegliere quale

Ogni installazione di Hermes Agent ha un'impostazione di sandbox che decide dove i comandi shell vengono eseguiti davvero. La scelta pesa: determina quanto è grande il raggio d'azione di un comando sbagliato, quanto veloce ti sembra l'agente, e quanto paghi per ora attiva.

Hermes porta sette backend. Il README li elenca tutti: local, docker, ssh, singularity, modal, daytona, vercel. v0.14.0 ha aggiunto Vercel Sandbox per chiudere la rosa. Ecco l'albero di decisione.

I 7 backend, in una tabella

local e docker sono gratis e girano sulla tua macchina. Gli altri cinque girano altrove — paghi in latenza, paghi in soldi, ma in cambio ti porti a casa qualcosa.

Quando scegliere quale

local — "Mi fido di questo agente su questa macchina"

L'agente lancia i comandi direttamente sul tuo filesystem con i tuoi permessi utente. Zero isolamento. Se l'agente decide rm -rf ~/code, lo fa. Se una prompt injection finisce nell'output di un tool, il comando iniettato gira.

Quando è la scelta giusta: stai smanettando su una VM usa-e-getta, l'agente fa cose che faresti tu a mano col stesso raggio d'azione, e la latenza a zero ti vale più del margine di sicurezza.

Quando è la scelta sbagliata: praticamente quasi sempre il resto del tempo.

docker — il default giusto

Un container sulla tua macchina, isolato dai namespace di Linux. La vista filesystem dell'agente è quella del container ; il tuo /home vero è nascosto a meno che tu non lo monti.

hermes config set sandbox docker e hermes setup tirano giù e configurano l'immagine. Da lì in poi, ogni chiamata di tool shell passa per il container.

Questo è il default giusto per circa l'80% degli utenti. L'overhead di latenza (~50 ms a comando) non si vede in chat. L'isolamento è abbastanza forte che un rm -rf / rade al suolo solo la vista del container, e il container è usa-e-getta. Se devi fare debug, ci entri con docker exec.

ssh — "L'agente vive su un'altra macchina"

I tool shell dell'agente girano via SSH su un host remoto. Il tuo processo Hermes locale è il client ; il lavoro succede sul remoto.

Questa è la scelta giusta quando il lavoro dell'agente appartiene al remoto — deploy verso un server, debug di log di produzione, esecuzione di migration. Non ti serve una sandbox locale perché l'host è la sandbox.

Il remoto deve essere un host a cui sei tranquillo a dare accesso shell all'agente. Tratta le credenziali SSH come credenziali di produzione, perché lo sono.

singularity — cluster HPC

Singularity (oggi Apptainer) è il runtime di container che i cluster HPC usano davvero, perché Docker richiede root sull'host e gli ambienti HPC non lo concedono. Se fai girare Hermes su un cluster di ricerca — schedulato da SLURM, senza Docker, pieno di GPU — questa è la scelta.

Se non riconosci le parole "HPC" o "Singularity", salta questa voce.

modal — calcolo a raffiche, soprattutto GPU

Modal è una piattaforma serverless per container. Hermes accende un container Modal per comando (o per sessione, riusando), esegue il comando, lo smonta. Paghi a secondo di compute attivo. Esistono fasce GPU.

Quando batte Docker: l'agente ha bisogno di GPU, o di risorse di calcolo oltre la tua macchina locale. Quando batte gli altri serverless: il cold start è circa 200 ms, accettabile per l'uso di tool al ritmo della chat, e lo snapshotting è abbastanza buono che lo stato a metà sessione sopravvive ragionevolmente.

daytona — lunga durata, quasi zero a riposo

L'asso nella manica di Daytona è la letargo. L'ambiente del tuo agente si addormenta quando non succede nulla e si sveglia su richiesta in qualche centinaio di ms. Paghi i secondi attivi, non quelli a riposo.

Effetto pratico: puoi avere un ambiente "il mio Hermes" coi tuoi dotfile, i tuoi skill, il lavoro in corso, che vive per mesi a costo quasi zero perché paghi solo quando lo usi.

Questa è la scelta se vuoi un agente che "vive da qualche parte" senza stare sul tuo laptop. La prima richiesta dopo una lunga inattività ci mette circa 300 ms a svegliarsi ; le successive vanno a velocità container.

vercel — Vercel Sandbox (v0.14.0)

Il backend più nuovo, aggiunto in v0.14.0. Stesso modello di container serverless di Modal, ma sull'infrastruttura di Vercel. Se hai già Vercel come target di deploy, è la scelta col minor attrito per tenere anche la sandbox dell'agente sullo stesso provider.

Più adatto a: flussi pesanti in JS dove vuoi che l'ambiente dell'agente rispecchi quello di produzione.

Come cambiare

hermes config set sandbox docker
# o: local, ssh, singularity, modal, daytona, vercel

Per i backend che vogliono credenziali (ssh / modal / daytona / vercel), hermes setup te le chiede ; oppure le imposti via hermes config set direttamente, come da doc.

Puoi anche fare un override per sessione se ti serve: hermes --sandbox modal per un singolo run che vuole una GPU, ritornando al tuo sandbox di default subito dopo.

E se non usassi affatto la sandbox?

Puoi disattivare il sandboxing del tutto (backend local), ma Hermes ci stratifica sopra un workflow di approvazione dei comandi: i comandi pericolosi come rm -rf, curl | sh o qualsiasi cosa che tocca /etc chiedono approvazione esplicita prima di girare. v0.14.0 ha irrobustito questo strato con tre chiusure di bypass di comando pericoloso e un blocco brute-force su sudo (#23736, #26829). Quindi nemmeno local è "niente" — è "isolamento più leggero ma con prompt veri". Vedi l'articolo sul modello di sicurezza per una scomposizione strato per strato.

La raccomandazione onesta

Per quasi tutti, quasi sempre: Docker.

Se vuoi che l'agente viva su un server che non è il tuo laptop: Daytona (il letargo da fermo è davvero magico e i conti tornano).

Se hai carichi GPU o l'agente fa calcolo serio: Modal.

Se sei un ricercatore su un cluster: Singularity.

Local solo se hai chiari i compromessi. SSH solo quando il lavoro appartiene al remoto. Vercel se sei già su Vercel.

Per approfondire

• •Release notes v0.14.0 — Vercel Sandbox aggiunta
• •Documentazione Hermes Agent — backend terminale
• •Repository di Hermes Agent