Siedem backendów sandboxa Hermes Agent: kiedy wybrać który

Każda instalacja Hermes Agent ma ustawienie sandbox, które decyduje, gdzie tak naprawdę wykonują się komendy shellowe. Wybór ma konsekwencje: decyduje, jaki promień rażenia ma zła komenda, jak szybki czuje się agent i ile płacisz za aktywną godzinę.

Hermes niesie siedem backendów. README je wymienia: local, docker, ssh, singularity, modal, daytona, vercel. v0.14.0 dorzucił Vercel Sandbox, żeby zaokrąglić listę. Oto drzewo decyzyjne.

Siedem backendów w jednej tabeli

local i docker są za darmo i na twojej maszynie. Pozostałe pięć chodzi gdzie indziej — płacisz latencją, płacisz dolarami, ale coś za to dostajesz.

Kiedy wybrać który

local — „ufam temu agentowi na tej maszynie"

Agent odpala komendy wprost na twoim filesystemie z uprawnieniami twojego usera. Zero izolacji. Jeśli agent zdecyduje się na rm -rf ~/code, to robi. Jeśli w outputie toola wyląduje prompt injection, wstrzyknięta komenda się odpala.

Kiedy to właściwy wybór: kodzisz na jednorazowej VM, agent robi rzeczy, które i tak zrobiłbyś sam z tym samym promieniem rażenia, a zero latencji liczy się bardziej niż margines bezpieczeństwa.

Kiedy to zły wybór: praktycznie każdy inny moment.

docker — właściwy domyślny

Kontener na twojej maszynie, izolowany przez linuksowe namespace'y. Widok filesystemu z perspektywy agenta jest widokiem kontenera; twój prawdziwy /home jest niewidoczny, jeśli go nie zamontujesz.

hermes config set sandbox docker plus hermes setup i obraz się ściągnie i skonfiguruje. Potem każde wywołanie shell-toola idzie przez kontener.

To właściwy default dla ~80% userów. Overhead latencji (~50 ms na komendę) jest niewidoczny w czacie. Izolacja jest na tyle mocna, że agent odpalający rm -rf / rozsadza tylko widok kontenera, a kontener jest jednorazowy. Trzeba zdebugować — docker exec w środek.

ssh — „agent mieszka na innym boksie"

Shell-toole agenta wykonują się po SSH na zdalnym hoście. Twój lokalny proces Hermesa to klient; remote to miejsce, gdzie dzieje się praca.

To właściwy wybór, kiedy agent robi pracę infrastrukturalną, która należy do remote'a — deploy na serwer, debug produkcyjnych logów, leci migracje. Lokalny sandbox nie jest potrzebny, bo host jest sandboxem.

Remote musi być hostem, na który zgadzasz się dać agentowi dostęp shellowy. SSH-credentialsy traktuj jak credentialsy produkcyjne, bo tym właśnie są.

singularity — klastry HPC

Singularity (teraz Apptainer) to runtime kontenerowy, którego klastry HPC naprawdę używają, bo Docker wymaga roota na hoście, a środowiska HPC tego nie dają. Jeśli odpalasz Hermesa na klastrze badawczym — z SLURM-em w harmonogramie, bez Dockera, z mnóstwem GPU — to właściwy wybór.

Jeśli słowa „HPC" albo „Singularity" nic ci nie mówią, omiń to.

modal — bursty compute, zwłaszcza GPU

Modal to serverless-owa platforma kontenerowa. Hermes stawia kontener Modal per komenda (albo per sesja, z reuse'em), odpala komendę i go zwija. Płacisz per sekunda aktywnego compute. Tier-y z GPU dostępne.

Kiedy to bije Dockera: agent potrzebuje GPU albo zasobów compute powyżej tego, co ma twój lokalny boks. Kiedy Modal bije inne serverless'y: cold start ~200 ms — akceptowalny dla tool-use w tempie czatu, a snapshotting jest na tyle dobry, że stan w środku sesji sensownie przeżywa.

daytona — długo żyjący, prawie zero w bezruchu

Killer-feature Daytony to hibernacja. Środowisko twojego agenta idzie spać, kiedy nic się nie dzieje, i budzi się na żądanie w kilkaset milisekund. Płacisz za aktywne sekundy, nie za sekundy bezruchu.

Praktyczny efekt: możesz mieć środowisko „mój Hermes" ze swoimi dotfile'ami, swoimi skillami i robotą w toku, które żyje miesiącami prawie za darmo, bo płacisz tylko, kiedy go używasz.

To właściwy wybór, jeśli chcesz agenta, który „gdzieś żyje", ale nie na twoim laptopie. Pierwszy request po długim bezruchu wymaga ~300 ms na obudzenie; kolejne lecą jak w kontenerze.

vercel — Vercel Sandbox (v0.14.0)

Najnowszy backend, dorzucony w v0.14.0. Ten sam model serverlessowych kontenerów co Modal, tylko na infrastrukturze Vercela. Jeśli i tak masz Vercela jako target deploymentu, to wybór o najmniejszym tarciu, żeby sandboxowanie agenta przerzucić na tego samego providera.

Najlepsze do: JS-ciężkich flow, w których chcesz, żeby środowisko agenta lustrzyło twoje środowisko produkcyjne.

Jak się przełączyć

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

Dla backendów, które chcą credentialsów (ssh / modal / daytona / vercel), hermes setup o nie zapyta; albo ustaw przez hermes config set wprost, zgodnie z dokumentacją.

Możesz też przesłonić per-sesja, jeśli trzeba: hermes --sandbox modal dla jednego biegu, który chce GPU, potem wracasz do swojego defaultowego sandboxa.

A co jeśli zero sandboxa?

Możesz całkowicie wyłączyć sandboxowanie (backend local), ale Hermes nakłada na to warstwę command-approval workflow: niebezpieczne komendy w stylu rm -rf, curl | sh albo cokolwiek dotykającego /etc zaprosi cię o jawne potwierdzenie przed odpaleniem. v0.14.0 utwardził tę warstwę zamknięciem trzech dangerous-command bypassów i blokadą brute-force'u na sudo (#23736, #26829). Czyli nawet local to nie „nic" — to „lżejsza izolacja, ale realne prompt-y". Po rozpisce warstwa-po-warstwie odeślę do posta o modelu bezpieczeństwa.

Konkretna rekomendacja

Dla większości ludzi, w większości sytuacji: Docker.

Chcesz, żeby agent siedział na serwerze, który nie jest twoim laptopem: Daytona (hibernacja-w-bezruchu jest naprawdę magiczna, a matematyka kosztów się klei).

Masz GPU-workloady albo agent robi prawdziwy compute: Modal.

Jesteś badaczem na klastrze: Singularity.

local tylko, jeśli rozumiesz kompromis. SSH tylko, kiedy robota należy do remote'a. Vercel, jeśli i tak siedzisz na Vercelu.

Dalsza lektura

• •Release notes v0.14.0 — dorzucony Vercel Sandbox
• •Dokumentacja Hermes Agent — backendy terminala
• •Hermes Agent na GitHubie