Память Honcho
Honcho — это AI-native бэкенд памяти, который добавляет диалектическое рассуждение и глубокое моделирование пользователя поверх встроенной системы памяти Hermes. Вместо простого хранилища «ключ-значение» Honcho ведёт постоянную модель того, кто такой пользователь: его предпочтения, манера общения, цели и привычки. Модель строится за счёт анализа разговоров уже после того, как они состоялись.
Honcho встроен в систему провайдеров памяти. Все описанные ниже возможности доступны через единый интерфейс провайдера памяти.
Что добавляет Honcho
| Возможность | Встроенная память | Honcho |
|---|---|---|
| Сохранение между сессиями | ✔ Файлы MEMORY.md/USER.md | ✔ На стороне сервера через API |
| Профиль пользователя | ✔ Ручное ведение агентом | ✔ Автоматическое диалектическое рассуждение |
| Сводка сессии | — | ✔ Внедрение контекста в рамках сессии |
| Изоляция между агентами | — | ✔ Отдельный профиль на каждого peer |
| Режимы наблюдения | — | ✔ Единый или направленный |
| Заключения (выведенные инсайты) | — | ✔ Рассуждение о закономерностях на сервере |
| Поиск по истории | ✔ Поиск по сессиям через FTS5 | ✔ Семантический поиск по заключениям |
Диалектическое рассуждение. После каждого хода разговора (с шагом, заданным через dialecticCadence) Honcho разбирает обмен репликами и выводит инсайты о предпочтениях, привычках и целях пользователя. Со временем они накапливаются, и агент начинает понимать пользователя глубже, чем тот высказал напрямую. Диалектика поддерживает многопроходную глубину (от 1 до 3 проходов) с автоматическим выбором «холодного» или «тёплого» промпта: холодный запрос концентрируется на общих фактах о пользователе, тёплый — на контексте текущей сессии.
Контекст в рамках сессии. Теперь базовый контекст включает сводку сессии рядом с представлением пользователя и его peer-картой. Агент видит, что уже обсуждалось в текущей сессии, реже повторяется и держит нить разговора.
Мультиагентные профили. Когда с одним пользователем общается сразу несколько экземпляров Hermes (скажем, ассистент по коду и личный помощник), Honcho ведёт для каждого отдельный профиль peer. Каждый peer видит только собственные наблюдения и заключения — контекст не перетекает между ними.
Установка
hermes memory setup # выберите "honcho" из списка провайдеровЛибо настройте вручную:
# ~/.hermes/config.yaml
memory:
provider: honchoecho 'HONCHO_API_KEY=***' >> ~/.hermes/.envКлюч API возьмите на honcho.dev.
Архитектура
Двухслойное внедрение контекста
На каждом ходу (в режиме hybrid или context) Honcho собирает два слоя контекста и внедряет их в системный промпт:
- Базовый контекст — сводка сессии, представление пользователя, его peer-карта, самопредставление ИИ и карта идентичности ИИ. Обновляется по
contextCadence. Это слой «кто этот пользователь». - Диалектическое дополнение — синтезированное LLM рассуждение о текущем состоянии и потребностях пользователя. Обновляется по
dialecticCadence. Это слой «что важно прямо сейчас».
Оба слоя склеиваются и обрезаются до бюджета contextTokens, если он задан.
Выбор холодного и тёплого промпта
Диалектика сама выбирает одну из двух стратегий промпта:
- Холодный старт (базового контекста ещё нет): общий запрос — «Кто этот человек? Каковы его предпочтения, цели и стиль работы?»
- Тёплая сессия (базовый контекст есть): запрос в рамках сессии — «С учётом того, что уже обсуждалось в этой сессии, какой контекст об этом пользователе наиболее релевантен?»
Переключение происходит автоматически — в зависимости от того, наполнен ли базовый контекст.
Три независимых регулятора
Стоимостью и глубиной управляют три не зависящих друг от друга регулятора:
| Регулятор | Что задаёт | По умолчанию |
|---|---|---|
contextCadence | Сколько ходов между вызовами API context() (обновление базового слоя) | 1 |
dialecticCadence | Сколько ходов между LLM-вызовами peer.chat() (обновление диалектического слоя) | 2 (рекомендуется 1–5) |
dialecticDepth | Сколько проходов .chat() на один вызов диалектики (1–3) | 1 |
Они ортогональны: можно часто обновлять контекст при редкой диалектике или, наоборот, гонять глубокую многопроходную диалектику на низкой частоте. Пример: contextCadence: 1, dialecticCadence: 5, dialecticDepth: 2 обновляет базовый контекст каждый ход, запускает диалектику раз в 5 ходов, и каждый её запуск делает по 2 прохода.
Глубина диалектики (многопроходный режим)
Когда dialecticDepth > 1, каждый вызов диалектики прогоняет несколько проходов .chat():
- Проход 0: холодный или тёплый промпт (см. выше).
- Проход 1: самопроверка — находит пробелы в исходной оценке и собирает свидетельства из недавних сессий.
- Проход 2: согласование — ищет противоречия между предыдущими проходами и выдаёт финальный синтез.
Каждый проход использует пропорциональный уровень рассуждения: ранние проходы легче, основной идёт на базовом уровне. Уровни по проходам можно переопределить через dialecticDepthLevels — например, ["minimal", "medium", "high"] для запуска с глубиной 3.
Проходы прерываются досрочно, если предыдущий вернул сильный сигнал (длинный, структурированный ответ), так что глубина 3 не всегда означает 3 LLM-вызова.
Прогрев на старте сессии
При инициализации сессии Honcho в фоне запускает диалектический вызов на полной заданной dialecticDepth и передаёт результат прямо в сборку контекста для первого хода. Однопроходный прогрев на холодном peer часто возвращает скудный результат, а многопроходная глубина успевает прогнать цикл проверки и согласования ещё до того, как пользователь скажет первое слово. Если прогрев не успел к первому ходу, тот переходит на синхронный вызов с ограниченным таймаутом.
Уровень рассуждения, адаптивный к запросу
Автоматически внедряемая диалектика масштабирует dialecticReasoningLevel по длине запроса: +1 уровень при ≥120 символах, +2 при ≥400, с ограничением сверху по reasoningLevelCap (по умолчанию "high"). Отключить можно через reasoningHeuristic: false — тогда каждый автовызов будет жёстко привязан к dialecticReasoningLevel. Доступные уровни: minimal, low, medium, high, max.
Параметры конфигурации
Honcho настраивается в ~/.honcho/config.json (глобально) или $HERMES_HOME/honcho.json (локально в профиле). Мастер настройки делает это за вас.
Self-hosted Honcho с аутентификацией
Когда вы направляете Hermes на self-hosted сервер Honcho, команды hermes honcho setup (и hermes memory setup) после базового URL спросят локальный JWT / bearer-токен. Вставьте JWT, подписанный секретом AUTH_JWT_SECRET сервера (переменная окружения в compose-файле Honcho), чтобы включить аутентифицированный доступ; для серверов с AUTH_USE_AUTH=false оставьте поле пустым. Локальный токен хранится в блоке хоста (hosts.<host>.apiKey в honcho.json) отдельно от любого облачного apiKey, поэтому позже вы сможете вернуть переключатель Cloud or local? обратно в cloud, не потеряв ни одну из учётных записей.
Полный справочник конфигурации
| Ключ | По умолчанию | Описание |
|---|---|---|
contextTokens | null (без ограничения) | Бюджет токенов для автоматически внедряемого контекста на ход. Задайте целое число (например, 1200), чтобы ограничить. Обрезка идёт по границам слов |
contextCadence | 1 | Минимум ходов между вызовами API context() (обновление базового слоя) |
dialecticCadence | 2 | Минимум ходов между LLM-вызовами peer.chat() (диалектический слой). Рекомендуется 1–5. В режиме tools не используется — модель вызывает явно |
dialecticDepth | 1 | Сколько проходов .chat() на один вызов диалектики. Ограничено диапазоном 1–3 |
dialecticDepthLevels | null | Необязательный массив уровней рассуждения по проходам, например ["minimal", "low", "medium"]. Переопределяет пропорциональные значения по умолчанию |
dialecticReasoningLevel | 'low' | Базовый уровень рассуждения: minimal, low, medium, high, max |
dialecticDynamic | true | При true модель может переопределять уровень рассуждения для конкретного вызова через параметр инструмента |
dialecticMaxChars | 600 | Максимум символов результата диалектики, внедряемого в системный промпт |
recallMode | 'hybrid' | hybrid (автовнедрение + инструменты), context (только внедрение), tools (только инструменты) |
writeFrequency | 'async' | Когда сбрасывать сообщения: async (фоновый поток), turn (синхронно), session (пакетом при завершении) или целое число N |
saveMessages | true | Сохранять ли сообщения через API Honcho |
observationMode | 'directional' | directional (всё включено) или unified (общий пул). Переопределяется объектом observation для точечной настройки |
messageMaxChars | 25000 | Максимум символов на сообщение, отправляемое через add_messages(). При превышении разбивается на части |
dialecticMaxInputChars | 10000 | Максимум символов входного запроса диалектики для peer.chat() |
sessionStrategy | 'per-directory' | per-directory, per-repo, per-session или global |
pinUserPeer | false | Только для шлюза. При true каждый пользователь платформы схлопывается в peerName |
userPeerAliases | {} | Только для шлюза. Карта runtime-ID на peer’ов ({"7654321": "alice"}). Многие к одному |
runtimePeerPrefix | "" | Только для шлюза. Помещает неизвестные runtime-ID в пространство имён (telegram_7654321), когда ни один алиас не подошёл |
Стратегия сессии определяет, как сессии Honcho сопоставляются с вашей работой:
per-session— каждый запускhermesполучает свежую сессию. Чистый старт, память — через инструменты. Рекомендуется новичкам.per-directory— одна сессия Honcho на рабочий каталог. Контекст накапливается между запусками.per-repo— одна сессия на git-репозиторий.global— единая сессия для всех каталогов.
Режим recall определяет, как память попадает в разговоры:
hybrid— контекст автоматически внедряется в системный промпт И доступны инструменты (модель сама решает, когда делать запрос).context— только автовнедрение, инструменты скрыты.tools— только инструменты, без автовнедрения. Агент должен явно вызватьhoncho_reasoning,honcho_searchи т. д.
Настройки по режимам recall:
| Настройка | hybrid | context | tools |
|---|---|---|---|
writeFrequency | сбрасывает сообщения | сбрасывает сообщения | сбрасывает сообщения |
contextCadence | задаёт частоту обновления базового контекста | задаёт частоту обновления базового контекста | не используется — нет внедрения |
dialecticCadence | задаёт частоту автовызовов LLM | задаёт частоту автовызовов LLM | не используется — модель вызывает явно |
dialecticDepth | многопроходность на вызов | многопроходность на вызов | не используется — модель вызывает явно |
contextTokens | ограничивает внедрение | ограничивает внедрение | не используется — нет внедрения |
dialecticDynamic | задаёт переопределение моделью | неприменимо (нет инструментов) | задаёт переопределение моделью |
В режиме tools всё в руках модели: она вызывает honcho_reasoning, когда сочтёт нужным, на том reasoning_level, который выберет сама. Настройки шага и бюджета работают только в режимах с автовнедрением — hybrid и context.
Сопоставление идентичностей в шлюзе
Эти настройки важны только при запуске шлюза Hermes — единственной точки входа, куда пользователи приходят с платформенными runtime-ID (UID в Telegram, snowflake в Discord, пользователь Slack). У сессий CLI, TUI и десктопа runtime-ID нет, они всегда резолвятся в peerName, так что вне шлюза эти ключи ни на что не влияют.
Мастер настройки определяет, подключена ли платформа-шлюз, и полностью пропускает этот шаг, если нет. Когда он всё же запускается, то задаёт один вопрос — кто общается с этим шлюзом? — и из ответа выводит ключи:
| Ответ | Результат |
|---|---|
| только я | pinUserPeer: true — каждый не-агентский пользователь шлюза схлопывается в ваш peer. Закрепление перебивает все алиасы, поэтому выбирайте этот вариант, только если ни одной пользовательской идентичности не нужен свой peer. Если до шлюза доходят отдельные агенты и каждому нужен собственный peer, не закрепляйте — оставьте pinUserPeer: false и сопоставьте их через userPeerAliases (редактор [e]) |
| я + другие люди (общий пул) | pinUserPeer: false + сопоставление userPeerAliases ваших runtime-ID в peerName — вы остаётесь на своей общей истории, остальные получают собственных peer’ов |
| только другие люди | pinUserPeer: false, при необходимости runtimePeerPrefix — каждый пользователь получает своего peer |
Чтобы задать три ключа напрямую, выберите в приглашении [e].
Резолвер перебирает ключи сверху вниз, побеждает первое совпадение: pinUserPeer → userPeerAliases[id] → runtimePeerPrefix + id → сырой runtime-ID → peerName → запасной вариант по ключу сессии.
Переключение pinUserPeer с true на false не переносит данные — память, накопленная под peerName, остаётся там, а пользователи платформы резолвятся в свежих, пустых peer’ов. Чтобы сохранить собственную непрерывность, выберите путь с общим пулом, тогда ваши runtime-ID будут алиаситься обратно в peerName. Мастер сам предлагает этот вариант, когда замечает такой переход.
pinPeerName — это старый алиас для pinUserPeer: по-прежнему читается ради обратной совместимости (pinUserPeer побеждает там, где заданы оба), но больше не записывается. Повторный запуск настройки переносит его на канонический ключ.
Наблюдение (directional или unified)
Honcho моделирует разговор как обмен сообщениями между peer’ами. У каждого peer есть два переключателя наблюдения, которые один к одному ложатся на SessionPeerConfig из Honcho:
| Переключатель | Эффект |
|---|---|
observeMe | Honcho строит представление этого peer по его собственным сообщениям |
observeOthers | Этот peer наблюдает за сообщениями другого peer (питает рассуждение между peer’ами) |
Два peer’а × два переключателя = четыре флага. observationMode — это пресет-сокращение:
| Пресет | Флаги пользователя | Флаги ИИ | Семантика |
|---|---|---|---|
"directional" (по умолчанию) | me: вкл, others: вкл | me: вкл, others: вкл | Полное взаимное наблюдение. Включает диалектику между peer’ами — «что ИИ знает о пользователе, исходя из того, что сказал пользователь и что ответил ИИ». |
"unified" | me: вкл, others: выкл | me: выкл, others: вкл | Семантика общего пула — ИИ наблюдает только за сообщениями пользователя, а peer пользователя моделирует лишь себя. Пул с одним наблюдателем. |
Чтобы управлять каждым peer отдельно, переопределите пресет явным блоком observation:
"observation": {
"user": { "observeMe": true, "observeOthers": true },
"ai": { "observeMe": true, "observeOthers": false }
}Типичные сценарии:
| Намерение | Конфиг |
|---|---|
| Полное наблюдение (большинству пользователей) | "observationMode": "directional" |
| ИИ не должен заново моделировать пользователя по своим же ответам | "ai": {"observeMe": true, "observeOthers": false} |
| Сильная персона, которую peer ИИ не должен обновлять по самонаблюдению | "ai": {"observeMe": false, "observeOthers": true} |
Серверные переключатели, заданные через дашборд Honcho, имеют приоритет над локальными значениями по умолчанию — Hermes подтягивает их обратно при инициализации сессии.
Инструменты
Когда Honcho активен как провайдер памяти, становятся доступны пять инструментов:
| Инструмент | Назначение |
|---|---|
honcho_profile | Чтение или обновление peer-карты — передайте card (список фактов) для обновления, опустите для чтения |
honcho_search | Семантический поиск по контексту — сырые выдержки без LLM-синтеза |
honcho_context | Полный контекст сессии — сводка, представление, карта, недавние сообщения |
honcho_reasoning | Синтезированный ответ от LLM Honcho — передайте reasoning_level (minimal/low/medium/high/max), чтобы задать глубину |
honcho_conclude | Создание или удаление заключений — передайте conclusion для создания, delete_id для удаления (только для PII) |
Команды CLI
Подкоманда hermes honcho регистрируется только тогда, когда Honcho — активный провайдер памяти (memory.provider: honcho в config.yaml). На свежей установке настройте Honcho напрямую через hermes memory setup honcho (или запустите hermes memory setup и выберите его из списка); подкоманда hermes honcho появится при следующем вызове.
hermes memory setup honcho # Настроить Honcho напрямую (работает до активации)
hermes honcho status # Статус подключения, конфигурация и основные настройки
hermes honcho setup # Перенаправляет на `hermes memory setup` (псевдоним после активации)
hermes honcho strategy # Показать или задать стратегию сессии (per-session/per-directory/per-repo/global)
hermes honcho peer # Показать или обновить имена peer'ов + уровень диалектического рассуждения
hermes honcho mode # Показать или задать режим recall (hybrid/context/tools)
hermes honcho tokens # Показать или задать бюджет токенов для контекста и диалектики
hermes honcho identity # Заполнить или показать Honcho-идентичность peer'а ИИ
hermes honcho sync # Синхронизировать конфигурацию Honcho со всеми существующими профилями
hermes honcho peers # Показать идентичности peer'ов по всем профилям
hermes honcho sessions # Список известных сопоставлений сессий Honcho
hermes honcho map # Сопоставить текущий каталог с именем сессии Honcho
hermes honcho enable # Включить Honcho для активного профиля
hermes honcho disable # Отключить Honcho для активного профиля
hermes honcho migrate # Пошаговое руководство по миграции с openclaw-honchoМиграция с hermes honcho
Если раньше вы пользовались отдельной командой hermes honcho setup:
- Ваша существующая конфигурация (
honcho.jsonили~/.honcho/config.json) сохраняется. - Ваши серверные данные (воспоминания, заключения, профили пользователей) остаются нетронутыми.
- Задайте
memory.provider: honchoв config.yaml, чтобы снова активировать.
Повторный вход и повторная настройка не нужны. Запустите hermes memory setup, выберите «honcho» — мастер сам обнаружит вашу существующую конфигурацию.
Полная документация
Полный справочник смотрите в разделе Провайдеры памяти — Honcho.