Общие метрики NeMo Relay

Hermes подключает NeMo Relay как обычную runtime-зависимость на тех платформах, для которых Relay публикует нативный wheel. Интеграция общих метрик встроена в Hermes и не требует плагина наблюдаемости. На остальных нативных целях Hermes по-прежнему импортируется без Relay: там используется явный no-op хост с урезанными возможностями. Выполнение Hermes остаётся доступным, а области видимости Relay, middleware, плагины и подписчики — нет. Экстра hermes-agent[nemo-relay] сохранена как no-op псевдоним для совместимости с уже существующими командами установки.

На поддерживаемых платформах для управляемых вызовов провайдера и инструментов Hermes требует NeMo Relay 0.10.

Runtime-зависимость и граница данных

Hermes устанавливает платформенный нативный wheel nemo-relay из ограниченного диапазона зависимости >=0.10,<0.11. Опубликованный пакет собирается из репозитория NVIDIA NeMo Relay. На неподдерживаемых платформах работает описанный выше явный no-op runtime; никакая другая реализация не скачивается.

Relay 0.10 требует конфигурацию наблюдаемости с version = 4. Собственные Python-перехватчики выполнения LLM получают (name, request, context, next_call); контекст отдаёт выбранный кодек запроса и, для нестримингового выполнения, кодек ответа. Нативные плагины нужно пересобрать под ABI v7 из Relay 0.10 и поднять нижнюю границу compat.relay до 0.10.0. Воркерам, которые регистрируют перехватчики выполнения LLM, нужно обновить коллбэки и перегенерировать привязки протокола. Полный чек-лист обновления — в руководстве по миграции на 0.10 от Relay.

Кроме того, Relay 0.10 сам запускает экспорт OpenTelemetry, когда активная конфигурация Relay встречает непустой OTEL_EXPORTER_OTLP_ENDPOINT (или отдельный OTEL_EXPORTER_OTLP_*_ENDPOINT для сигнала) в окружении процесса Hermes. Эти span-ы gen_ai несут сообщения промптов и ответов. Файлы, которые создаёт hermes migrate relay, задают [components.config.opentelemetry] enabled = false, чтобы сохранить поведение 0.9; добавьте такую же секцию в файл, написанный вручную, или задайте OTEL_SDK_DISABLED=true, если этот экспорт вам не нужен.

Когда активно управляемое выполнение Relay, запрос к провайдеру и его ответ проходят через этот нативный модуль внутри процесса Hermes, поэтому настроенные перехватчики работают с реальным вызовом. Это отдельная история, не связанная с контрактом данных общих метрик. Режим общих метрик не ставит никакого сетевого экспортёра расширенной наблюдаемости, а его подписчик принимает только версионированную проекцию по списку разрешений, описанную ниже. Единственный исходящий путь — опциональный отправитель пакетов из приложения A: он ничего не передаёт, пока пользователь не включит и enabled, и send, и отправляет целые пакеты, а не живые span-ы. Отдельно настроенный плагин расширенной наблюдаемости или динамический плагин может создать другой путь данных, и такой путь требует собственной проверки политики.

Сбор выключен, пока его не включит политика Hermes:

telemetry:
  shared_metrics:
    enabled: true

Этот выбор читается из собственного config.yaml профиля. Управляемый машиной оверлей конфигурации не может включить или выключить общие метрики от имени профиля.

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

HERMES_NEMO_RELAY_PLUGINS_TOML заменяет пользовательский файл явно выбранным; системный файл по-прежнему применяется поверх него. Конфигурация внутри репозитория игнорируется. Если явно выбранный файл загрузить не удалось, Hermes сообщает об ошибке и продолжает работу без плагинов Relay, а не откатывается к другой конфигурации.

Запустите hermes doctor, чтобы увидеть, какие файлы применяются. Его раздел NeMo Relay Plugins перечисляет каждый файл, который находит Relay, говорит, включён ли хоть один плагин, и показывает любые проблемы, о которых сообщает Relay, — не загружая код плагинов.

Сегментация session-span для непрерывных сессий

Relay экспортирует span, когда закрывается его область видимости. Непрерывная сессия шлюза может жить сутками, поэтому её span сессии остаётся открытым, хотя span каждого хода экспортируется как обычно. Опциональная сегментация вращает на границе хода только область видимости сессии:

gateway:
  telemetry:
    session_segments:
      on_compaction: false  # вращать после компактизации контекста
      max_turns: 0          # 0 = без ограничений; N = ходов на сегмент

Оба значения по умолчанию сохраняют одну область видимости сессии на всё её время жизни. У span-ов после вращения остаётся тот же session_id, к нему добавляются hermes.session.segment и hermes.session.segment_reason (compaction или max_turns).

Рабочий каталог в данных области

Когда Hermes знает логический рабочий каталог сессии или задачи, стартовые области hermes.session и hermes.turn включают его в ATOF как data.cwd. Поэтому у хода, выполняемого в worktree задачи, каталог может отличаться от каталога сессии, которой он принадлежит. Неизвестные каталоги опускаются, а данные конца области по-прежнему зарезервированы под исход.

Рабочий каталог — входные данные области Relay, так что его видит каждый включённый подписчик Relay, а не только ATOF. По путям можно узнать имена пользователей, названия репозиториев или устройство точек монтирования. Relay не фильтрует события по рабочему каталогу; если путь не должен покидать хост, используйте доверенный локальный коллектор или не включайте удалённый экспортёр для этого процесса.

Марки компактизации

Когда runtime Relay жив, Hermes отправляет одну марку Relay с data_schema: {"name": "hermes.compaction", "version": "1"} для каждого из этих источников:

• каждая попытка compress_context, которая вернулась, включая заблокированные, направленные в Codex и прерванные;
• каждый проход микрокомпактизации;
• каждая зафиксированная проактивная обрезка результатов инструментов;
• каждая компактизация треда Codex app-server, которую Codex выполнил сам, а Hermes её заметил.

Для марки настройки не нужны, потому что экспортёры Relay настраиваются отдельно. Другие перезаписи истории и запроса марок пока не порождают: нативная компактизация OpenAI Responses и обрезка элементов перед её контрольной точкой, уменьшение изображений после отказа провайдера, усечение только запроса и автоматический сброс сессии в шлюзе после хода, закончившегося compression_exhausted: он заменяет сессию новой пустой, а не компактизирует её.

Фиксация, у которой не удалось разделение сессии уже после сохранения компактизированной истории, всё равно считается committed (модель дальше видит компактизированную историю), с failure_class: session_split_failed и split_status: failed_not_indexed.

Родитель марки — живой hermes.turn той же сессии либо область hermes.session, когда компактизация идёт вне хода (гигиена шлюза). При compression.in_place: false фиксация с ротацией переводит агента в дочернюю сессию, у которой нет области Relay, пока её не откроет более поздний вызов LLM под управлением Relay или следующий ход. Пока области нет, компактизация в дочерней сессии (второй предварительный проход или проход микрокомпактизации перед концом хода) получает в родители живой hermes.turn, в котором агент стартовал, а data.session_id по-прежнему называет дочернюю сессию. Марка не отправляется ни из хода, который Relay не инструментирует (второй параллельный ход той же сессии), ни из форка с отвязанным сохранением вроде фонового ревью: их компактизация переписывает только их собственную расшифровку.

data плоская, чтобы OpenTelemetry разворачивал каждое поле в nemo_relay.mark.data.<key>. Каждый ключ v1 присутствует в каждой марке; неприменимое значение — null. Категориальные поля берутся из этих закрытых множеств, кроме двух идентификаторов суммаризатора:

Значение вне закрытого множества читается как other. failure_class берёт классы hermes.compression.count плюс классы, существующие только у попытки (выходы защитных проверок вроде blocked:cooldown, выходы маршрута Codex вроде codex_auto_native, выходы аренды session_ownership_lost, session_ownership_unreadable и cooldown_state_unreadable, empty_transcript (движок контекста не вернул сообщений), summary_model_benched и исходы микрокомпактизации), none, когда класса нет, и other для всего остального. Автоматический вызов, не передавший метку триггера, читается как trigger: unknown при trigger_class: auto; запись вообще без триггера читается как unknown в обоих полях. in_place и session_rotated выставляются, только когда split_status равен in_place_committed или rotated_committed; cache_break равен null при scope: provider.

Числовые поля несут эффект (tokens_before, tokens_after, tokens_reclaimed, messages_before, messages_after, items_dropped) и тайминги (duration_ms, summary_generation_ms, aux_call_duration_ms, queue_wait_ms, commit_ms). Число токенов — грубая оценка только по сообщениям (token_count_method: estimate_rough). Полезная нагрузка никогда не содержит текст сообщений, текст сводки, тему фокуса (только has_focus_topic), текст ошибок и пути к файлам. attempt_id и session_id нужны для корреляции; не используйте их как метки метрик.

Ходы Codex app-server выполняют вызовы модели внутри Codex, поэтому Relay не записывает для них старт LLM. Перезапись фиксирует их марка compaction; сброс актуальности влияет только на более поздний вызов LLM на стороне Hermes в той же области сессии. Компактизация, которую Hermes запускает принудительно, записывается один раз — её попыткой compress_context: следующий ход Codex отбрасывает уведомления хода компактизации и не может сообщить о ней повторно.

Известные пробелы в v1:

• При gateway.telemetry.session_segments.on_compaction: true фиксация с ротацией вне любого хода закрывает старую сессию Relay до отправки марки, и марка теряется. Сейчас ни один вызов так не делает: ручной /compress откладывает это уведомление до момента после марки, а гигиена шлюза компактизирует на месте.
• Зарезервировано для будущих версий и в v1 никогда не отправляется: kind request_truncation / window_reduction, scope: request, trigger: recovery, outcome: noop и token_count_method: provider_usage.

Политика плагинов на весь процесс и изоляция профилей

Конфигурация плагинов Relay — это решение уровня развёртывания процесса, а не настройка профиля Hermes. Первый обслуживаемый профиль запускает ленивую инициализацию, и каждый следующий профиль, который обслуживает этот процесс Hermes, разделяет получившиеся статические middleware, динамические плагины, подписчиков, экспортёры и политику ограничений (guardrails). После успешной инициализации Hermes пишет в лог загруженные файлы:

The Relay plugin host is active process-wide and applies to all profiles hosted by this Hermes process. Configuration files: /home/user/.config/nemo-relay/plugins.toml; /etc/nemo-relay/plugins.toml

Области видимости профилей внутри этой общей политики по-прежнему сохраняют причинную изоляцию. ATIF группирует события по их верхнеуровневой области видимости Agent, так что одновременные сессии разных профилей дают отдельные траектории, а не одну смешанную. ATOF и другие глобальные подписчики видят события всех обслуживаемых профилей. Статические и динамические middleware точно так же выполняются для управляемых вызовов из каждого профиля.

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

Если профилям нужны разные уровни доверия, учётные данные плагинов, адресаты экспорта или политики ограничений — запускайте их в отдельных процессах Hermes. Этот процессный контракт плагинов не меняет независимое согласие каждого профиля на общие метрики, его локальное состояние SQLite и группировку траекторий ATIF.

Ядро Hermes владеет одним хостом Relay и одной изолированной областью видимости сессии Relay на каждую сессию Hermes. Продюсеры жизненного цикла в ядре получают через agent.relay_runtime общий дескриптор сессии или выполняют в контексте этой сессии API областей видимости, LLM, инструментов и марок Relay. Новые продуктовые марки не требуют регистрации плагина Hermes. Марки общих метрик по-прежнему должны содержать только поля, одобренные версионированным списком разрешений; жёсткая зависимость не меняет политику сбора и приватности.

Текущие срезы

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

Hermes turn, API, tool, and approval hooks
  -> Relay session, task, LLM, tool, and mark lifecycle
  -> Hermes shared-metrics subscriber
  -> SQLite counters
  -> immutable JSON delta package

Hermes отправляет пустой LLMRequest в жизненный цикл, принадлежащий метрикам. Это не тот отдельный управляемый вызов через нативный runtime, который описан выше. Терминальное событие метрик содержит идентификатор модели и маршрут провайдера, которые Hermes использовал для логического вызова, например nvidia/nemotron-3-ultra через openrouter. Эти идентификаторы приводятся к нижнему регистру и ограничены структурно, но не нормализуются по каталогу моделей из репозитория. Ценообразование и классификация по семействам моделей — забота бэкенда метрик. Промпты, ответы, эндпоинты, ошибки, идентификаторы сессий, задач и запросов в событие метрик и в пакет не попадают. Новые вызовы используют hermes.model_route.count. Начиная со схемы пакета v3, каждая строка маршрута также несёт call_role (primary или auxiliary), outcome (success, failed, cancelled) и error_class: собственное значение FailoverReason классификатора ошибок (rate_limit, auth, context_overflow, …) для последней неудачной попытки этого логического вызова либо none. Строка success с классом, отличным от none, — это вызов, который восстановился после такой ошибки. Вспомогательные вызовы (заголовки, сжатие, зрение, …) подчиняются тем же правилам: одна строка на логический вызов независимо от числа попыток через запасные варианты, классификация тем же классификатором (тело HTTP-200 с объектом error провайдера классифицируется по этому объекту), cancelled с none, если Hermes прервал вызов (/stop, Ctrl+C, прерывание, завершение работы), и unknown только когда классификатор не может назвать сбой. Вспомогательный вызов, идущий рядом с ходом (генерация заголовка) и завершающийся под собственными живыми областями хода, всё равно считается: его результат закрывает область, когда ход его вычерпывает. У вспомогательных строк ttft_bucket равен unknown: большинство вспомогательных вызовов не стримятся. Прежний контракт hermes.model_call.count остаётся только читаемым — чтобы ожидающие локальные счётчики, созданные старыми сборками, можно было экспортировать без потери данных.

Первый старт сессии с согласием порождает пустую марку Relay hermes.client.active. Подписчик уровня профиля создаёт случайный UUID идентичности установки и через транзакционный compare-and-set записывает не более одного счётчика активного клиента в любом скользящем 24-часовом окне. У метрики нет измерений; версия Hermes, семейство ОС, архитектура и способ установки остаются ограниченными ресурсами пакета. Параллельные процессы Hermes делят одну защёлку SQLite, поэтому одновременные старты не могут посчитать одну установку дважды. Более поздняя сессия или задача может снова попытаться поставить марку, но подписчик подавляет её до истечения скользящего окна.

Каждый запуск задачи — это область видимости Relay Function с именем hermes.task_run, вложенная в сессию Hermes, которой она принадлежит. Стартовый счётчик содержит только ограниченные значения поверхности выполнения и точки входа плюс, для задач шлюза, встроенную platform обмена сообщениями (telegram, discord, slack, …; платформы, которые Hermes поставляет в plugins/platforms/, — по имени; платформа из plugin-catalog/ — по имени записи каталога, только если собственная запись установщика доказывает установку из каталога; любая другая платформа-плагин — plugin; любая другая поверхность — none). Терминальный счётчик (hermes.task_run.finished) содержит поля старта плюс ограниченные исход, причину завершения, статус прерывания и failure_class для упавших задач: FailoverReason провайдера, если ход умер на классифицированной ошибке API, иначе локальный класс (empty_response, context_compression, repeated_errors, exception, other, …). То же событие завершения питает hermes.task_run.duration с поверхностью выполнения, исходом, корзиной длительности и корзиной числа повторов провайдера. Пакет v2 нёс длительность, повторы и число вызовов модели и инструментов на задачу прямо в терминальной строке, из-за чего почти каждая задача становилась отдельной строкой; число вызовов на ход живёт в hermes.task_cost.count. Сырые причины выхода машину не покидают. Повторы — это дополнительные попытки провайдера для одного и того же идентификатора API-запроса Hermes; они не раздувают число логических вызовов модели. Вызовы инструментов дедуплицируются по идентификатору вызова инструмента Hermes после того, как замечен терминальный результат инструмента. Внешняя граница выполнения AIAgent закрывает задачу при обычном возврате, раннем возврате, исключении и отмене. Если Hermes вращает сессию разговора во время сжатия контекста, владение активной задачей следует за идентификатором задачи.

Измерение entrypoint (в hermes.task_run.started, hermes.task_run.finished и hermes.session.count) говорит, кто запустил выполнение; значения берутся из закрытого множества:

Запуск считается one_shot или background, когда его процесс несёт маркер HERMES_SINGLE_QUERY_SESSION, который выставляют one-shot пути (тот же маркер читают источник сессии и cache_ttl: auto). Вовлечённость (hermes.engagement.*) и строки только для наблюдаемых запусков (стоимость задач, использование инструментов за сессию, трение моделей) относятся к one_shot так же, как к interactive, — как до появления этого значения; запуски background и delegated неконтролируемые и там исключены. Пакеты, записанные до появления one_shot, несут такие запуски как interactive и по-прежнему проходят проверку. hermes -z выходит через os._exit, поэтому закрывает свою сессию метрик перед выходом, а не полагается на хук atexit.

Каждый вызов инструмента представлен жизненным циклом инструмента Relay с именем hermes.tool_call. Терминальный счётчик содержит только ограниченные корзины категории инструмента, исхода и исхода одобрения; то же событие питает hermes.tool_call.latency с категорией инструмента, корзиной задержки и явной корзиной числа повторов (пакет v2 нёс задержку и повторы в терминальной строке, по одной строке на несколько вызовов). Категорию Hermes выводит из набора инструментов, уже объявленного в его runtime-реестре; пользовательские и нераспознанные наборы схлопываются в other, а имена инструментов и плагинов не экспортируются. То же терминальное событие питает и hermes.tool.usage.count с tool_name, outcome и error_class. tool_name экспортируется только для инструментов, объявленных в статическом toolsets.TOOLSETS репозитория (toolsets.BUILTIN_TOOL_NAMES, снятый до создания любого пользовательского набора в runtime); инструменты MCP дают mcp, а любой инструмент плагина или пользовательский — plugin. error_class отображает собственные значения error_type Hermes (tool_error, timeout, interrupted, invalid_arguments, blocked, contract_violation); любое другое значение, например имя класса исключения, схлопывается в exception. Повторы Hermes не угадывает по повторяющимся именам инструментов или соседним вызовам: если хук не даёт явной связи повтора, корзина повторов получает значение unknown. Решения об одобрении порождают марки hermes.tool_approval и записываются либо с привязкой к вызову инструмента, либо явно как unattributed. Имена не встроенных инструментов, идентификаторы вызовов, аргументы, результаты, команды, описания и текст ошибок в события и пакеты общих метрик не входят. Запущенный инструмент, который всё ещё открыт на момент завершения задачи, закрывается как упавший, просроченный или отменённый и остаётся в корзине счётчика инструментов этой задачи.

Успешные изменения навыков порождают марки hermes.skill.lifecycle только с ограниченным действием и происхождением. Успешные загрузки порождают марки hermes.skill.load с ограниченным происхождением, состоянием «первое использование / повторное», состоянием «повторное после патча», корзиной числа использований и skill_name: имя навыка — только если это навык, который поставляет сам Hermes (skills/ или optional-skills/), иначе custom. Повторное использование и непрерывность поколений патчей Hermes вычисляет транзакционно в своём существующем состоянии skills/.usage.json; имена локальных навыков и навыков, созданных агентом, а также точные счётчики и поколения никогда не попадают в события метрик Relay, измерения SQLite или пакеты. Использование после нового патча считается один раз как reused_after_patch; последующие использования остаются обычным повторным использованием до следующего патча. Привязка исхода задачи к патчу отложена, пока не определены её окно и семантика для нескольких навыков.

Раз в скользящие 24 часа первая активация также порождает марку hermes.install.snapshot, описывающую, как настроен профиль: провайдер памяти (имя встроенного провайдера, builtin или plugin), корзины числа серверов MCP, включённых плагинов, установленных навыков, включённых заданий cron, профилей и подключённых платформ обмена сообщениями, идентификатор основного провайдера, терминальный бэкенд (local, docker, ssh, … или other), язык интерфейса (поставляемая локаль или other) и install_age_bucket: как давно началась самая первая сессия профиля. Возраст установки позволяет бэкенду отличить нового пользователя от старого, который только что дал согласие. Имена серверов, плагинов, навыков, заданий и профилей в событие не читаются никогда. Та же защёлка compare-and-set, что и у hermes.client.active, держит его в одной строке на установку в сутки, а продюсер проверяет защёлку до обхода дерева навыков.

Снимок также несёт шесть полей об отставании версий, канале и оборудовании; все читаются офлайн (без сетевых вызовов и подпроцессов):

• release_channel (stable, main, dev, unknown): канал, зашитый в упакованную сборку (канареечные сборки main читаются как main), запись о канале в установке из исходников, иначе ветка checkout (main для main/master, dev для любой другой ветки). URL git-remote и имена веток в событие не читаются никогда.
• version_age_bucket (lt_7d … gte_90d, unknown): возраст установленной версии по дате её собственного коммита в штампе установки или checkout.
• behind_bucket (0, 1, 2, 3_to_5, 6_to_10, gte_11, unknown): на сколько коммитов или релизов отстаёт версия, только по кэшированному результату проверки обновлений для этой самой ревизии не старше 7 дней; иначе unknown.
• ram_bucket (lt_8g … gte_128g, unknown): установленная память, округлённая до номинального размера (итог ОС, умноженный на 1,1 на резервирование под прошивку).
• gpu_class (nvidia, amd, intel, apple_silicon, none, unknown): вендор GPU с наивысшим приоритетом по /proc/driver/nvidia или PCI-идентификаторам вендоров DRM в Linux, по классу в реестре видеоадаптеров в Windows, по нативной arm64 в macOS. Никогда не название модели, не версия драйвера и не объём VRAM.
• local_model_provider_used (yes/no): работает ли основная модель или любая вспомогательная задача на локальном или self-hosted сервере (идентификатор локального провайдера вроде Ollama/LM Studio/llama.cpp или базовый URL в loopback/частной сети). Сам URL остаётся на машине.

Метрики для продуктовых решений

Они отвечают на продуктовые вопросы, которые счётчики активности не покрывают: что удерживает людей, где отваливаются новые пользователи, какие поверхности и модели несут реальную нагрузку и в какие расширения стоит вкладываться. Каждое измерение — закрытое перечисление, корзина, идентификатор провайдера/модели (как в маршрутах моделей) или публичное имя, которое поставляет сама Nous.

Ответы, которые несёт relay-коннектор, сообщают платформу, на которой идёт разговор (платформа входящего сообщения, а когда коннектор представляет ровно одну платформу — она), но никогда не relay; relay остаётся, только когда неизвестно ни то ни другое. Ход, входящее сообщение которого коннектор не пометил, всё равно считается сообщением шлюза (execution_surface=gateway, у задачи/сессии platform=relay). hermes.platform.health для relay-коннектора остаётся relay: его единственный сокет представляет несколько платформ, поэтому подключение или обрыв не принадлежат ни одной из них в отдельности.

Десктопное приложение: что используют, что мешает, что отключают

Записывается приложением Desktop в хранилище профиля в фокусе, только пока у этого профиля включён переключатель сбора. Когда он выключен, приложение не хранит локальной записи (выключение удаляет то, что было сохранено) и ничего не отправляет. Приложение держит одну локальную запись на подключение к шлюзу и профиль, общую для окон этого профиля; после смены профиля ничего не хранится и не отправляется, пока не прочитан переключатель нового профиля, а сам переключатель перечитывается, когда окно вновь получает фокус (так что отказ через CLI или в другом окне действует и здесь). Запросов оценки и другого нового UI нет; каждый факт берётся из взаимодействия, которое в приложении уже есть. Каждое значение — закрытый идентификатор, определённый в коде приложения (область, действие, уведомление, сценарий, переключатель, шаг), опубликованный ключ конфигурации или корзина. Текст сообщений, текст тостов, имена сессий/ботов/профилей, пути и значения настроек не уходят никогда.

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

Качество, трение и давление контекста по моделям

Провайдер и модель подчиняются правилам маршрута модели: провайдер, который поставляет Hermes (встроенный, профиль plugins/model-providers/ из дерева исходников или публичный идентификатор models.dev), и его идентификатор модели; пользовательские эндпоинты, плагины провайдеров, установленные в $HERMES_HOME/plugins/model-providers/ или из pip (включая имена и алиасы), локальные алиасы серверов для custom (ollama, local, vllm, llamacpp, llama-cpp, llama.cpp) и серверы на loopback читаются как custom. Поставляемый провайдер, чей эндпоинт — сервер на loopback (lmstudio под любым из его алиасов), сохраняет своё имя, но его модель читается как custom. Модель, чей провайдер неизвестен или чей идентификатор — URL, путь к файлу, сетевой адрес (host:port, IP-адрес, localhost) или ARN AWS (он содержит идентификатор аккаунта), читается как custom. У провайдеров Azure идентификатор модели — это имя развёртывания, выбранное владельцем, поэтому он проходит только когда это публичный идентификатор модели (каталоги моделей Hermes или локальный кэш models.dev, например gpt-4o); acme-legal-prod читается как custom. Локальный подписчик заново применяет эти правила к полям провайдера и модели каждой марки и отбрасывает строку, которую они переписали бы.

Точность обвязки агента

Эти метрики настраивают сам цикл агента. Собственные циклы фонового ревью и куратора Hermes не считаются никогда; делегированные субагенты — считаются (их вызовы инструментов, циклы и ответы — тоже поведение модели). Текст команд, пути к файлам, аргументы инструментов и текст ответов не уходят никогда — только закрытые значения ниже.

Эффективность: стоимость хода, потери, накладные расходы инструментов и разрывы кэша промптов

Провайдер и модель подчиняются правилам маршрута модели выше. «Ход пользователя» — одно сообщение пользователя вплоть до итогового ответа; работа, которой владеет Hermes (фоновое ревью памяти/навыков, куратор, собственные ходы делегированных субагентов), ходом пользователя не считается. cache_break и tool_output_truncation описывают поведение модели и инструментов, поэтому делегированные субагенты там считаются; фоновое ревью и куратор — никогда.

Вовлечённость и неявная удовлетворённость моделью

Активное время накапливается локально по суткам UTC: сумма пауз между последовательными взаимодействиями (ход пользователя, начинающийся или заканчивающийся на интерактивной поверхности, либо сообщение шлюза; неконтролируемые запуски cron, которые считает hermes.cron.run, делегированные дочерние, фоновое ревью, куратор, пакетный режим и встраивание через сервер API / Python исключены), каждая пауза ограничена 5 минутами. Строки суток записываются, когда сутки закрываются первым взаимодействием в более поздний день, в одной транзакции базы данных, так что сутки сообщаются ровно один раз на профиль, сколько бы процессов ни увидели смену суток; они датируются сутками, которые описывают. Основная модель — та, что обслужила больше всего ходов пользователя в этот день (none, если таких не было), её имя задают правила маршрута модели. Дни активности в неделю и возврат по моделям выводятся на сервере из этих суточных строк и существующего install_id: Hermes не хранит для них ни недельного окна, ни идентификатора, кроме install_id.

active_profile_count_bucket считает различные профили хоста с ходом, которым владеет пользователь (взаимодействия выше), в эти сутки UTC. Каждый профиль сворачивает свои ходы в один накопитель хоста, который лежит в базе корневого (по умолчанию) профиля, как непрозрачные локальные хеши домашнего каталога каждого профиля, которые его никогда не покидают, так что профиль считается один раз, какой бы процесс или мультиплексированный runtime его ни обслуживал. Число несёт только строка суток корневого профиля (он сообщает сутки, даже когда сам корневой простаивал, с 0 активных минут и поверхностей); строка любого другого профиля читается как 0. Когда у корневого профиля сбор выключен, в его базу ничего не пишется, и число не сообщается.

Онбординг и сигналы о функциях

Причины сбоев установки и обновления

Начиная со схемы пакета v4 (расширена на месте; только добавления, так что любая уже отправленная форма остаётся допустимой), две существующие метрики говорят, почему они упали. Строки, записанные до изменения, сохраняют прежний набор полей и по-прежнему упаковываются.

Свежие установки

Локальное состояние пишется в:

$HERMES_HOME/telemetry/shared_metrics/metrics.sqlite3
$HERMES_HOME/telemetry/shared_metrics/outbox/*.json

База хранит транзакционные агрегаты и состояние outbox пакетов. Файлы пакетов — неизменяемые дельта-документы, соответствующие закрытой JSON-схеме и записываемые атомарной заменой как компактный JSON (jq . выведет его с отступами). Когда сервис приёма принял или отклонил пакет, база хранит только его состояние отправки и сбрасывает свою копию тела; локальной историей остаётся файл. Каждый пакет фиксирует версию Hermes, семейство ОС, архитектуру и способ установки как ограниченные ресурсы клиента. Нераспознанные значения платформы или способа установки экспортируются как unknown; сырые строки платформы, имена хостов и пути не включаются никогда. Полностью упакованные строки агрегатов, а также строки и файлы успешно экспортированных пакетов хранятся локально 30 дней. Ожидающие строки пакетов и счётчики с неэкспортированными дельтами не удаляются никогда. Схемы пакетов v1, v2 и v3 для существующих файлов outbox не меняются. Новые пакеты используют v4, которая добавляет failure_class в hermes.compression.count и hermes.memory.op.count и по-прежнему принимает их наборы полей из v3 (а также, будучи расширена на месте только добавлением значений, и после выхода v4 в стабильном релизе, — failure_class в hermes.extension.install.count / hermes.update.run и registry в первой из них, с приёмом их прежних наборов полей v4), так же как v3 принимала наборы полей v2 для hermes.model_route.count, hermes.tool_call.count и счётчиков задач, — чтобы счётчики, записанные до обновления, безопасно сливались. Словари, выведенные из реестров в репозитории (имена инструментов, платформы, провайдеры памяти, классы ошибок), ограничены в схеме JSON шаблонами; авторитетный список разрешений — это shared_metrics_contract.py.

Каждый пакет содержит install_id, сгенерированный как случайный UUID. Несмотря на имя поля в схеме, сейчас его область — один HERMES_HOME, так что точнее называть его постоянным псевдонимным идентификатором профиля. Он не выводится из данных оборудования, аккаунта, хоста, пути или учётных данных. Он стабилен между пакетами этого профиля и потому может связывать эти локальные пакеты между собой. Удаление $HERMES_HOME/telemetry/shared_metrics сбрасывает идентификатор вместе со всеми агрегатами и файлами пакетов.

Удалённая доставка — opt-in и по умолчанию выключена. Повторное использование постоянного локального идентификатора на удалённой стороне требовало отдельного продуктового и приватностного решения, охватывающего согласие, область идентичности, поведение при сбросе, хранение и удаление — это решение принято.

Эти решения зафиксированы в приложении A, а реализующий их экспортёр уже выпущен. Сам по себе сбор всё так же ничего не передаёт: отправитель работает только при истинном telemetry.shared_metrics.send. Каждый переданный пакет несёт стабильный install_id как есть (продуктовое решение от 2026-08-27 — см. запись в A.2, включая отменённую схему с HMAC-псевдонимом).

Идентичность установки ограничена одним HERMES_HOME. Чтобы сбросить её, остановите процессы Hermes и удалите $HERMES_HOME/telemetry/shared_metrics. Так намеренно удаляются вместе старая идентичность, база агрегатов и локальные пакеты в очереди; следующая сессия с согласием создаёт новую идентичность. Отключение общих метрик останавливает новый сбор, но не удаляет молча ранее собранное локальное состояние.

Smoke-тест

Прогоните настоящий ход CLI Hermes против детерминированного локального сервера модели:

./.venv/bin/python scripts/smoke_nemo_relay_shared_metrics.py

По умолчанию скрипт использует установленную зависимость nemo-relay. Передавайте --relay-python ../nemo-relay/python только при тестировании локально собранной привязки Relay.

Smoke-тест заставляет локальную модель сделать настоящий вызов инструмента read_file перед финальным ответом, а затем прогоняет через установленную привязку Relay переходы навыков: create, load, reuse, patch, edit, stale, archive, restore и install. Он проверяет счётчики модели, провайдера, задач, инструментов и навыков в SQLite, валидирует все экспортированные дельта-пакеты по закрытой схеме, проверяет псевдонимный счётчик активного клиента и убеждается, что в пакетах нет «канареек» — промпта, ответа, идентификатора вызова инструмента, результата инструмента и имени навыка.

Приложение A: решения по удалённому экспортёру (фаза 2)

Статус: реализовано. Это приложение отвечает на продуктовые и приватностные вопросы, которые раздел «Текущие срезы» откладывал до будущего удалённого экспортёра. Здесь записано, что решено и почему, — чтобы обоснование пережило реализацию.

Отправка по умолчанию выключена и требует одновременно telemetry.shared_metrics.enabled и telemetry.shared_metrics.send.

Экспортёр отправляет файлы пакетов, уже записанные в $HERMES_HOME/telemetry/shared_metrics/outbox/, в сервис приёма телеметрии Hermes. Этот сервис проверяет только конверт (schema_version плюс UUID package_id) и сохраняет тело дословно в S3.

A.1 Согласие

Передача — отдельный opt-in, независимый от сбора, под новым ключом конфигурации:

telemetry:
  shared_metrics:
    enabled: false   # собирать локально
    send: false      # НОВОЕ: передавать в сервис телеметрии Nous

• send по умолчанию false. Сам по себе сбор ничего не передаёт.
• send требует enabled, но не подразумевает его: флаг передачи не должен молча включать сбор. send: true при enabled: false выдаёт предупреждение и ничего не делает.
• Как и enabled, send принадлежит профилю и не переопределяется конфигурацией управляемой области.

Оба ключа спрашивают один раз на профиль, с одними и теми же тремя ответами везде («Send to Nous» / «Local only» / «No thanks»):

«No thanks» — вариант по умолчанию в терминале, так что нажатие Enter никого не включает. Esc в терминале и ✕ на баннере дашборда оставляют вопрос открытым, и его зададут снова в следующий раз. Полоса Desktop появляется только после того, как первый онбординг завершён или пропущен, и никогда не показывается во внутреннем профиле настройки, где идёт приветственный чат. Ответ на любой поверхности записывает оба ключа в config.yaml профиля плюс offer_version, а профиль, у которого уже есть любой из ключей, больше не спрашивают. Управляемой установке предложение не показывают никогда.

Одно исключение: до исправления буфера опережающего ввода нажатие Enter во время запуска hermes chat могло сохранить «No thanks» до появления вопроса. Поэтому «No thanks», записанный без offer_version, предлагают ещё раз на каждой поверхности, с пояснением почему. Любой ответ закрывает вопрос навсегда, включая Esc или ✕ на баннере, которые сохраняют «No thanks». Ответы с согласием не спрашивают повторно. Чтобы позже изменить ответ, используйте hermes setup telemetry, hermes tools или Settings › Safety › Privacy & network в Desktop.

Пакет отправляется только тогда, когда весь его период попадает внутрь записанного окна согласия. Согласие хранится как явные интервалы в SQLite-хранилище общих метрик (send_consent_windows): окно открывается, когда send: true замечен впервые, подтверждается вперёд каждым следующим наблюдением и закрывается — в последний подтверждённый момент, а не по настенным часам, — когда замечен send: false. Единственный согласователь выводит эту таблицу из конфигурации при каждом старте процесса, так что изменения через мастер настройки, ручные правки config.yaml и отзывы согласия посреди прохода идут одним и тем же путём, и ни один из них не может пропустить переход.

Любой пакет, период которого предшествует первому окну, попадает между окнами или выходит за новейший подтверждённый момент, исключается — шлюз закрывается при отказе (fail closed). Поэтому свежий пакет ждёт не больше одного старта процесса после завершения своего периода, прежде чем станет пригодным к отправке.

Шлюз проверяет период, а не время создания пакета. Один период раскладывается на несколько пакетов, созданных в разные дни: первый пакет дня пишется в тот же день, а хвостовой пакет за тот же период обычно появляется на следующий. Если бы проверялось время создания, хвост периода ушёл бы, а голова отбросилась — и день оказался бы молча недосчитан. Проверка по периоду держит согласие направленным только вперёд, а каждый переданный период — полным.

Локальная история может накапливаться до 30 дней, и эти данные собирались под обещание, что ничего не выгружается. Уважение к согласию только вперёд стоит максимум 30 дней накопившегося бэклога, на отправку которого разрешения у нас никогда не было.

A.2 Область идентичности — стабильный install_id передаётся как есть

Запись о решении. Исходная схема этого экспортёра (и редакции 1–8 этого приложения) передавала вместо идентификатора ключевой псевдоним: HMAC-SHA256(key = локально хранимая ротируемая соль, message = install_id), с ротацией соли каждые 30 дней. 2026-08-27, до выпуска фичи (ноль согласившихся пользователей, ноль передач в продакшене), владелец продукта решил, что аналитике нужна стабильная идентичность сквозь окна — кривые удержания, поведение установки во времени, — а ротация по своей природе именно это и разрушает. Слой псевдонимизации убрали целиком, а не ослабили на месте.

Что передаётся теперь:

• Каждый пакет несёт install_id дословно: постоянный случайный UUID уровня профиля, описанный выше.
• Он генерируется локально (uuid4), не содержит сведений об оборудовании, аккаунте, пользователе или машине и идентифицирует профиль, а не человека.
• Он стабилен, пока пользователь не удалит каталог общих метрик, что генерирует его заново (см. A.4).

Последствия — названы прямо, а не замазаны:

• Пакеты одного профиля коррелируют бессрочно, а не в пределах окна. Долгосрочная связываемость последовательности ежедневных конвертов одной установки теперь спроектированное поведение, а не побочный остаток.
• Анализ остаточных рисков старой схемы из A.3 (стабильный кортеж resource плюс смежные периоды, перекидывающие мост между окнами ротации) потерял смысл — границ окон, через которые можно было бы перекинуть мост, больше нет.
• Текст согласия в мастере настройки описывает эту модель идентичности явно; его обновили в том же изменении, которое убрало вывод псевдонима, так что ни в одной выпущенной сборке согласие не собиралось под старой формулировкой.

Побайтово идентичные повторные отправки сохраняются. Передаваемый идентификатор записывается в строку (sent_install_id) при первой подготовке пакета, а тело для передачи всегда собирается из этого записанного значения, поэтому повтор даёт идентичные байты. Этого требует контракт: повторная отправка package_id с другим содержимым — неопределённое поведение. (Со стабильным идентификатором записанная копия уже не защищает от ротации — она остаётся как столбец аудита и дешёвая страховка от любых будущих изменений семантики идентичности.)

A.3 Ротация — убрана (запись о решении)

Ротацию соли удалили вместе с выводом псевдонима (продуктовое решение, 2026-08-27). Этот раздел сохранён как запись о том, что делала прежняя схема и почему её удаление приняли:

• Ротация существовала, чтобы ограничить долгосрочную связываемость: одна идентичность на 30-дневное окно, несвязанные идентичности между окнами.
• Задокументированный остаточный риск (полный анализ — в истории git): стабильный низкоэнтропийный кортеж resource в конверте плюс смежные суточные периоды и так правдоподобно позволяли связать окна для редких конфигураций, так что граница лишь повышала цену, а стеной не была.
• Продуктовая потребность, которая её и добила: непрерывность сквозь окна — ровно то, что нужно анализу удержания. Границу, которая в основном мешает честному анализу и лишь повышает цену для настойчивого корреляционщика, сочли неверным компромиссом, как только стабильная идентичность стала требованием.

В хранилище нет соли, нет расписания ротации, и нигде в конвейере нет выведенного идентификатора.

A.4 Поведение при сбросе

Удаление $HERMES_HOME/telemetry/shared_metrics по-прежнему сбрасывает локальную идентичность, агрегаты и файлы пакетов — ровно так, как описано выше. Теперь действуют две честные оговорки:

• Сброс генерирует install_id заново, так что последующие пакеты передают новую идентичность. Локальный сброс действительно даёт новую удалённую идентичность.
• Сброс не отменяет отправленное. Уже переданные пакеты остаются в хранилище сервиса приёма под тем идентификатором, с которым были отправлены. В контракте v1 нет API ни для чтения, ни для удаления.

send: false останавливает передачу немедленно: согласие перечитывается перед каждым пакетом, так что уже идущий проход останавливается после пакета, который отправляет в этот момент, а не сливает всю партию. Ранее переданные пакеты при этом не удаляются, а локальный сбор не прекращается.

Отключение отправки также закрывает окно согласия — в последний момент, когда согласие реально наблюдалось, а не по настенным часам. Пакеты, чьи периоды попадают между одним окном и следующим, не передаются никогда, даже если отправку позже включить снова, — и это верно при любом числе циклов вкл/выкл, при ручных правках без запущенного процесса и при часах, прыгающих в любую сторону (открытие окна прижимается сверху ко всем меткам времени, уже имеющимся в хранилище; отметки наблюдения продвигаются на ограниченный шаг за вызов, так что один сбойный выброс вперёд не утащит горизонт подтверждения на годы вперёд; закрытие никогда не ложится позже часов самого закрывающего наблюдения). В отличие от прежней единственной подвижной даты opt-in, закрытие и повторное открытие НЕ отбрасывает ещё не доставленный бэклог из предыдущего окна согласия — те пакеты остаются внутри своего интервала и сохраняют право на отправку.

Одно намеренное последствие для пути обновления: пакеты, экспортированные при доинтервальной модели согласия (до появления send_consent_windows), предшествуют первому записанному окну и потому после обновления никогда не передаются. Это направление «закрыться при отказе» — вернуть старую подвижную суточную отметку, чтобы их выпустить, значило бы вернуть семантику, которую пять раундов ревью показали несостоятельной, — и стоит оно максимум недоставленного бэклога, но никогда не собранных данных.

A.5 Хранение

• Локально: без изменений — 30 дней для успешно экспортированной истории, а ожидающие дельты хранятся до экспорта. Состояние отправки не продлевает локальное хранение: пакет, который так и не удалось отправить, всё равно удаляется через 30 дней. Неограниченный локальный рост при навсегда недоступном эндпоинте — худший отказ, чем потеря метрик с установки, которая сломана уже месяц.
• Удалённо: сырые пакеты хранятся в S3 бессрочно в продакшене и 30 дней на staging.

A.6 Удаление

В контракте v1 нет пути удаления на удалённой стороне, и это приложение его не выдумывает. Что может сделать пользователь:

Если когда-нибудь появится обязательство удалять данные по запросу, путь поиска теперь прямой: install_id пользователя (его можно прочитать из локального хранилища) — это ключ, под которым хранятся его данные. Построение серверного API удаления остаётся новым продуктовым решением, а не деталью реализации.

A.7 Что такое каталог outbox

Записано потому, что при планировании фазы 2 его однажды прочитали неверно — так, что это удалило бы данные пользователя.

Каталог — это локальная история, а не очередь на отправку. package_outbox — таблица SQLite; её столбец exported_at означает «записан на диск», а не «отправлен». Файлы неизменяемы и удаляются только по возрасту.

Контракт приёма говорит, что отправителям следует удалять пакет из своего outbox по 202. Экспортёр этого не делает. Удаление по подтверждению превратило бы 30-дневную локальную историю пользователя в очередь передачи и уничтожило бы состояние, которое ему обещали. Вместо этого состояние отправки живёт в новых столбцах таблицы package_outbox; передача файлов не касается.

A.8 Замечание об области действия

Поле install_id внутри тела пакета передаётся так, как его записал генератор (переписывается из замороженного sent_install_id строки, где хранится то же значение). Ни одно другое поле полезной нагрузки не меняется, ничего не добавляется, и сервис рассматривает всё тело как непрозрачное. Поэтому эволюция схемы полезной нагрузки, как и раньше, остаётся заботой отправителя.