Обновление и удаление

Обновление

Установки через git

Свежая версия ставится одной командой:

hermes update

Команда подтягивает последний код из main, обновляет зависимости и предлагает донастроить новые опции, которые появились со времени прошлого обновления.

Установки через pip

Релизы на PyPI отслеживают версии с тегами (мажорные и минорные релизы), а не каждый коммит в main. Проверить наличие обновления и обновиться:

hermes update --check    # узнать, есть ли на PyPI релиз новее
hermes update            # выполняет pip install --upgrade hermes-agent

Либо вручную:

pip install --upgrade hermes-agent    # или: uv pip install --upgrade hermes-agent
совет

hermes update сам находит новые параметры конфигурации и предлагает их добавить. Пропустили приглашение? Запустите hermes config check, чтобы увидеть недостающие опции, а потом hermes config migrate — он добавит их в интерактивном режиме.

Что происходит при обновлении (установки через git)

При запуске hermes update выполняются такие шаги:

  1. Снимок данных сопряжения — сохраняется лёгкий снимок состояния до обновления (охватывает ~/.hermes/pairing/, правила комментариев Feishu и другие файлы состояния, которые меняются во время работы). Восстановить его можно через процесс восстановления из снимка, описанный в разделе Снимки и откат, либо распаковав самый свежий zip быстрого снимка, который Hermes записал рядом с каталогом ~/.hermes/.
  2. Git pull — подтягивает свежий код из ветки main и обновляет сабмодули.
  3. Проверка синтаксиса после pull + автооткат — закончив pull, Hermes компилирует восемь критичных файлов, которые импортируются при каждом запуске hermes. Если хоть один не парсится (скажем, осиротевший маркер конфликта слияния или случайно обрезанный файл), Hermes выполняет git reset --hard <sha-до-pull> и откатывает установку, чтобы ваша оболочка осталась рабочей. Повторите hermes update, когда апстрим починит проблему.
  4. Установка зависимостей — запускает uv pip install -e ".[all]", чтобы подхватить новые или изменённые зависимости.
  5. Миграция конфигурации — находит опции, добавленные после вашей версии, и предлагает их задать.
  6. Автоперезапуск шлюзов — работающие шлюзы обновляются по завершении апдейта, чтобы новый код вступил в силу сразу. Шлюзы под управлением сервиса (systemd на Linux, launchd на macOS) перезапускаются через менеджер сервисов. Ручной шлюз перезапускается автоматически, если Hermes удаётся сопоставить запущенный PID с профилем.

Обновление с нестандартной ветки: --branch

По умолчанию hermes update следит за origin/main. Передайте --branch <имя> — и обновление пойдёт с другой ветки. Это удобно для QA-каналов, фича-веток и тестирования релиз-кандидатов:

hermes update --branch release-candidate
hermes update --check --branch experimental   # только посмотреть отставание

Если ваш локальный чекаут на другой ветке, Hermes сам прячет (stash) незакоммиченную работу, переключает HEAD на нужную ветку и делает pull. Ветки, которых нет локально, автоматически отслеживаются от origin/<имя> (git checkout -B <имя> origin/<имя>). Если ветки нет нигде, обновление падает аккуратно: спрятанные изменения восстанавливаются перед выходом, так что застрять в странном состоянии не получится. Логика синхронизации форка с апстримом (только для main) на остальных ветках пропускается.

Локальные изменения при неинтерактивных обновлениях

Запускаете hermes update в терминале — Hermes прячет незакоммиченные правки дерева исходников, делает pull, а после спрашивает, восстанавливать ли их. Ровно так, как было всегда. Для интерактивных обновлений ничего не меняется.

Другое дело, когда обновление идёт без терминала — от кнопки «Update» в десктопном или чат-приложении, либо по триггеру шлюза. Спрашивать некого, и судьбу спрятанных изменений решает настройка updates.non_interactive_local_changes:

# ~/.hermes/config.yaml
updates:
  non_interactive_local_changes: stash   # по умолчанию: сохранить + автовосстановить
  # non_interactive_local_changes: discard  # выбросить локальные правки исходников
  • stash (по умолчанию) — спрятать автоматически, сделать pull, затем автовосстановить ваши изменения поверх обновлённого кода. Ничего не теряется; конфликты при восстановлении сохранятся в git stash для ручного разбора.
  • discard — спрятать и удалить stash после pull, чтобы обновление всегда ложилось на чистое дерево. Включайте это лишь на машинах, где локальные правки исходников Hermes вам точно не нужны. Здесь именно stash-drop, а не git reset --hard + git clean -fd, поэтому игнорируемые пути вроде node_modules, venv и артефактов сборки остаются нетронутыми.

В десктопном приложении это Settings → Advanced → In-App Update Local Changes.

Только проверка: hermes update --check

Чтобы узнать о доступном обновлении до того, как делать pull, запустите hermes update --check. Для git-установок он делает fetch и сравнивает коммиты с origin/main; для pip-установок запрашивает у PyPI последний релиз. Файлы не трогаются, шлюз не перезапускается. Команда пригодится в скриптах и cron-задачах, где нужна проверка «есть ли обновление».

Полный бэкап перед обновлением: --backup

Для ценных профилей — продакшен-шлюзов, общих командных установок — можно включить полный бэкап HERMES_HOME (конфиг, авторизация, сессии, навыки, сопряжение) до pull:

hermes update --backup

Или сделать это поведением по умолчанию для каждого запуска:

# ~/.hermes/config.yaml
updates:
  pre_update_backup: true

Раньше --backup работал всегда, но на больших домашних каталогах он добавлял к каждому обновлению по несколько минут — теперь это опция по выбору. Лёгкий снимок данных сопряжения, описанный выше, по-прежнему выполняется безусловно.

Windows: запущен ещё один hermes.exe

В Windows hermes update откажется работать, обнаружив другой процесс hermes.exe, который держит открытым исполняемый файл точки входа из venv. Чаще всего это бэкенд, порождённый приложением Hermes Desktop, открытый REPL hermes в соседнем терминале или работающий шлюз:

$ hermes update
✗ Another hermes.exe is running:
    PID 12345  hermes.exe

  Updating now would fail to overwrite ...\venv\Scripts\hermes.exe because
  Windows blocks REPLACE on a running executable.

  Close Hermes Desktop, exit any open `hermes` REPLs, and
  stop the gateway (`hermes gateway stop`) before retrying.
  Override with `hermes update --force` if you've already
  confirmed those processes will not write to the venv.

Закройте перечисленные процессы и запустите заново. Уверены, что параллельный процесс не помешает (редкий случай — обычно это нужно, лишь когда прослойку антивируса определяют ошибочно)? Добавьте --force, чтобы пропустить проверку. Тогда апдейтер всё равно будет пытаться переименовать .exe с экспоненциальной задержкой, а при упорных блокировках запланирует замену на следующую перезагрузку через MoveFileEx(MOVEFILE_DELAY_UNTIL_REBOOT), чтобы обновление завершилось.

Ожидаемый вывод выглядит так:

$ hermes update
Updating Hermes Agent...
📥 Pulling latest code...
Already up to date.  (или: Updating abc1234..def5678)
📦 Updating dependencies...
✅ Dependencies updated
🔍 Checking for new config options...
✅ Config is up to date  (или: Found 2 new options — running migration...)
🔄 Restarting gateways...
✅ Gateway restarted
✅ Hermes Agent updated successfully!

Рекомендуемая проверка после обновления

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

  1. git status --short — если дерево неожиданно «грязное», разберитесь, прежде чем продолжать.
  2. hermes doctor — проверяет конфиг, зависимости и состояние сервисов.
  3. hermes --version — убедитесь, что версия поднялась как ожидалось.
  4. Используете шлюз? hermes gateway status.
  5. Если doctor сообщает о проблемах npm audit: выполните npm audit fix в указанном каталоге.
внимание
«Грязное» рабочее дерево после обновления

Если git status --short показывает неожиданные изменения после hermes update, остановитесь и изучите их, прежде чем продолжать. Обычно так бывает, когда локальные правки переналожились поверх обновлённого кода или шаг с зависимостями обновил lock-файлы.

Если терминал отключился посреди обновления

От случайной потери терминала hermes update защищён:

  • Обновление игнорирует SIGHUP, поэтому закрытие SSH-сессии или окна терминала больше не убивает его на полпути. Дочерние процессы pip и git наследуют эту защиту, так что оборванное соединение не оставит окружение Python наполовину установленным.
  • Весь вывод во время работы дублируется в ~/.hermes/logs/update.log. Терминал пропал — переподключитесь и загляните в лог, чтобы понять, завершилось ли обновление и удался ли перезапуск шлюза:
tail -f ~/.hermes/logs/update.log
  • Ctrl-C (SIGINT) и завершение работы системы (SIGTERM) по-прежнему учитываются: это намеренные отмены, а не случайности.

Оборачивать hermes update в screen или tmux ради того, чтобы пережить обрыв терминала, больше не нужно.

Проверка текущей версии

hermes version

Сравните её с последним релизом на странице релизов GitHub.

Обновление из мессенджеров

Обновиться можно и прямо из Telegram, Discord, Slack, WhatsApp или Teams — отправьте:

/update

Команда подтянет свежий код, обновит зависимости и перезапустит работающие шлюзы. На время перезапуска бот ненадолго уйдёт офлайн (обычно 5–15 секунд), а затем продолжит работу.

Ручное обновление

Если вы ставили вручную, не через быстрый установщик:

cd /path/to/hermes-agent
export VIRTUAL_ENV="$(pwd)/venv"

# Подтянуть свежий код
git pull origin main

# Переустановить (подхватит новые зависимости)
uv pip install -e ".[all]"

# Проверить новые опции конфигурации
hermes config check
hermes config migrate   # Интерактивно добавить недостающие опции

Инструкция по откату

Если после обновления что-то сломалось, можно вернуться на предыдущую версию:

cd /path/to/hermes-agent

# Список недавних версий
git log --oneline -10

# Откат на конкретный коммит
git checkout <commit-hash>
uv pip install -e ".[all]"

# Перезапустить шлюз, если он работает
hermes gateway restart

Чтобы откатиться на конкретный тег релиза (подставьте свой прежний тег — например, недавний релиз вроде v2026.5.16 или любой более ранний тег из git tag --sort=-version:refname):

git checkout vX.Y.Z
uv pip install -e ".[all]"
внимание

Откат может вызвать несовместимости конфигурации, если до этого добавлялись новые опции. После отката запустите hermes config check и удалите из config.yaml нераспознанные опции, если столкнётесь с ошибками.

Заметка для пользователей Nix

Если вы ставили через Nix flake, обновления идут через менеджер пакетов Nix:

# Обновить вход flake
nix flake update hermes-agent

# Или пересобрать со свежей версией
nix profile upgrade hermes-agent

Установки Nix неизменяемы — за откат отвечает система поколений Nix:

nix profile rollback

Подробнее — в Настройке Nix.


Удаление

Установки через git

hermes uninstall

Деинсталлятор предложит сохранить файлы конфигурации (~/.hermes/) на случай будущей переустановки.

Установки через pip

pip uninstall hermes-agent
rm -rf ~/.hermes            # По желанию — оставьте, если планируете переустановку

Ручное удаление

rm -f ~/.local/bin/hermes
rm -rf /path/to/hermes-agent
rm -rf ~/.hermes            # По желанию — оставьте, если планируете переустановку
инфо

Если шлюз стоял как системный сервис, сначала остановите и отключите его:

hermes gateway stop
# Linux: systemctl --user disable hermes-gateway
# macOS: launchctl remove ai.hermes.gateway
ESC