Как я обновлял Hermes Agent и почему правильнее отдать это AI-агенту

Сегодня обновлял Hermes Agent — персонального AI-агента от Nous Research, который у меня крутится на VPS. Хочу зафиксировать, что пошло не так, чего НЕ делать, и почему главный вывод оказался простым: подобные задачи проще и безопаснее отдавать агенту с доступом к серверу, а не пытаться разобраться самому.

Контекст

Hermes Agent — это open-source агент с памятью, скиллами, gateway для мессенджеров (Telegram, Discord, Slack). У меня он стоял несколько месяцев на VPS Ubuntu 24.04, версия 0.11.0. Захотел подняться до 0.12.0, потому что в свежих релизах появились web dashboard, новые провайдеры моделей и куча других фич.

На бумаге обновление выглядело тривиально: либо hermes update, либо в крайнем случае склонировать новую версию и восстановить данные. На практике всё оказалось значительно сложнее.

Что было не так с моей установкой

При проверке выяснилось, что:

1. Сам Hermes CLI был сломан — ModuleNotFoundError: No module named 'hermes_cli.main'. Версия 0.11.0 формально установлена, но запустить ничего нельзя.

2. Установка была в legacy layout — весь код Hermes лежал прямо в ~/.hermes/ рядом с данными. В новой версии 0.12.0 NousResearch перешёл на FHS layout: код в /usr/local/lib/hermes-agent/, данные в ~/.hermes/. Старая схема больше не поддерживается чисто.

3. Git origin указывал на мой личный fork, не на upstream NousResearch. То есть hermes update тянул бы из моего же репо, где не было свежих коммитов.

4. Между моим fork и upstream не было общего предка — я когда-то сделал бэкап как git init && git add . && git commit, без сохранения upstream-истории. Отставание — 7011 коммитов. Любой git merge при таком разрыве — это лавина конфликтов.

5. Локальная база state.db была повреждена — messages_fts vtable constructor failed. Виртуальная FTS5-таблица сообщений разрушена, восстановить не удалось.

6. Внутри ~/.hermes/ лежала вложенная копия hermes-agent версии 0.10.0 с собственным .git. Это блокировало переход на FHS layout: install.sh видит её и не переключается.

7. Был оставлен незавершённый stash от предыдущей попытки hermes update, прервавшейся посередине.

Каждая проблема по отдельности решаема. Но вместе они складываются в ситуацию, когда стандартный hermes update физически не может сработать.

Чего НЕ делать в такой ситуации

1. Не запускать git merge или git pull с huge-разрывом без общего предка.

Это генерирует тысячи конфликтов через всю кодовую базу. Я провёл достаточно времени, прикидывая, реально ли разрешить хотя бы 100 из 7000+ — невозможно. Если merge-base отсутствует — merge не подходит, нужна другая стратегия.

2. Не запускать hermes update на сломанной установке.

Если CLI уже падает с ошибкой импорта, hermes update тем более упадёт. Хуже того — он успеет сделать auto-stash и оставить рабочее дерево в промежуточном состоянии. У меня в репозитории уже висел такой stash от чьей-то предыдущей попытки.

3. Не делать mv ~/.hermes без бэкапа.

Логично, но в момент паники легко пропустить шаг. У меня в ~/.hermes/ были все данные за месяцы работы: сессии, память, кастомные скиллы, кастомные скрипты, авторизации. Потеря — это потеря.

4. Не восстанавливать вслепую runtime-файлы.

При переустановке хочется тупо скопировать всё содержимое старой папки в новую. Нельзя так. Файлы вроде gateway_state.json, channel_directory.json, processes.json, auth.lock, state.db-shm, state.db-wal — это runtime-состояние. Их восстановление в свежую установку приводит к багам или повреждению базы.

5. Не восстанавливать повреждённую базу.

Если PRAGMA integrity_check показывает ошибки и .recover не работает — смириться, создать новую. Попытка восстановить «как было» приведёт к тому, что новая Hermes будет работать с битой базой и падать при первом обращении к таблице.

6. Не доверять hermes gateway restart.

Есть известный issue #6631 — restart не всегда убивает процесс. На моём сервере старый PID продолжал работать в памяти со старым кодом 3 часа после «рестарта». Помог только systemctl stop && systemctl start.

Безопасный workflow обновления

Если Hermes здоров и установка свежая (FHS layout):

hermes update --check                       # узнать, есть ли новая версия
hermes update --backup --restart-gateway    # с автобэкапом + рестартом

Флаг --backup создаёт snapshot HERMES_HOME перед pull. Откатиться можно через hermes backup restore --state pre-update. Это штатный path, на нём можно жить.

Если установка сломана или была в legacy layout (как у меня) — нужна полная переустановка:

1. Сделать tar-бэкап всего ~/.hermes/ (исключая .venv, node_modules, __pycache__).
2. Переименовать ~/.hermes в ~/.hermes.old-DATE.
3. Запустить official curl install.sh | bash --skip-setup.
4. Восстановить из старой папки только user data — конфиги, ключи, сессии, память, кастомные скиллы и скрипты. НЕ восстанавливать venv, runtime-файлы, повреждённую базу.
5. hermes config migrate, systemctl stop/start hermes-gateway, проверить статус через 30 секунд.

Это путь, по которому в итоге пошёл я. Занял 30-40 минут чистой работы.

Главный вывод: отдавайте задачу AI-агенту

Когда я начал ковыряться в этой ситуации сам, я тратил время на чтение документации, проверку git remote, поиск merge-base, выяснение структуры новой версии. Каждый шаг порождал новый вопрос.

В какой-то момент я просто дал доступ к серверу Claude Code (через временный SSH-ключ, на час). Дальше агент:

• сам провёл диагностику и нашёл все 7 накопившихся проблем,
• сам прочитал свежий install.sh, разобрался с FHS layout,
• сам сделал бэкап с правильными исключениями,
• сам переустановил Hermes и восстановил данные с разделением «что копировать» и «что не копировать»,
• сам написал отчёт о сделанном для будущих сессий,
• задокументировал риски следующего обновления.

Я только подтверждал выбор стратегии и решал спорные моменты (например, что делать с моими правками к 4 встроенным скиллам).

Урок: AI-агент с доступом к серверу — это не «автоматизация рутины», а замена долгого ручного исследования. Я знал примерное направление, но не помнил всех деталей: как именно работает install.sh, какие файлы являются runtime-only, как корректно сравнить мои правки с upstream через git diff stash@{0}:file HEAD:file, какие skills являются bundled, а какие custom. Агент держит это знание в контексте и применяет за минуты.

Это меняет подход к подобным задачам в принципе. Раньше «обновить Hermes» означало забронировать вечер. Теперь — это разговор и подтверждения по ходу.

Практические правила для будущего

1. При любой сложности с обновлением — сразу подключайте агента к серверу через временный SSH-ключ. Не тратьте час на самостоятельное копание.

2. Перед запуском любого update — снимайте полный tar-бэкап. Хоть раз спасёт.

3. hermes update использует git pull под капотом. Если ваш origin указывает на personal fork без новых коммитов — обновления просто не будет. Проверьте git remote -v перед обновлением.

4. FHS layout vs legacy layout. В новой версии Hermes код в /usr/local/lib/hermes-agent, данные в ~/.hermes. Если у вас legacy (всё в ~/.hermes) — проще полностью переустановить, чем мигрировать.

5. Custom скрипты в ~/.hermes/scripts/ могут затираться при hermes update. Безопаснее держать их в отдельной папке вне HERMES_HOME.

6. hermes gateway restart — это reload, а не restart. Для гарантированной перезагрузки процесса — systemctl stop && systemctl start hermes-gateway.

7. После любых работ на сервере, где засветился пароль root — менять пароль и переходить на key-only auth.

Финал

В итоге Hermes Agent v0.12.0 поднялся, dashboard работает, custom skills и scripts на месте, риски следующего обновления задокументированы, в Obsidian появилась структура для серверов и общих знаний.

Главная мысль не про Hermes. Она про то, что для нетривиальных DevOps-задач сегодня самый эффективный путь — не «прочитать всю документацию и попробовать», а «дать агенту доступ и подтверждать решения». Качество исполнения при этом часто выше моего, потому что агент не пропускает шаги по невнимательности и держит в голове весь набор edge-кейсов сразу.

Если вы тоже держите Hermes или похожие self-hosted AI-инструменты — рекомендую заложить в workflow роль «агент с временным SSH-доступом для апдейтов и инцидентов». Окупается с первого раза.