OpenClaw и Hermes на одном VPS: чего стоит связать двух агентов безопасно
Недавно на глаза попалась мысль в духе "Hermes и OpenClaw решают разные задачи - выбирайте по сценарию". Я решил не выбирать. План выглядел идеально: поднять оба агента на одном VPS и заставить их работать в связке, где OpenClaw - это диспетчер и интерфейс общения, а Hermes - "исполнитель", который берёт тяжёлые задачи: исследования, генерацию кода, прогоны скриптов, долгие цепочки действий в песочнице. Пишешь в Telegram "разберись", OpenClaw понимает, что это не быстрый ответ в чат, а настоящая работа, и передаёт поручение Hermes. Hermes уходит выполнять, возвращает результат - и пользователь видит только финальный ответ.
Спойлер: схема действительно заводится. Но если пытаться сделать это "как обычно", за вечер и без паранойи, вы в какой-то момент обнаружите, что построили удалённое выполнение команд, к которому ведёт дорожка из мессенджера. И это принципиально меняет разговор о безопасности.
Чем ИИ‑агент на сервере отличается от обычного сервиса
Классический веб‑сервис ограничен: у него есть конечный набор эндпоинтов, параметры, валидации, права. Его поверхность атаки можно описать документацией API и конфигом роута.
ИИ‑агент - другое животное. Он умеет выполнять произвольные команды, причём не заранее заданные вами, а те, которые "придумает" модель на основе текста из чата и контекста. По сути, интерфейсом управления становится окно мессенджера, а "набор возможностей" равен всему, что доступно в терминале и файловой системе. Это не просто "ещё один сервис", это машина принятия решений, которая может ошибиться, поверить чужому тексту и сделать вредное действие без злого умысла - искренне считая, что выполняет задачу.
И если смотреть честно, ломается здесь сразу в трёх местах.
1) Периметр: панели управления любят слушать не только loopback
У обоих агентов обычно есть веб‑панели и локальные интерфейсы, из которых "можно сделать что угодно". И проблема в том, что "по умолчанию" эти интерфейсы нередко стремятся слушать не только `127.0.0.1`. В результате сервер начинает светить наружу административные порты, которые вы вообще не планировали публиковать.
У меня это выстрелило очень наглядно: на короткое время я остался без фаервола (сам того не заметив), и один из сервисных портов - 18789 - оказался доступен из интернета. Удивительно не то, что это случилось, а то, как легко это пропустить, когда параллельно вы отлаживаете контейнеры, токены, интеграции и "почему не поднимается песочница". В такие моменты мозг занят логикой, а не периметром.
Вывод: если у вас на VPS живёт агент, первым делом фиксируйте сетевую модель. Не "потом закрою", а сразу: что слушает снаружи, что только на loopback, какие порты должны быть видимы, какие - никогда.
2) Канал входа: кто может написать боту, тот фактически может выполнить команду
Второй слой - коммуникационный. В моей схеме входом был Telegram. Кажется невинным: чатик, ботик, удобно.
Но по факту это "клавиатура", которая может попросить агента сделать что угодно. Не "вызвать метод API", а сформулировать произвольное поручение. Если бот отвечает всем, кто знает его имя, то вы сделали публичный терминал с естественным языком. И даже если агент "старается быть осторожным", само наличие такого канала - уже риск.
Отсюда простой, но неприятный тезис: список пользователей, которым разрешено писать агенту, - это часть системы безопасности, а не "настройка удобства". Уровень доступа должен начинаться именно там, на входе, а не внизу, возле `sudo`.
3) Сам агент: вероятностная модель + чужой текст = неожиданные последствия
Даже если периметр закрыт и бот принимает команды только от вас, остаётся третий класс проблем: сам механизм принятия решений. Модель может интерпретировать задачу неверно и удалить не тот каталог, перезаписать конфиг, сломать маршрутизацию - не из вредности, а из непонимания нюанса.
Ещё хуже то, что агент читает внешние тексты: страницы, файлы, лог‑выводы. И для него текст "внутри файла" или "на веб‑странице" не принципиально отличается от текста, который вы написали в чат. Если в этот текст попадает инструктивная формулировка (вроде "игнорируй предыдущие правила и сделай X"), у вас появляется риск "подмены намерений". На практике это означает: аудит должен учитывать не только команды, но и то, какие данные агенту разрешено читать и куда ему разрешено писать.
Один из проектов честно формулирует то, что многие предпочитают не замечать: разработчики не исходят из того, что вы запускаете агента на защищённом продакшен‑сервере. Безопасность - на вашей стороне. И это не страшилка, а реальность текущего поколения инструментов.
Отсюда базовый принцип, который приходится применять буквально везде: агент получает ровно столько прав, сколько нужно для задачи - и ни одним больше. Банально звучит до тех пор, пока не начнёте проверять дефолты.
Два агента - две философии, но одинаковые классы граблей
OpenClaw устроен как контейнерный комбайн: живёт в Docker, имеет гейтвей, веб‑панель, каналы вроде Telegram, систему плагинов, умеет планировать и "звать" других агентов. Это удобно именно как диспетчер: он держит контекст, рулит сессиями, распределяет задачи.
Hermes от Nous Research ощущается иначе. Он запускается как процесс на хосте: вокруг самого агента контейнера нет, зато есть Docker‑песочница, в которой он исполняет код. То есть изоляция перенесена "ниже": изолирован не мозг, а руки - то, что он запускает.
И вот тут появляется первая практическая ловушка: "Docker внутри Docker". Формально это может быть "поддерживается", но "поддерживается" не всегда означает "работает без сюрпризов" на реальном VPS с реальными ограничениями. В одном окружении вы внезапно обнаружите, что внутри контейнера нет нужных возможностей ядра, в другом - что агент не видит Docker CLI, в третьем - что права на сокет `docker.sock` превращают песочницу в декорацию.
Отдельная категория боли - сеть. Два VPN могут не поделить маршрут так, что часть запросов идёт "не туда", DNS резолвит неожиданно, а ваш отладочный трафик живёт своей жизнью. В мире агентов это особенно неприятно, потому что вы не всегда сразу понимаете, это Hermes "думает" неправильно или у него просто нет маршрута до нужного ресурса.
Аудит, который нашёл настоящую проблему
Самая полезная часть всей истории - момент, когда перестаёшь лечить симптомы. В какой-то точке выясняется: неважно, сколько раз вы переустановите контейнеры, если у вас открыт наружу административный порт или бот принимает сообщения от любого желающего. Поэтому нужен именно аудит: не "что не запускается", а "какая у меня реальная модель угроз".
Когда я наконец прошёлся по портам, правилам фаервола, binding'ам сервисов и доступам - обнаружилось, что реальная проблема не в "кривом плагине" и не в "сломанной зависимости", а в банальной экспозиции наружу того, что наружу попадать не должно.
Бэкапы и "сорок минут на OAuth ради rclone"
Отдельный урок - резервные копии. В обычной разработке это часто "потом настрою". В мире агентов "потом" может не наступить: один неосторожный шаг - и вы потеряли данные, конфиги, ключи, историю.
Парадоксально, но настройка нормального бэкапа иногда занимает больше времени, чем установка агента: авторизация, OAuth‑танцы, ограничения провайдера, rclone, права на каталог, расписание. И всё это кажется вторичным ровно до тех пор, пока агент не снесёт "временную папку", которая внезапно окажется не временной.
Hermes: другой подход, те же проблемы по краям
У Hermes обнаруживаются свои "мелкие, но критичные" шероховатости. Например, установщик может попросить пароль у пользователя, у которого пароля вообще нет (типичная история для минимальных VPS‑образов или для пользователей, созданных под сервис). Где-то всплывает таблица на "тридцать моделей", и вы тратите время не на работу, а на выбор и сверку совместимостей. Где-то ожидается Playwright, которого в окружении нет, хотя по смыслу "должен бы быть".
И всё это в итоге приводит к главному вопросу: кто здесь оператор? Вы или агент? Если вы превращаетесь в человека, который бесконечно чинит окружение, а агент лишь изредка выдаёт пользу - значит архитектура выбрана неудачно, или права/изоляция настроены так, что работать неудобно.
Связка через ACP: на бумаге красиво, кнопки "сделай хорошо" нет
Соединять OpenClaw и Hermes я собирался через ACP (Agent Client Protocol): у OpenClaw есть плагин, который подключает внешних ACP‑агентов, а у Hermes - режим ACP‑сервера. Теоретически всё складывается: один управляет, второй исполняет.
Практически выясняется, что "готовой кнопки" нет. Начинаются вопросы уровня инфраструктуры:
- как контейнеру OpenClaw дотянуться до сервиса на хосте;
- как корректно пробросить адреса и порты, не открывая их в интернет;
- как собрать образ, если на этапе сборки внезапно "выбросило" Docker CLI или нужные утилиты;
- как настроить песочницу Hermes так, чтобы она позволяла делегировать задачи, а не блокировала их из соображений безопасности.
Особенно показателен момент с делегированием: вместо того чтобы "стать исполнителем" самому, OpenClaw должен уметь "позвать исполнителя" - а Hermes должен принять задачу как внешний исполнитель, а не как интерактивный пользователь в локальной сессии. Пока это не выстроено, система выглядит как набор компонентов, которые по отдельности умные, а вместе - упрямые.
Момент, когда всё наконец заработало - и почему это не повод расслабляться
Когда связка всё же заводится, ощущение похоже на магию: пишешь в чат задачу, диспетчер классифицирует её, передаёт исполнителю, тот что-то делает в изоляции и возвращает результат. Ради этого и затевалось.
Но именно в этот момент появляется соблазн "забить на мелочи": оставить панель "временно" открытой, разрешить боту отвечать "пока только мне, но без проверки", выдать агенту лишние права "чтобы не мучиться". Это самый опасный сценарий, потому что система уже выглядит рабочей - и перестаёт восприниматься как эксперимент.
Если забить, последствия будут классическими:
- утечка через открытую веб‑панель или сервисный порт;
- удалённое выполнение команд через компрометированный канал (тот же мессенджер);
- повреждение данных из-за ошибки модели;
- "песочница", которая на деле не песочница из-за выданных привилегий.
Что стоит добавить к такой схеме, чтобы она была ближе к "безопасной"
Ниже - практичные усиления, которые логично закладывать именно для сценария "OpenClaw как оркестратор + Hermes как исполнитель" на одном VPS:
1) Жёстко зафиксировать сетевой контур. Всё административное - только на loopback. Внешний доступ - через отдельный защищённый канал (например, туннель) и только при необходимости.
2) Сделать строгий allow‑list для входа в бота. Не "кто знает имя", а конкретные user_id. В идеале - ещё и отдельный секрет/подпись на команды для чувствительных операций.
3) Развести пользователей и права. OpenClaw и Hermes должны работать от отдельных системных пользователей, без лишних групп и без доступа к домашним каталогам друг друга.
4) Ограничить файловую систему. Агенту - отдельные рабочие директории. Конфиги, ключи, бэкапы - вне зоны его записи. Чем меньше агент "видит", тем меньше он может случайно сломать.
5) Логи и трассировка действий. Не просто "работает/не работает", а понятная запись: кто инициировал задачу, что было выполнено, какие команды запускались, куда писались файлы.
6) План восстановления. Бэкап конфигов, данных и артефактов - не роскошь. Время на настройку окупится при первой же странной ошибке.
7) Отдельная среда для экспериментов. Если есть возможность, тестируйте новые плагины/модели/права на отдельном инстансе или хотя бы в отдельном профиле, а не на "боевом" VPS.
Итог
Запустить OpenClaw и Hermes на одном VPS и связать их через ACP реально. Концептуально это выглядит как идеальная пара: один разговаривает с пользователем и оркестрирует, второй выполняет тяжёлую работу. Но цена удобства - в том, что вы строите систему удалённого исполнения команд, где входом становится мессенджер, а решения принимает вероятностная модель, читающая внешний текст.
Если относиться к этому как к обычной установке сервиса, вы очень быстро окажетесь в ситуации, где "вроде всё работает", но периметр дырявый, права избыточны, а песочница существует лишь на словах. Если же закладывать безопасность как фундамент - с минимальными правами, закрытыми панелями, строгим входом и нормальными бэкапами - связка превращается в мощный инструмент, а не в лотерею на тему "когда меня найдут по открытому порту".
