Как я подключил Hermes Agent к серверам, Obsidian, почте и разделил на Telegram-ботов

❯ Мои проблемы

Сейчас я развиваюсь в DevOps, системном администрировании и смежных с ними направлениях. Для обучения ^[1] и работы веду собственную базу знаний в Obsidian по системе Zettelkasten, храню планы и заметки. Подробнее о том, как я организовал свою базу знаний, можно почитать в одной из моих предыдущих статей ^[2].

Кроме того, у меня есть собственный проект ServeHub-2. Он позволяет быстро развернуть инфраструктуру из двух серверов — локального и удалённого, объединённых в одну сеть, — с набором сервисов для решения различных задач. Проект создавался прежде всего для личного использования, но также может быть полезен тем, кто хочет получить готовую self-hosted-инфраструктуру с необходимыми инструментами обслуживания. Подробнее о нём можно почитать на GitHub ^[3]. Внедрение Hermes фактически является частью этого проекта, поэтому гайд по настройке находится там.

Наконец, у меня есть три почтовых ящика, которые приходится регулярно проверять. Из-за этого я периодически пропускаю важные письма или просто забываю заглянуть во входящие.

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

Конечно, для инфраструктуры у меня уже есть система мониторинга и алертинга. Она реагирует на заранее определённые события и сообщает о проблемах, но не всегда позволяет быстро разобраться в ситуации целиком. Для работы с Obsidian можно писать собственные скрипты, а для почты существуют отдельные инструменты. Однако в итоге получается набор разрозненных решений, которыми неудобно управлять.

❯ Решение?

Я решил попробовать объединить часть этих задач с помощью Hermes Agent. Для этого арендовал дополнительный сервер в Timeweb Cloud ^[4], подключил его к ServeHub-2 и развернул на нём агента. Я разделил его на отдельные профили с собственными Telegram-ботами: один предназначен для работы с базой знаний, второй — для аудита серверов, третий — для мониторинга почты.

Локальные нейросети я пока не рассматриваю. По моему опыту ^[5], качество и удобство работы с ними заметно уступают использованию моделей через API, поэтому для этого проекта я выбрал облачный вариант.

В качестве основной модели использую DeepSeek V4 Flash. Она хорошо справляется с моими задачами, а стоимость использования API остаётся приемлемой.

❯ Что такое Hermes Agent и почему он

Hermes Agent ^[7] — это ИИ-агент с открытым исходным кодом, который умеет выполнять задачи с помощью инструментов, работать с файлами и командной строкой. Его возможности расширяются с помощью навыков (skills), а отдельные профили позволяют разделять задачи и настройки.

Одна из особенностей Hermes — встроенный механизм самоулучшения. Агент может сохранять полезную информацию о предыдущих задачах в долговременной памяти ^[8], создавать собственные навыки и дорабатывать их по мере использования. Это позволяет постепенно адаптировать окружение агента к моим задачам без необходимости каждый раз начинать с нуля. При этом речь идёт об улучшении памяти ^[9], навыков и рабочего процесса, а не о самостоятельном переобучении базовой модели.

Понятное дело, это всё на словах. Тот же OpenClaw ^[10] тоже обладает широкими возможностями и, вероятно, справился бы с моими задачами. Тем не менее в моём случае Hermes оказался удобнее благодаря встроенным механизмам и тому, что многое необходимое для моего сценария доступно сразу после установки.

❯ Особенности архитектуры

Hermes работает на отдельном сервере, подключённом к сети моего проекта. Он может подключаться к двум другим серверам: удалённому VPS и домашнему серверу. Доступ к их внутренним сервисам и точкам входа настроен только через виртуальную сеть 10.8.0.0/24.

Использование защищенной сети также позволяет Hermes подключаться к другим устройствам в сети без необходимости открывать для них порты в интернете или настраивать проброс портов на роутере. Главное условие — устройство должно быть подключено к этой сети, а доступ к нему должен быть настроен заранее. В дальнейшем это позволит подключать новые устройства и расширять возможности автоматизации.

❯ Настройка контейнера клиента

Кратко разберу настройку клиента. Полную инструкцию можно найти в репозитории ^[3]. Здесь покажу основные файлы конфигурации.

x-logging: &default-logging
  driver: "json-file"
  options:
    max-size: "10m"
    max-file: "3"

services:
  amnezia-client:
    build:
      context: .
      dockerfile: Dockerfile.amnezia
    container_name: amnezia-client
    restart: unless-stopped
    cap_add:
      - NET_ADMIN             # Права на управление сетевым стеком и правилами маршрутизации
      - SYS_MODULE            # Права на загрузку модулей ядра ОС
    devices:
      - /dev/net/tun:/dev/net/tun # Проброс виртуального сетевого адаптера (TUN) с хоста
    volumes:
      - ./apps-data/amnezia:/config
      - /lib/modules:/lib/modules:ro # Монтирование модулей ядра хоста для работы драйверов
    logging: *default-logging
    network_mode: "host"      # Использование сетевого интерфейса хоста напрямую без изоляции Docker
    healthcheck:
      test: ["CMD-SHELL", "awg show | grep interface || exit 1"] # Проверка работоспособности интерфейса Amnezia WireGuard
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 10s

#!/bin/bash
find /etc/amnezia/amneziawg -mindepth 1 -delete

COUNTER=0
for s in $(find /config -name "*.conf")
do
  if test -f ${s}
  then
    COUNTER=$(( COUNTER + 1 ))
    basename=$(basename ${s})
    name=${basename%.conf}
    echo awg interface "${name}" will be created from config file "${basename}"
    cp ${s} /etc/amnezia/amneziawg/${name}.conf
    chmod 600 /etc/amnezia/amneziawg/${name}.conf
    awg-quick up ${name} # Подъем интерфейса через утилиту
  fi
done

if [[ $COUNTER -lt 1 ]]
then
  echo "There are no config files in the /config folder"
fi

sleep infinity # Удержание контейнера в запущенном состоянии, чтобы процесс не завершился сразу после инициализации

#!/bin/bash
find /etc/amnezia/amneziawg -mindepth 1 -delete

COUNTER=0
for s in $(find /config -name "*.conf")
do
  if test -f ${s}
  then
    COUNTER=$(( COUNTER + 1 ))
    basename=$(basename ${s})
    name=${basename%.conf}
    echo awg interface "${name}" will be created from config file "${basename}"
    cp ${s} /etc/amnezia/amneziawg/${name}.conf
    chmod 600 /etc/amnezia/amneziawg/${name}.conf
    awg-quick up ${name} # Подъем интерфейса через утилиту
  fi
done

if [[ $COUNTER -lt 1 ]]
then
  echo "There are no config files in the /config folder"
fi

sleep infinity # Удержание контейнера в запущенном состоянии, чтобы процесс не завершился сразу после инициализации

❯ Чем отличаются три профиля Hermes Agent

❯ Первый основной бот: Obsidian и другие задачи

Для первого бота я использовал профиль default, практически не меняя его настройки. В отличие от остальных, у него нет фиксированного расписания: я обращаюсь к нему по мере необходимости. Помимо работы с Obsidian, его можно использовать для разовых задач, которые проще делегировать агенту, чем выполнять самостоятельно.

Моё хранилище построено на системе Zettelkasten и хранится в отдельном Git-репозитории на Gitea. Я веду там технические заметки, планы, шпаргалки и другие материалы. Поэтому в качестве основного примера рассмотрим именно работу с этим хранилищем.

Настройка доступа

Поскольку Hermes работает в Docker, контейнеру необходимо предоставить доступ к нужным файлам. Для этого в ~/.hermes/config.yaml я добавил следующие тома:

terminal:
  backend: docker
  docker_volumes:
    - "/home/r9888/.ssh/id_ed25519:/root/.ssh/id_ed25519:ro"
    - "/home/r9888/main-vault:/root/main-vault:rw"
    - "/home/r9888/.git-credentials:/root/.git-credentials:ro"

Здесь каждый том выполняет свою задачу.

Приватный SSH-ключ нужен для подключения к серверам, а само хранилище монтируется с правами на чтение и запись, чтобы агент мог создавать и изменять заметки. Файл .git-credentials содержит сохранённые данные для аутентификации при работе с Gitea через HTTPS.

Для работы с сохранёнными учётными данными Git я настроил соответствующий механизм: git config –global credential.helper store.

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

Изучение хранилища

Сначала я попросил Hermes изучить репозиторий main-vault, разобраться в его структуре. Он провёл полный аудит и обновил MEMORY.md:

При последующих запросах мне не нужно каждый раз объяснять устройство хранилища с нуля. Агент уже знает общую структуру и может использовать её как отправную точку, обращаясь к актуальным файлам по мере необходимости.

Анализ и автоматизация работы с тегами

При перестройке хранилища раньше у меня очень много заметок оказалось без тегов, и я их давно хотел добавить, но никак не находил время. Я попросил об этом Hermes. По моему хранилищу он понял, что мои теги в первую очередь на кириллице и опирался именно на это, потом он что-то сломал, но в итоге починил. В конце он сам запушил изменения и обновил скилл:

Здесь наглядно видно, как работает Hermes на практике, как он подстраивается под задачу и сам чинит все, что сломалось, при этом улучшая свою работу в процессе.

❯ Второй бот: аудит серверов

В отличие от бота для работы с Obsidian, здесь агент должен не редактировать файлы, а проверять состояние серверов, искать потенциальные проблемы и формировать отчёт с рекомендациями.

Моя инфраструктура состоит из двух основных узлов: удалённого VPS и домашнего сервера, объединённых общей защищенной сетью. На них работают Docker-контейнеры, веб-сервисы, мониторинг, сбор логов и резервное копирование. Проверять всё это вручную регулярно довольно неудобно, поэтому я решил поручить сбор диагностической информации отдельному агенту.

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

Тестовый аудит

После запуска Hermes подключился к обоим серверам по SSH и последовательно собрал данные. Проверка заняла около девяти минут. В процессе агент столкнулся с несколькими нюансами.

Первое замечание касалось обновлений Ubuntu на VPS. Агент обнаружил доступное обновление пакета libapparmor1 и рекомендовал установить его при следующем обслуживании сервера. Проблема получила низкий приоритет.

Второе замечание относилось к Homebox на домашнем сервере. Сервис слушал адрес 0.0.0.0:7745, то есть был доступен через сетевые интерфейсы хоста, а не только через локальный интерфейс. По результатам проверки агент отметил, что сервис доступен из локальной сети без аутентификации через Nginx, и предложил убрать прямую публикацию порта, оставив доступ через обратный прокси.

Наконец, в журналах домашнего сервера обнаружились ошибки ^[11] ACPI, связанные с прошивкой и USB-контроллером. Агент оценил их как не влияющие на работу сервисов.

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

❯ Третий бот: мониторинг почты

У меня три почтовых ящика, которые приходится регулярно просматривать. При этом значительную часть входящих сообщений составляют рассылки, подборки вакансий и другие письма, не требующие немедленного внимания ^[12], хотя иногда проскакивают какие-то личные сообщения, связанные с заказами и подобным, которые важно не пропустить.

Вместо того чтобы получать уведомление о каждом новом письме, я хотел сделать отдельного агента, который проверяет входящие, выделяет действительно важные сообщения и присылает краткую сводку.

Отладка проверки почты

Для проверки я попросил агента выполнить тестовый запуск. Вместо того чтобы просто сообщить об ошибке, Hermes изучил конфигурацию и скрипты, проверил работу Himalaya и обнаружил две проблемы в check_mail.py, который создал ранее.

Скрипт использовал путь ~/.local/bin/himalaya, но при запуске через Python символ ~ не раскрывался в домашний каталог пользователя. После замены на абсолютный путь /root/.local/bin/himalaya проблема исчезла.

Вторая проблема оказалась интереснее. Скрипт ожидал, что Himalaya вернёт JSON-массив писем, но версия 2 использовала объект с полем envelopes. Из-за несовпадения форматов скрипт мог не обработать полученные данные, даже если подключение к почтовому ящику работало успешно.

Hermes исправил поиск бинарного файла, добавил обработку нового формата JSON с сохранением обратной совместимости. После исправлений я повторно запустил проверку. Все три почтовых ящика проверились успешно, а агент прислал результат в Telegram.

Проверка (cron) запускается дважды в день — в 08:00 и 18:00 по московскому времени. Агент отслеживает новые письма и отправляет в Telegram сводку по результатам проверки.

❯ Заключение

Я начинал с идеи просто попробовать Hermes Agent в повседневной работе, а в итоге получил три полноценных сценария автоматизации.

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

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

Если вам интересна тема сетевой архитектуры, администрирования Linux и DevOps, делюсь своими практическими заметками и опытом в Telegram-канале My Tech Notes ^[13].

Новости, обзоры продуктов и конкурсы от команды  ^[18]Timeweb.Cloud ^[19] — в нашем Telegram‑канале ^[18] ↩