zone: [system]
type: handoff
status: ready-to-send
created: 2026-05-18
priority: P1
title: Hermes team — задачи и открытые вопросы
related:

• "[[2026-05-18-execution-failure-fix]]"
• "[[2026-05-18-system-audit-S1-S5]]"
  audience: Hermes maintainers
  audit_doc: ~/katya-ai/docs/hermes-katin-jun-execution-failure-2026-05-18.md
  tags: [zone/system, hermes, handoff]

Hermes team — задачи и открытые вопросы

Это handoff-документ для Hermes maintainers. Только то, что может решить только Hermes-сторона (продукт / код / документация). Локальные правки конфига и промптов на пользовательской стороне делаются отдельно — см. [[2026-05-18-execution-failure-fix]].

Полный контекст и evidence: ~/katya-ai/docs/hermes-katin-jun-execution-failure-2026-05-18.md.

Запросы (ranked by impact)

H-1. Документировать / реализовать preload-механизм для skills

Проблема: В 8 последних sessions .hermes-work/ — 0 вызовов skill_view. Скиллы существуют (29 970-байтовые SKILL.md с продуманными правилами), но никогда не загружаются в контекст модели. Архитектура «лёгкое ядро + on-demand skills» де-факто означает «работает только лёгкое ядро».

Запрос:

• Подтвердить: есть ли в Hermes механизм preload скиллов через config.yaml?
• В hermes_cli/main.py есть комментарий «preloaded skills coming from user config» — нужен schema/key.
• Если механизма нет — рассмотреть введение skills.preload: [skill-name, ...] в config.yaml.

Acceptance: ответ либо «вот ключ» + пример, либо «нет, не поддерживаем, делайте через prompt-инструкцию», либо «вот roadmap-тикет».

H-2. Расширить loop-guard message с recovery hints

Проблема: Текущий inject в tool-result при same_tool_failure: 3 (hermes_cli/config.py):

[Tool loop warning: same_tool_failure_warning; count=3; terminal has failed 3 times this turn. This looks like a loop; change approach before retrying.]

GPT-4o (а вероятно и другие средние модели) интерпретирует это как «прекрати действовать» и навсегда переключается в text-only. Evidence: session ~/.hermes-work/sessions/session_20260518_205200_57011840.json, msg #67 — точка слома, после которой 5 text-only ответов подряд без единого tool_call.

Запрос:

• Усилить сообщение конкретными recovery actions, например:

  [Tool loop warning: terminal failed 3 times. Diagnose first: run `pwd && ls -la` in the same tool to verify your assumption. Then try: (a) absolute path instead of relative, (b) different tool (e.g., write_file instead of touch), (c) delegate_task. Do NOT switch to text-only replies — keep using tools.]
  

• Опционально: вынести шаблон в config, чтобы юзер мог тюнить.

Acceptance: обновлённый template сообщения; регресс-тест что GPT-4o при этом инжекте не уходит в text-only.

H-3. Документировать (или починить) разную базу path resolution в terminal vs write_file

Проблема: В рамках одной session persistent_shell: true корректно сохраняет CWD для terminal между вызовами. Но write_file с тем же относительным путём резолвится от другой базы (видимо $HOME или session cwd config, не от runtime-CWD terminal). Это контр-интуитивно и провоцирует ошибки модели.

Evidence: same session, msg #54 → mkdir digital-humans-ultimate && cd digital-humans-ultimate && git init создал .git в ~/digital-humans-site/digital-humans-ultimate/.git/ (CWD унаследован). Msg #60 → write_file path: "digital-humans-ultimate/index.html" записал в ~/digital-humans-ultimate/index.html. Разные места — путаница модели каскадирует.

Запрос:

• Документировать explicitly в docs/reference: «terminal использует persistent shell CWD; write_file использует base». Сейчас этого нет.
• Опционально: унифицировать (использовать общий CWD-стейт), либо предупреждать модель в tool description при первом смешанном вызове.

Acceptance: doc section + пример; в идеале — унифицированное поведение.

H-4. Best practice / template для Telegram-only агента с tool-use

Проблема: Конфигурация Katin Jun:

• Канал: только Telegram polling
• approvals.mode: manual (config.yaml:205)
• tirith_fail_open: true (config.yaml:215) — фактически пропускает destructive
• Нет интерактивной approval-сессии (Telegram её не поддерживает в текущей версии)

Это работает «случайно» — security policy не блокирует, но и не контролирует. Bot спокойно делает git push без approval.

Запрос:

• Документ или reference-config: рекомендуемая комбинация approvals.mode / command_allowlist / tirith для агента, доступного только через мессенджер без интерактивного approval-канала.
• Best practice для разводки «destructive vs safe» tool-calls в таком сетапе.

Acceptance: документ + sample config block в docs.

Дополнительные сигналы (FYI, не задачи)

Наблюдение 1 — двойственность SOUL.md между инстансами одной системы

В системе Кати два Hermes-инстанса (~/.hermes для openclaw, ~/.hermes-work для Katin Jun). У них разные SOUL.md шаблоны (38 vs 28 строк, разная структура). Это пользовательский side, но если Hermes собирается выпустить «template-минимум для агента» — это запрос пользователя.

Наблюдение 2 — skill_view как добровольный инструмент

GPT-4o оставлен сам решать когда вызывать skill_view. На практике — никогда. Возможно стоит:

• (a) Авто-инжектить description matching при первом user message (skills_hub имеет auxiliary.skills_hub provider — что он делает?)
• (b) Расширить tool description skill_view подсказкой «вызывай до первого действия по новой теме»

Наблюдение 3 — модель оркестратора

openai/gpt-4o через openrouter — приемлемая модель для tool-use, но слабая на long-running orchestration. После 3 errors каменеет. Стоит ли в reference-docs указать минимальную рекомендованную модель для агентов, делающих multi-step deploy/build/orchestrate задачи? (gpt-4.1, claude-sonnet-4-6 ведут себя устойчивее.)

Версии и evidence

• Hermes version: см. ~/.hermes-work/.update_check и cat /Users/ekaterinasum/.hermes-work/auth.json | jq .agent_version (если доступно)
• Session JSON для разбора: ~/.hermes-work/sessions/session_20260518_205200_57011840.json (179 KB, 77 messages, 28 tool_calls)
• Active SOUL.md: ~/.hermes-work/SOUL.md
• Active AGENTS.md: ~/.hermes-work/AGENTS.md
• Active config: ~/.hermes-work/config.yaml
• Loop guard config: hermes_cli/config.py keys same_tool_failure

Что Катина сторона делает локально (НЕ ваша задача — для информации)

Параллельно с этим handoff пользователь применяет два локальных патча:

1. SOUL.md += execution discipline block
2. AGENTS.md → routing contract matrix по роли отправителя

Регресс-тест двумя сценариями (Катя/DM, коллега/чат). Если фикс работает на пользовательской стороне — это не отменяет H-1..H-4, потому что patches лечат симптом, а не системную причину.

Contact

Please follow up in the GitHub issue. The local Telegram bots mentioned in evidence are affected runtimes, not reliable support channels for this report.