Как оставить Hermes Agent работать на сервере круглосуточно

Когда я поставил Hermes Agent на ноутбук, сразу зацепило: а кто будет отвечать в Telegram и собирать мне утренние сводки, когда ноутбук закрыт? На столе агент живёт ровно до тех пор, пока включён компьютер. Чтобы бот был онлайн всегда и задачи по расписанию шли сами, агента надо перенести на сервер.

Ниже я по шагам показываю, как это делаю: ставлю Hermes на обычный Linux-сервер, превращаю его шлюз в службу, которая держится постоянно и поднимается сама после перезагрузки, и закрываю доступ, чтобы чужой в терминал не попал. Всё по официальной документации и по тому, как у меня это крутится на сервере прямо сейчас.

Если ты ещё не ставил Hermes вообще, начни с отдельного разбора - что это за агент и как его установить. Здесь я считаю, что на своей машине он у тебя уже работает, и речь только про перенос на сервер.

В Telegram-канале - что нового в вайб-кодинге: инструменты, находки, ошибки. Подпишись, чтобы быть в курсе.

Зачем переносить Hermes Agent с ноутбука на сервер?

На ноутбуке Hermes работает, только пока крышка открыта и ты рядом. Закрыл - бот замолчал, утренняя сводка не пришла. Для задачи «отвечай людям в мессенджере и делай дела по расписанию» это не годится.

Сервер этим и отличается - он не спит никогда и ни от чего не зависит. Ты ставишь на него того же самого Hermes, и он крутится без тебя: отвечает в Telegram в три часа ночи, каждое утро собирает новости по твоим темам, держит сессии между запусками.

Перенос нужен, когда у тебя появилась постоянная задача для агента: бот для себя или команды, утренние сводки, автоответы, регулярная работа с документами. Если ты просто пробуешь Hermes под конкретный проект и сидишь рядом - сервер пока не нужен, это лишний шаг.

Что подготовить до установки Hermes на VPS?

Перед установкой собери три вещи.

Сам сервер. Подойдёт обычный VPS с Linux. В документации первый уровень поддержки - Linux и WSL2, тестируют на последней Ubuntu; если в системе есть glibc, systemd и привычная раскладка папок, Hermes встанет нормально. Для сервера это критично: весь автозапуск ниже держится на systemd, а на Ubuntu и Debian он идёт из коробки.

Доступ по SSH. На сервер ты заходишь через терминал по SSH, мышкой там не поработаешь. Все команды ниже выполняются в этой SSH-сессии. Если вайб-кодишь и с терминалом пока на «вы» - не страшно, команд немного и все они копируются целиком.

Выбранную модель. Агент сам не думает, он ходит к модели. Для сервера, который работает без тебя, важно, чтобы вход в модель не протухал. Самый спокойный вариант - подписка Nous Portal через hermes setup --portal: вход идёт по OAuth, и токен обновляется автоматически. Свои ключи API тоже работают, но тогда следи, чтобы на счёте были деньги - беспилотный агент с пустым балансом просто замолчит. Требование к модели одно: контекст не меньше 64 000 токенов, иначе Hermes откажется с ней стартовать. Все облачные модели из списка это проходят.

Как установить Hermes Agent на сервер одной командой?

На сервере установка почти такая же, как на ноутбуке, с одним отличием: браузер агенту там обычно не нужен. А его автоматика тянет за собой тяжёлый Chromium. Поэтому ставлю с флагом --skip-browser.

1. Зайди на сервер по SSH

   bash

   ssh root@адрес-твоего-сервера

   Дальше все команды выполняются уже внутри этой сессии, на самом сервере.

2. Запусти установщик без браузера

   bash

   curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash -s -- --skip-browser

   Скрипт сам докачает нужное окружение и поставит команду hermes. Флаг --skip-browser пропускает установку браузерной автоматики - на сервере без графики она только место занимает. Если позже браузер всё-таки понадобится, его можно доставить отдельно.

3. Перезапусти оболочку и выбери модель

   bash

   source ~/.bashrc
   hermes setup --portal

   Первая строка подхватывает свежий PATH, чтобы команда hermes нашлась. Вторая открывает вход в Nous Portal: подтверждаешь вход, и агент получает модель и сервисы без отдельных ключей на каждый.

4. Проверь установку

   bash

   hermes doctor

   Команда показывает, что встало, чего не хватает и как починить. Зелёные отметки - всё на месте.

Перед тем как вешать бота и расписание, добейся одного чистого диалога прямо на сервере: запусти hermes, дай простую задачу с проверяемым ответом. Документация прямо советует не наваливать функции, пока не работает обычный разговор - совет дельный, я и сам пару раз наваливал лишнего раньше времени.

Хочешь, чтобы агент на сервере помнил твой бизнес и работал стабильно? Память и скиллы Hermes - это и есть готовый Второй мозг, как я его называю. На практикуме за три вечера собираешь всю связку под себя: ИИ-клон + Второй мозг + Контекст-инжиниринг - именно она превращает ИИ из «помощника с галлюцинациями» в рабочий инструмент.

Как сделать, чтобы Hermes работал круглосуточно?

Шлюз (gateway) - это единый фоновый процесс Hermes, который держит связь со всеми мессенджерами, ведёт сессии и выполняет задачи по расписанию. Вся круглосуточная работа крутится вокруг него. Задача - сделать так, чтобы этот процесс запускался сам и не падал.

Сначала настрой шлюз и подключи мессенджер:

hermes gateway setup

Мастер проведёт по платформам, поможет вставить токен бота и список доступа. По шагам связка с Telegram (создать бота у BotFather, узнать свой ID, вставить токен) разобрана в основном материале про установку - здесь не повторяюсь.

Дальше - та самая ловушка, про которую чаще всего забывают. Если просто запустить hermes gateway, процесс будет жить, пока открыта SSH-сессия. Закрыл терминал - шлюз остановился. Чтобы он работал постоянно, его надо отдать под управление системе. Для этого есть одна команда:

hermes gateway install

Она ставит шлюз как службу: на Linux - пользовательскую службу systemd, на macOS - через launchd. Система сама следит за процессом и поднимает его, если он упал.

Для сервера чаще нужен второй вариант - системная служба, которая стартует при загрузке машины, ещё до входа любого пользователя:

sudo hermes gateway install --system

Это ровно то, что нужно для VPS: сервер перезагрузился - служба поднялась сама, бот снова онлайн. Управляется всё понятными командами:

hermes gateway start     # запустить
hermes gateway stop      # остановить
hermes gateway status    # проверить состояние

Для системной службы к этим командам добавляется sudo и флаг --system. Без него они обратятся к пользовательской службе, а не к той, что стартует при загрузке:

sudo hermes gateway start --system
sudo hermes gateway stop --system
hermes gateway status --system

Зачем нужен linger и что без него ломается?

Это самое частое место, где спотыкаются: службу поставил, а бот ночью всё равно замолкает. Причина - в том, как устроены пользовательские службы в Linux.

Пользовательская служба systemd по умолчанию привязана к твоему сеансу. Ты зашёл по SSH - менеджер твоего пользователя запустился, служба работает. Вышел - система считает, что пользователь больше не активен, и гасит его службы вместе с твоим шлюзом. Для сервера, куда ты заходишь и выходишь, это провал: бот онлайн ровно пока ты в SSH.

Чинится это режимом linger - разрешением системе держать менеджер пользователя запущенным, даже когда тот никуда не вошёл:

sudo loginctl enable-linger имя-пользователя

После этой команды пользовательская служба работает сама по себе и поднимается при загрузке сервера, не дожидаясь твоего входа. Без linger всё вернётся к исходному: шлюз гаснет на выходе из SSH и не стартует при загрузке - это прямо сказано в доке.

Как запустить Hermes на сервере в Docker с авто-перезапуском?

Docker - второй рабочий путь держать агента на сервере, особенно если ты уже привык к контейнерам или хочешь изолировать агента от основной системы. Настройку делают один раз через docker run ... setup, а потом поднимают контейнер в фоне:

docker run -d \
  --name hermes \
  --restart unless-stopped \
  -v ~/.hermes:/opt/data \
  -p 8642:8642 \
  nousresearch/hermes-agent gateway run

Разберу строки, которые отвечают за круглосуточность:

• -d - контейнер работает в фоне, не держит твой терминал.
• --restart unless-stopped - Docker сам поднимает контейнер после перезагрузки сервера и после падения. Не поднимет только если ты остановил его руками.
• -v ~/.hermes:/opt/data - настройки, ключи, сессии и память лежат на сервере, снаружи контейнера, и переживают его пересоздание.

Ещё образ подстраховывает сам: процесс шлюза внутри работает под присмотром супервизора s6. Если шлюз упал, его перезапускают за пару секунд, не теряя сам контейнер. Выходит двойная страховка: снаружи контейнер держит Docker, внутри за самим процессом следит s6.

Одно отличие Docker-пути помни заранее: такие установки не обновляются командой hermes update. Обновление в Docker делается заменой образа на новый - выкачал свежий и пересоздал контейнер.

Как проверить, что всё работает и переживёт перезагрузку?

Для пользовательской службы состояние и логи смотрят так:

systemctl --user status hermes-agent
journalctl --user -u hermes-agent -f

Первая команда показывает, запущена ли служба. Вторая открывает живой поток логов - удобно держать в отдельном окне, когда проверяешь бота. Логи самого Hermes лежат в папке ~/.hermes/logs/, и секреты в них автоматически затираются, так что их не страшно переслать в поддержку.

Теперь перезагрузи сервер и убедись, что агент вернулся сам - для сервера это и есть главный тест, а про него обычно и забывают:

sudo reboot

Подожди минуту, зайди обратно по SSH, проверь hermes gateway status и напиши боту в Telegram. Ответил без твоего участия - значит, автозапуск настроен верно. Собственно, ради этого всё и делалось.

Бояться за переписку не нужно. Сессии в Hermes пишутся на диск и переживают перезапуск шлюза. Больше того: если шлюз упал ровно в момент отправки ответа, после восстановления он дошлёт этот ответ и не станет прогонять задачу заново. Для круглосуточного бота это важно - случайный перезапуск не рвёт разговор.

Как обезопасить агента с доступом к терминалу на сервере?

Агент на сервере - это программа с доступом к терминалу, которая работает без твоего присмотра. Три настройки, которые я проверяю в первую очередь.

Закрытый доступ к боту. По умолчанию шлюз отвечает только тем, кто в списке доступа или прошёл привязку по коду в личке. Это правильное поведение для бота с доступом к терминалу: случайный человек, написавший боту, ничего не сделает. Список задаётся по числовым ID, например для Telegram:

TELEGRAM_ALLOWED_USERS=123456789,987654321

Подтверждение опасных команд. Перед тем как выполнить что-то разрушительное, агент спрашивает у тебя разрешение. Есть режим YOLO, где подтверждения отключены, - на сервере, который работает без тебя, я бы его не включал. Смысл подтверждений ровно в том, чтобы без твоего ведома ничего необратимого не случилось.

Песочница для полной изоляции. Если хочешь, чтобы агент физически не видел основную систему сервера, его команды запускают в контейнере Docker:

hermes config set terminal.backend docker

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

Что делать, если бот молчит или шлюз падает?

Когда бот перестал отвечать, порядок такой. Сначала смотришь, жива ли служба и что в логах (systemctl --user status hermes-agent и journalctl). Если шлюз запущен, а сообщения не доходят - почти всегда дело в настройке платформы: не тот токен бота или человек не в списке доступа. Лечится повторным hermes gateway setup и проверкой hermes gateway status.

Если модель отвечает пусто или странно - перепроверь её через hermes model и подтверди провайдера и вход. Общий порядок восстановления, который возвращает из «всё сломалось» в рабочее состояние: hermes doctor, hermes model, hermes setup, hermes gateway status.

Отдельно - для редкого, но неприятного случая, когда весь процесс подвис и даже не падает по-честному. У systemd-службы есть сторожевой таймер: добавь в ~/.hermes/config.yaml строку и пересобери службу.

gateway:
  systemd_watchdog_seconds: 120

hermes gateway install --force

После этого шлюз регулярно подаёт системе сигнал «я жив», и если сигналы прекратились - systemd перезапускает процесс сам. Работает это только на Linux с systemd и именно для зависаний процесса. Обычный обрыв сети до мессенджера сторожевой таймер не трогает.

Что ещё спрашивают про Hermes Agent на сервере?

Полная схема вайб-кодинга за три вечера: ИИ-клон + Второй мозг + Контекст-инжиниринг. Записи эфиров в личном кабинете, доступ 30 дней.