День 116 — Hermes Agent получил память для планов, интернет и экономию контекста

2 сентября 2026, 22:30

Hermes Agent уже давно живёт в отдельной VM внутри Proxmox, отвечает в Telegram и ходит к модели через локальный FreeDeepseekAPI. Но просто подключить LLM к инфраструктуре недостаточно. Для короткого вопроса такой агент удобен, а на длинной задаче быстро проявляются ограничения: план теряется в истории, вывод команд забивает контекст, а поиск по интернету зависит от возможностей конкретной модели.

Сегодня я добавил Hermes четыре расширения:

Planning with Files — постоянный план и журнал работы в Markdown;
RTK — сокращение многословного вывода команд;
Agent Reach — доступ к веб-страницам, GitHub, YouTube и RSS;
Skill Retrieval — выбор релевантных навыков вместо загрузки всего каталога.

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

Рабочий контур навыков Hermes Agent

Открыть интерактивную архитектуру Hermes Agent

Интерактивная версия позволяет отдельно проследить путь запроса, работу длинной задачи, исследование внешних источников и отключённый Skill Retrieval. Интерфейс просмотрщика Archify пока англоязычный, но содержание схемы подписано по-русски.

Зачем это понадобилось

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

Одновременно агент выполняет команды вроде git diff, читает логи и исследует репозитории. Их необработанный вывод тоже быстро расходует контекст.

Получалась такая схема:

сообщение в Telegram
        |
        v
огромный системный prompt со skills
        |
        v
многословный вывод shell-команд
        |
        v
модели остаётся меньше полезного контекста

Цель обновления — не добавить ещё четыре пункта в список плагинов, а сделать длинные инфраструктурные задачи устойчивее.

Planning with Files

Первым был установлен Planning with Files. Это реализация подхода, при котором план, найденные факты и прогресс существуют не только внутри переписки, а сохраняются в Markdown-файлах.

Для Hermes проект предоставляет отдельный skill, plugin, три инструмента планирования и hooks жизненного цикла.

Теперь большая задача может выглядеть так:

/skill plan

Проверь весь homelab:
- состояние узлов Proxmox;
- свободное место;
- ошибки сервисов;
- доступные обновления.

Сначала составь план. Ничего не изменяй без подтверждения.

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

Есть небольшой нюанс: команда /plan уже занята ядром Hermes. Поэтому установленный skill вызывается через /skill plan.

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

RTK: меньше вывода, больше полезного контекста

Второе расширение — RTK, небольшой CLI-proxy на Rust. Он становится между агентом и консольной командой, фильтруя повторяющийся и малополезный вывод.

После подключения к Hermes команда:

git status

автоматически переписывается в:

rtk git status

То же относится к части команд git, поиску по файлам и запуску тестов. Самому пользователю писать rtk не нужно: преобразование выполняет plugin Hermes.

Авторы RTK заявляют сокращение вывода распространённых команд на 60–90%. Это не означает, что весь запрос к модели станет дешевле на 90%: системные инструкции, история и ответ модели никуда не исчезают. Но shell output — именно та часть, которую RTK действительно может уменьшить.

Для инфраструктуры я настроил исключения. RTK не переписывает:

ssh, scp, rsync
systemctl, journalctl
ip, ss, ping, dig, wg
qm, pct, pvesh
apt, curl, playwright

Причина простая: в диагностике сети, systemd и Proxmox опасно потерять строку, которую фильтр посчитал несущественной. Экономить контекст стоит там, где результат предсказуем, а не на критичных данных.

Agent Reach: интернет как набор проверяемых каналов

Третье расширение — Agent Reach. Оно не заменяет браузер одной волшебной кнопкой, а собирает несколько специализированных способов чтения источников.

На сервере сейчас работают:

чтение обычных веб-страниц через Jina Reader;
GitHub через установленный gh;
YouTube через yt-dlp;
RSS;
открытые данные Bilibili и V2EX.

В Telegram теперь можно написать:

Используй agent-reach. Изучи последние релизы Hermes Agent,
найди важные изменения и оцени риски обновления для нашей VM.

Или передать конкретный репозиторий:

Проверь обновления FreeDeepseekAPI на GitHub.
Сравни их с нашей установленной версией и ничего не обновляй.

Установленная версия Agent Reach — 1.5.0. Она находится в отдельном Python venv, а Hermes подключает её как skill. Такая изоляция уменьшает риск конфликта зависимостей с самим агентом.

Не все каналы заработали полностью. GitHub CLI пока не авторизован для приватных репозиториев, а Exa MCP не смог пройти через используемый SOCKS-транспорт. В качестве рабочего fallback остаются штатный веб-поиск Hermes и Jina Reader.

Я намеренно не переносил на сервер cookies от личных социальных сетей. Доступ к публичным источникам и доступ к аккаунтам пользователя — разные уровни доверия.

Skill Retrieval: хорошая идея, неудачная интеграция

Четвёртым расширением стал Skill Retrieval из набора moonlight-lupin/agent-skills.

Идея правильная: вместо помещения всех навыков в prompt локальный BM25-индекс выбирает только те, которые относятся к текущему запросу. При сотне skills это должно заметно уменьшать системный контекст.

Статический аудит runtime-кода не показал опасной сетевой активности или скрытого выполнения shell-команд. Сам поиск по индексу занимал около 0,18 секунды и выбирал ожидаемые навыки.

Но полный тест выявил другую проблему: с активным plugin Hermes зависал ещё до вызова модели. После отключения Skill Retrieval тот же короткий запрос сразу возвращал ответ.

Я попробовал оставить только компактный список имён без pre_llm_call hook, но зависание повторилось. Поэтому текущее состояние такое:

skill-retrieval: installed, disabled

Это лучше, чем оставить красивую оптимизацию и получить молчащего Telegram-бота. К plugin можно вернуться после исправления совместимости с текущей версией Hermes.

Что пришлось поправить в Telegram

После перезапуска gateway проявилась отдельная проблема: обычные HTTP-запросы через SOCKS работали, getMe и тестовый getUpdates проходили, но новый Telegram adapter зависал при инициализации большого HTTP-пула.

Для gateway были заданы более консервативные параметры:

HERMES_TELEGRAM_HTTP_POOL_SIZE=16
HERMES_TELEGRAM_HTTP_POOL_TIMEOUT=15
HERMES_TELEGRAM_HTTP_CONNECT_TIMEOUT=15
HERMES_TELEGRAM_HTTP_READ_TIMEOUT=35
HERMES_TELEGRAM_HTTP_WRITE_TIMEOUT=35
HERMES_TELEGRAM_DISABLE_FALLBACK_IPS=true

Fallback IP здесь не нужен: Telegram всё равно должен идти через явно настроенный SOCKS-proxy. Чем меньше параллельных соединений создаёт бот, тем проще переживать переподключение туннеля и сетевые таймауты.

Сам gateway и FreeDeepseekAPI остаются под управлением systemd и автоматически перезапускаются при сбоях.

Как теперь пользоваться Hermes через Telegram

Для коротких задач ничего не изменилось:

Проверь свободное место на VM и пришли краткий отчёт.

Для длинных задач лучше явно включать файловый план:

/skill plan

Проверь обновления Hermes и FreeDeepseekAPI.
Изучи changelog, оцени риски, сделай резервную копию
и покажи план до внесения изменений.

Для исследования внешних источников можно прямо назвать Agent Reach:

Используй agent-reach. Найди новые версии Proxmox,
Hermes Agent и FreeDeepseekAPI за последний месяц.
Отдели обязательные обновления от необязательных.

RTK работает автоматически. Пользователю не нужно помнить о нём в каждом сообщении.

Проверка после установки

Каждое расширение проверялось отдельно. Общий минимум выглядел так:

hermes plugins doctor
agent-reach doctor
rtk --version
rtk rewrite "git status"
curl http://127.0.0.1:9655/health
systemctl --user status hermes-gateway.service

Отдельно были выполнены короткие запросы напрямую к deepseek-chat и deepseek-chat-search, а затем через Hermes. Именно последний end-to-end тест обнаружил зависание Skill Retrieval.

Перед изменениями создана резервная копия конфигурации, plugins и skills. Для агента, который сам умеет менять систему, возможность быстро вернуться к известному состоянию важнее количества установленных возможностей.

Итог

Hermes стал ближе не к обычному чат-боту, а к постоянному оператору homelab:

Telegram
   |
   v
Hermes Agent
   |
   +--> Planning with Files — держит длинный план
   +--> RTK                 — сокращает вывод команд
   +--> Agent Reach         — читает внешние источники
   +--> FreeDeepseekAPI     — предоставляет модель и поиск

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

А Skill Retrieval останется напоминанием о правильном порядке работы с AI-инфраструктурой:

установить -> проверить -> воспроизвести сбой -> отключить нестабильное

В homelab работающий агент полезнее агента с максимально длинным списком возможностей.