Семь sandbox-бэкендов Hermes Agent: когда какой брать

У каждой установки Hermes Agent есть настройка sandbox, которая решает, где shell-команды реально исполняются. Выбор последствий: он определяет, какой blast radius у плохой команды, насколько шустрым ощущается агент, и сколько ты платишь за активный час.

Hermes везёт семь бэкендов. README их перечисляет: local, docker, ssh, singularity, modal, daytona, vercel. v0.14.0 добавил Vercel Sandbox — состав закрыт. Вот дерево решений.

Все семь бэкендов в одной таблице

local и docker — бесплатные, на твоей машине. Остальные пять крутятся где-то ещё — платишь latency и долларами, но что-то взамен ты тоже получаешь.

Когда какой брать

local — «я доверяю этому агенту на этой машине»

Агент запускает команды прямо на твоей файловой системе с правами твоего юзера. Никакой изоляции. Если агент решит rm -rf ~/code, он это и сделает. Если в tool-выводе зашита prompt injection, инъецированная команда тоже отработает.

Когда это правильный выбор: ты ковыряешь одноразовую VM, агент делает ровно то, что ты бы сам сделал руками с тем же blast radius, а нулевая задержка важнее запаса по безопасности.

Когда это неправильный выбор: примерно во всех остальных случаях.

docker — правильный дефолт

Контейнер на твоей машине, изолированный Linux namespace'ами. Вид файловой системы агента — это вид контейнера; твой настоящий /home не видно, если ты сам не примонтируешь.

hermes config set sandbox docker плюс hermes setup — образ подтянется и сконфигурится. Дальше каждый shell-tool-вызов идёт через контейнер.

Это правильный дефолт для ~80% пользователей. Накладные расходы на latency (~50 мс на команду) в чате не видны. Изоляция достаточно крепкая — агент, который запустит rm -rf /, разнесёт только вид контейнера, а контейнер одноразовый. Понадобится подебажить — заходишь docker exec.

ssh — «агент живёт на другой машине»

Shell-tool'ы агента исполняются по SSH на удалённом хосте. Твой локальный Hermes-процесс — клиент; работа происходит на удалёнке.

Это правильный выбор, когда работа агента принадлежит удалёнке — деплоить на сервер, дебажить продовые логи, гонять миграции. Локальный sandbox не нужен, потому что сам хост и есть sandbox.

Удалёнка должна быть хостом, с тем что у агента есть shell-доступ. К SSH-credentials относись как к продовым, потому что они и есть продовые.

singularity — HPC-кластеры

Singularity (сейчас Apptainer) — это контейнер-runtime, которым HPC-кластеры реально пользуются, потому что Docker требует root на хосте, а HPC-окружения этого не дают. Если ты крутишь Hermes на research-кластере — SLURM-расписание, никакого Docker, много GPU — это правильный выбор.

Если слова «HPC» и «Singularity» тебе ничего не говорят — пропускай этот пункт.

modal — burst-вычисления, особенно GPU

Modal — это serverless-контейнер-платформа. Hermes поднимает Modal-контейнер на команду (или на сессию, с переиспользованием), запускает команду и сворачивает. Платишь за активные секунды compute. Доступны GPU-tier'ы.

Когда это бьёт Docker: агенту нужны GPU или ресурсы compute больше твоей локальной коробки. Когда Modal бьёт другие serverless: холодный старт ~200 мс — приемлемо для tool-use в темпе чата, а snapshotting достаточно хорош, чтобы внутрисессионное состояние сохранялось пристойно.

daytona — долгоживущий, простой почти даром

Killer-feature Daytona — гибернация. Среда твоего агента засыпает, когда ничего не происходит, и просыпается по запросу за пару сотен миллисекунд. Платишь за активные секунды, не за idle.

Практический эффект: можно держать «my Hermes»-среду со своими dotfiles, своими скилами, своей работой в процессе — и она живёт месяцами почти бесплатно, потому что ты платишь только когда реально пользуешься.

Это правильный выбор, если ты хочешь, чтобы агент «где-то жил», но не на твоём ноутбуке. Первый запрос после долгого простоя — ~300 мс на пробуждение; последующие — на скорости контейнера.

vercel — Vercel Sandbox (v0.14.0)

Самый свежий бэкенд, добавлен в v0.14.0. Та же serverless-контейнер-модель, что у Modal, только на инфре Vercel'а. Если у тебя Vercel уже как target деплоя, это самый низкотрильный способ положить agent-sandbox на того же провайдера.

Лучше всего для: JS-тяжёлых потоков, где ты хочешь, чтобы среда агента зеркалила твою прод-deploy-среду.

Как переключиться

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

Для бэкендов, которым нужны credentials (ssh / modal / daytona / vercel), hermes setup спросит у тебя; или ставь через hermes config set напрямую, согласно докам.

При необходимости можно переопределять per-session: hermes --sandbox modal для одного прогона, которому нужен GPU, — потом возвращаешься к дефолтному sandbox.

А что если совсем без sandbox?

Можно отключить sandbox целиком (local-бэкенд), но Hermes поверх кладёт workflow одобрения команд: опасные команды вроде rm -rf, curl | sh или всего, что лезет в /etc, перед запуском попросят явное «да». v0.14.0 закрепил этот слой — три закрытых dangerous-command bypass'а и блокировка sudo brute-force (#23736, #26829). Так что даже local — это не «ничего», это «менее серьёзная изоляция, зато реальные prompt'ы». Послойный разбор — в посте про модель безопасности.

Реальная рекомендация

Большинству людей, в большинстве случаев: Docker.

Если хочешь, чтобы агент жил на сервере, который не твой ноут: Daytona (свойство «спит, пока простаивает» — реально магическое, и арифметика по деньгам сходится).

Если у тебя GPU-нагрузки или агент делает настоящие вычисления: Modal.

Если ты исследователь на кластере: Singularity.

local — только если ты понимаешь компромисс. SSH — только когда работа принадлежит удалёнке. Vercel — если ты уже на Vercel.

Дальше

• •Release notes v0.14.0 — добавлен Vercel Sandbox
• •Документация Hermes Agent — терминальные бэкенды
• •Проект Hermes Agent на GitHub