Инструменты и наборы инструментов

Команды установки Python-зависимостей на этой странице рассчитаны на чекаут исходников, подготовленный через PM. После изменения зависимостей заново активируйте чекаут и перезапустите Hermes.

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

Доступные инструменты

У Hermes из коробки большой реестр встроенных инструментов: веб-поиск, автоматизация браузера, выполнение команд в терминале, редактирование файлов, память, делегирование, запланированные задачи и многое другое. Новые инструменты добавляют плагины: например, управление устройствами Home Assistant приходит из плагина homeassistant каталога.

Если смотреть по крупным категориям:

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

Как пользоваться наборами инструментов

# Использовать конкретные наборы инструментов
hermes chat --toolsets "web,terminal"

# Посмотреть все доступные инструменты
hermes tools

# Настроить инструменты для каждой платформы (интерактивно)
hermes tools

Среди распространённых наборов — web, search, terminal, file, browser, vision, image_gen, skills, tts, todo, memory, session_search, cronjob, code_execution, delegation, clarify, messaging, discord, discord_admin, debugging и safe.

Полный список, включая платформенные пресеты вроде hermes-cli, hermes-telegram, и динамические MCP-наборы вида mcp-<server>, приведён в Справочнике по наборам инструментов.

Аннотации к результатам инструментов

При чтении транскриптов агента полезно знать о нескольких особенностях поведения инструментов:

• Смерть по сигналу объясняется словами. Когда команду в терминале убивает сигнал, в результате вместо голого числового кода появляется понятная пометка — например, exit -9/137 превращается в «terminated by signal 9: SIGKILL — often the kernel OOM killer on memory exhaustion, or an explicit kill -9», и так же размечаются segfault, abort, SIGTERM, разрыв канала (broken pipe) и превышение лимитов CPU/размера файла. Отрицательные коды (семантика подпроцесса) описываются однозначно; конвенция шелла 128+номер_сигнала сопровождается оговоркой «usually», поскольку приложение вполне может завершиться с таким кодом само.
• Файлы в UTF-16 перекодируются, а не отклоняются. read_file определяет UTF-16 (по BOM или эвристике байтовых паттернов, для любого порядка байт — типично для файлов из Windows-«Блокнота» и редиректов PowerShell >) и перекодирует его в UTF-8 для отображения, вместо того чтобы пометить файл как бинарный. В результат добавляется подсказка о том, что произошло преобразование; правки через patch/write_file записываются обратно в UTF-8. Файлы крупнее 10 МБ и по-настоящему бинарные файлы по-прежнему отклоняются как бинарные.

Бэкенды терминала

Инструмент терминала умеет выполнять команды в разных окружениях:

Настройка

# В ~/.hermes/config.yaml
terminal:
  backend: local    # или: docker, ssh, singularity, modal, daytona, vercel_sandbox
  cwd: "."          # Рабочий каталог
  timeout: 180      # Таймаут команды в секундах

Файлы автозапуска шелла и неинтерактивные команды

Агент вызывает терминал неинтерактивно — без TTY и без человека у приглашения. Тяжёлая или рассчитанная на интерактив инициализация шелла, которую вы никогда не замечаете в обычном терминале, может ломать или сильно замедлять каждую команду агента:

• Медленная инициализация (nvm, менеджеры версий, обращения к сети из приглашения): классическое подключение nvm.sh заметно замедляет запуск каждого шелла, а агент запускает шеллы часто. Многосекундные rc-файлы превращают быстрый git status в риск таймаута.
• Блоки, ожидающие TTY: всё в .bashrc/.zshrc, что выводит приглашение, подключается к tmux/screen, вызывает read или показывает меню, подвесит неинтерактивный шелл — команда будет казаться зависшей, а потом упадёт по таймауту.
• Безусловный вывод: rc-файлы, которые печатают баннеры через echo, засоряют вывод каждой команды, который потом приходится разбирать агенту.

Стандартное решение — защита, которую большинство дистрибутивов уже ставят в начало .bashrc: выходить раньше, если шелл неинтерактивный, и держать всё тяжёлое или интерактивное ниже неё:

# ~/.bashrc — держите эту защиту ближе к началу файла
case $- in
  *i*) ;;      # интерактивный: продолжаем
  *) return;;  # неинтерактивный: останавливаемся здесь
esac

# тяжёлая/интерактивная инициализация — НИЖЕ защиты
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"

Пользователям zsh: настройку только для логина держите в .zprofile, настройку только для интерактива — в .zshrc; .zshenv оставьте минимальным, поскольку он выполняется для каждого шелла, включая неинтерактивные. Если агенту действительно нужен инструмент, который в PATH кладёт только ваш rc-файл, вынесите изменение PATH выше защиты (экспорт PATH дёшев) либо создайте симлинк на бинарник в ~/.local/bin.

Если команды агента в терминале зависают или сразу падают по таймауту после того, как вы поработали в собственном терминале, — первый подозреваемый это инициализация вашего шелла.

Бэкенд Docker

terminal:
  backend: docker
  docker_image: python:3.11-slim

Один постоянный контейнер, общий на весь процесс. При первом обращении Hermes поднимает единственный долгоживущий контейнер (docker run -d ... sleep infinity) и направляет в него каждый вызов терминала, файловых операций и execute_code через docker exec. Смена рабочего каталога, установленные пакеты, правки окружения, файлы, записанные в /workspace, — всё это переносится из одного вызова инструмента в следующий, переживает /new, /reset и субагентов delegate_task и живёт ровно столько, сколько работает сам процесс Hermes. При завершении работы контейнер останавливается и удаляется.

То есть бэкенд Docker ведёт себя как постоянная песочница-виртуалка, а не как свежий контейнер под каждую команду. Один раз сделали pip install foo — пакет на месте до конца сессии. Перешли в cd /workspace/project — следующие вызовы ls увидят именно этот каталог. Полный жизненный цикл и флаг container_persistent, который определяет, переживают ли /workspace и /root перезапуски Hermes, описаны в разделе Настройка → Бэкенд Docker.

Бэкенд SSH

Рекомендуется ради безопасности — так агент не сможет изменить собственный код:

terminal:
  backend: ssh

# Укажите учётные данные в ~/.hermes/.env
TERMINAL_SSH_HOST=my-server.example.com
TERMINAL_SSH_USER=myuser
TERMINAL_SSH_KEY=~/.ssh/id_rsa

Singularity/Apptainer

# Заранее соберите SIF для параллельных воркеров
apptainer build ~/python.sif docker://python:3.11-slim

# Настройте
hermes config set terminal.backend singularity
hermes config set terminal.singularity_image ~/python.sif

Modal (бессерверное облако)

python -c "import pm; pm.sync_venv(['modal'], explicit=True)"
modal setup
hermes config set terminal.backend modal

Vercel Sandbox

python -c "import pm; pm.sync_venv(['vercel'], explicit=True)"
hermes config set terminal.backend vercel_sandbox
hermes config set terminal.vercel_image vercel/sandbox/universal:latest

Для аутентификации нужны все три переменные: VERCEL_TOKEN, VERCEL_PROJECT_ID и VERCEL_TEAM_ID. Такая настройка через access-токен — поддерживаемый способ для деплоев и обычных долгоживущих процессов Hermes на Render, Railway, Docker и подобных хостингах. Свежие песочницы стартуют из образа terminal.vercel_image (по умолчанию vercel/sandbox/universal:latest; прежние пресеты vercel_runtime в Vercel объявлены устаревшими); по умолчанию Hermes использует /vercel/sandbox как корень удалённого рабочего пространства.

Для разовой локальной разработки Hermes также принимает короткоживущие OIDC-токены Vercel:

VERCEL_OIDC_TOKEN="$(vc project token <project-name>)" hermes chat

Из каталога связанного (linked) проекта Vercel:

VERCEL_OIDC_TOKEN="$(vc project token)" hermes chat

При container_persistent: true Hermes использует снапшоты Vercel, чтобы сохранять состояние файловой системы между пересозданиями песочницы в рамках одной задачи. В снапшот может попасть и то, что Hermes синхронизировал в песочницу: учётные данные, навыки и файлы кеша. Снапшоты не сохраняют работающие процессы, пространство PID и идентичность самой живой песочницы.

Фоновые команды терминала используют общий для Hermes процесс работы с нелокальными процессами: пока песочница жива, spawn, poll, wait, log и kill идут через обычный process-инструмент, но Hermes не обеспечивает нативное восстановление отсоединённых (detached) процессов Vercel после очистки или перезапуска.

Оставляйте container_disk неустановленным или на общем значении по умолчанию 51200: для Vercel Sandbox настройка размера диска не поддерживается и приведёт к ошибке диагностики или создания бэкенда.

Ресурсы контейнера

Для всех контейнерных бэкендов настраиваются CPU, память, диск и сохранение состояния:

terminal:
  backend: docker  # или singularity, modal, daytona, vercel_sandbox
  container_cpu: 1              # Ядра CPU (по умолчанию: 1)
  container_memory: 5120        # Память в МБ (по умолчанию: 5 ГБ)
  container_disk: 51200         # Диск в МБ (по умолчанию: 50 ГБ)
  container_persistent: true    # Сохранять файловую систему между сессиями (по умолчанию: true)

При container_persistent: true установленные пакеты, файлы и конфигурация переживают переход между сессиями.

Безопасность контейнеров

Все контейнерные бэкенды запускаются с усиленной защитой:

• Корневая файловая система только для чтения (Docker)
• Сброшены все Linux-capabilities
• Запрет на повышение привилегий
• Лимит PID (256 процессов)
• Полная изоляция пространств имён
• Постоянное рабочее пространство через тома, а не через перезаписываемый корневой слой

Docker при желании можно снабдить явным списком разрешённых переменных окружения через terminal.docker_forward_env, но проброшенные переменные видны командам внутри контейнера, поэтому считайте их раскрытыми для этой сессии.

Управление фоновыми процессами

Запускайте фоновые процессы и управляйте ими:

terminal(command="pytest -v tests/", background=true)
# Возвращает: {"session_id": "proc_abc123", "pid": 12345}

# Затем управляйте через инструмент process:
process(action="list")       # Показать все запущенные процессы
process(action="poll", session_id="proc_abc123")   # Проверить статус
process(action="wait", session_id="proc_abc123")   # Ждать завершения
process(action="log", session_id="proc_abc123")    # Полный вывод
process(action="kill", session_id="proc_abc123")   # Завершить
process(action="write", session_id="proc_abc123", data="y")  # Передать ввод

Режим PTY (pty=true) включает работу с интерактивными CLI-инструментами вроде Codex и Claude Code.

Завершённые фоновые команды сохраняют в активном профиле свой код выхода и снятый вывод. Вернитесь в разговор, из которого команда запускалась (или в его продолжение после сжатия), и обращайтесь с исходным session_id: process(action="log") — за выводом, process(action="poll") — за кодом выхода. Посторонние разговоры и запросы без привязанной сессии-владельца сохранённые квитанции прочитать не могут, даже зная точный хендл процесса. process(action="list") тоже показывает сохранённые результаты по текущей задаче или разговору.

Hermes держит 64 последних завершённых результата и хранит их до 7 дней после завершения — в logs/process-results/ внутри домашнего каталога профиля. В квитанцию попадает не больше прежнего скользящего хвоста вывода на 200 000 символов, причём правила вычистки секретов терминала применяются всегда, даже когда вычистка живого вывода отключена. Просроченные квитанции убираются при следующих чтениях и записях результатов. Восстановление не перезапускает команды и не проигрывает уведомления о завершении заново. Оно сохраняет работу, которая успела закончиться при живом родителе, — но не продлевает жизнь незавершённым детям после таймаута или падения.

Поддержка sudo

В интерактивной родительской сессии поддерживаемые команды sudo идут через скрытый ввод пароля (он кешируется на время сессии). Сюда же относятся буквальные абсолютные или закавыченные пути к исполняемому файлу и приставки env с обычными опциями и присваиваниями — например, env -u UNUSED /usr/bin/sudo id. Sudo без пароля запроса не требует. Можно также прописать SUDO_PASSWORD в файле .env своего профиля на машине агента.

Полезную нагрузку для оболочки — bash -c 'sudo id', разбиваемые строки env -S, динамические пути к исполняемому файлу, незнакомые опции env — переписыватель пароля не разбирает. Нужен интерактивный запрос — вызывайте sudo напрямую. Правила подтверждений и защиту от паролей sudo, подставленных агентом, это не меняет.

Делегированные субагенты запрос пароля открыть не могут: у их параллельной работы нет упорядоченного канала к человеку. Выполните команду в родительской сессии либо заведите SUDO_PASSWORD локально. У сессий в мессенджерах и headless безопасного канала для ответа с паролем нет — не отправляйте пароли в чат.