Оптимизация внутренней кухни Hermes

Чуть больше месяца назад я начал использовать Hermes вместо OpenClaw. Сначала осторожно: несколько личных задач, немного экспериментов, обычная проверка на “не развалится ли в реальной жизни”. Потом, как это обычно бывает, оно незаметно стало частью рабочего дня.

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

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

У агента тоже есть фоновые расходы#

Когда мы говорим “агент отвечает моделью X”, это звучит просто. Но реальная система делает не только основной ответ. Hermes выполняет много служебных операций вокруг диалога: сжимает историю, извлекает текст из веб-страниц, выбирает skills, генерирует названия сессий, проверяет опасные команды, обрабатывает изображения и так далее.

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

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

У меня Hermes работает через подписку Codex, поэтому вопрос стал совсем практическим. Хочется экономить токены и лимиты, но не превращать систему в лотерею.

Это не единственный вариант. Такие фоновые операции можно направлять и в локальные модели, и в модели по API, если так удобнее или дешевле. В моём случае речь именно про Codex-подписку: сильную модель оставить там, где она действительно нужна, а простую внутреннюю работу отдать модели попроще.

Что я вынес на mini#

В Hermes для этого есть auxiliary-модели. Идея простая: основная модель остается для диалога и сложных задач, а фоновые операции получают свои маршруты.

Полный список таких операций лучше смотреть в актуальном config.yaml: он зависит от версии Hermes и подключенных возможностей. Здесь я говорю только о тех пунктах, которые менял у себя.

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

На openai-codex / gpt-5.4-mini я вынес:

• compression — сжатие истории диалога;
• web_extract — извлечение текста и смысла из веб-страниц;
• skills_hub — подбор релевантных skills;
• title_generation — короткие названия сессий.

Это текстовые, частые и относительно дешевые по риску задачи. Ошибка там неприятна, но обычно не катастрофична. А экономия может быть заметной, особенно если Hermes используется не как игрушка на вечер, а как постоянный рабочий слой.

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

Что я не стал удешевлять#

approval я оставил на openai-codex / gpt-5.4.

Это не место для экономии на спичках. approval участвует в решении, можно ли выполнять потенциально опасную команду автоматически или нужно спросить человека. Если такая проверка ошибется, последствия могут быть ощутимее, чем лишние токены.

Проверка после правки#

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

hermes -p <profile> config check

После проверки конфигов нужно перезапустить gateway, если он запущен. Иначе Hermes продолжит жить со старой конфигурацией и новые маршруты не подхватятся.

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

Итог#

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

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

Hermes в этом смысле становится не просто ботом в Telegram, а небольшой операционной системой для задач. А у операционной системы, как выясняется, тоже есть коммунальные платежи.