Память Honcho
Honcho — это бэкенд памяти для ИИ, который добавляет диалектическое рассуждение и глубокое моделирование пользователя поверх встроенной системы памяти VibeOS. Вместо простого хранения «ключ-значение» Honcho поддерживает текущую модель того, кто такой пользователь — его предпочтения, стиль общения, цели и паттерны — путем анализа разговоров после их завершения.
Honcho интегрирован в систему Провайдеров памяти. Все функции ниже доступны через единый интерфейс провайдера памяти.
Что добавляет Honcho
| Возможность | Встроенная память | Honcho |
|---|---|---|
| Постоянство между сессиями | ✔ Файловые MEMORY.md/USER.md | ✔ Серверная сторона с API |
| Профиль пользователя | ✔ Ручная курация агентом | ✔ Автоматическое диалектическое рассуждение |
| Сводка сессии | — | ✔ Внедрение контекста в рамках сессии |
| Изоляция нескольких агентов | — | ✔ Разделение профилей по пирам |
| Режимы наблюдения | — | ✔ Единое или направленное наблюдение |
| Выводы (производные инсайты) | — | ✔ Серверное рассуждение о паттернах |
| Поиск по истории | ✔ Поиск по сессиям FTS5 | ✔ Семантический поиск по выводам |
Диалектическое рассуждение: После каждого оборота разговора (с ограничением по dialecticCadence) Honcho анализирует обмен и извлекает инсайты о предпочтениях, привычках и целях пользователя. Они накапливаются со временем, давая агенту углубляющееся понимание, выходящее за рамки того, что пользователь явно заявил. Диалектика поддерживает многопроходную глубину (1–3 прохода) с автоматическим выбором холодного/теплого промпта — холодные стартовые запросы фокусируются на общих фактах о пользователе, а теплые запросы отдают приоритет контексту в рамках сессии.
Контекст в рамках сессии: Базовый контекст теперь включает сводку сессии вместе с представлением пользователя и карточкой пира. Это дает агенту осведомленность о том, что уже обсуждалось в текущей сессии, уменьшая повторения и обеспечивая непрерывность.
Многопользовательские профили: Когда несколько экземпляров VibeOS общаются с одним и тем же пользователем (например, помощник по кодингу и личный помощник), Honcho поддерживает отдельные профили «пиров». Каждый пир видит только свои собственные наблюдения и выводы, предотвращая перекрестное загрязнение контекста.
Настройка
vibeos memory setup # выберите "honcho" из списка провайдеров
Или настройте вручную:
# ~/.vibeos/config.yaml
memory:
provider: honcho
echo 'HONCHO_API_KEY=***' >> ~/.vibeos/.env
Получите API-ключ на honcho.dev.
Архитектура
Двухуровневое внедрение контекста
Каждый оборот (в режиме hybrid или context) Honcho собирает два уровня контекста, внедряемых в системный промпт:
- Базовый контекст — сводка сессии, представление пользователя, карточка пира пользователя, самопредставление ИИ и идентификационная карточка ИИ. Обновляется по
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 и передает результат непосредственно в сборку контекста первого оборота. Однопроходный предварительный прогрев на холодном пире часто возвращает скудный вывод — многопроходная глубина запускает цикл аудита/согласования до того, как пользователь заговорит. Если предварительный прогрев не завершился к первому обороту, первый оборот переключается на синхронный вызов с ограниченным таймаутом.
Адаптивный уровень рассуждения на основе запроса
Автоматически внедряемая диалектика масштабирует dialecticReasoningLevel в зависимости от длины запроса: +1 уровень при ≥120 символах, +2 при ≥400, с ограничением на reasoningLevelCap (по умолчанию "high"). Отключите с помощью reasoningHeuristic: false, чтобы закрепить каждый автоматический вызов на dialecticReasoningLevel. Доступные уровни: minimal, low, medium, high, max.
Параметры конфигурации
Honcho настраивается в ~/.honcho/config.json (глобально) или $VIBEOS_HOME/honcho.json (локально для профиля). Мастер настройки сделает это за вас.
Самостоятельно размещенный Honcho с аутентификацией
При указании VibeOS на самостоятельно размещенный сервер Honcho, vibeos honcho setup (и vibeos memory setup) запрашивают локальный JWT / bearer токен после базового URL. Вставьте JWT, подписанный AUTH_JWT_SECRET сервера (переменная окружения Honcho compose), чтобы включить аутентифицированный доступ; оставьте пустым для серверов, работающих с 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 | {} | Только для шлюза. Карта идентификаторов времени выполнения на пиров ({"7654321": "alice"}). Многие к одному |
runtimePeerPrefix | "" | Только для шлюза. Пространство имен для неизвестных идентификаторов времени выполнения (telegram_7654321), если нет совпадения по псевдониму |
Стратегия сессии управляет тем, как сессии Honcho сопоставляются с вашей работой:
per-session— каждый запускvibeosполучает новую сессию. Чистые старты, память через инструменты. Рекомендуется для новых пользователей.per-directory— одна сессия Honcho на рабочую директорию. Контекст накапливается между запусками.per-repo— одна сессия на git-репозиторий.global— одна сессия для всех директорий.
Режим извлечения управляет тем, как память поступает в разговоры:
hybrid— контекст автоматически внедряется в системный промпт, И инструменты доступны (модель решает, когда запрашивать).context— только автоматическое внедрение, инструменты скрыты.tools— только инструменты, без автоматического внедрения. Агент должен явно вызыватьhoncho_reasoning,honcho_searchи т.д.
Настройки для каждого режима извлечения:
| Настройка | hybrid | context | tools |
|---|---|---|---|
writeFrequency | сбрасывает сообщения | сбрасывает сообщения | сбрасывает сообщения |
contextCadence | управляет обновлением базового контекста | управляет обновлением базового контекста | неактуально — нет внедрения |
dialecticCadence | управляет автоматическими вызовами LLM | управляет автоматическими вызовами LLM | неактуально — модель вызывает явно |
dialecticDepth | многопроходность на вызов | многопроходность на вызов | неактуально — модель вызывает явно |
contextTokens | ограничивает внедрение | ограничивает внедрение | неактуально — нет внедрения |
dialecticDynamic | управляет переопределением модели | Н/Д (нет инструментов) | управляет переопределением модели |
В режиме tools модель полностью контролирует ситуацию — она вызывает honcho_reasoning, когда хочет, с любым выбранным reasoning_level. Настройки каденса и бюджета применяются только к режимам с автоматическим внедрением (hybrid и context).
Сопоставление идентификаторов шлюза
Эти настройки имеют значение только при запуске шлюза VibeOS — единой точки входа, где пользователи приходят с собственными идентификаторами платформы (UID Telegram, снежинка Discord, пользователь Slack). Сессии CLI, TUI и рабочего стола не имеют идентификатора времени выполнения и всегда разрешаются в peerName, поэтому вне шлюза эти ключи ничего не делают.
Мастер настройки определяет, подключена ли платформа шлюза, и полностью пропускает этот шаг, если нет. Когда он запускается, он задает один вопрос — кто разговаривает через этот шлюз? — и выводит ключи:
| Ответ | Результат |
|---|---|
| только я | pinUserPeer: true — каждый пользователь шлюза, не являющийся агентом, сводится к вашему пиру. Привязка переопределяет все псевдонимы, поэтому выбирайте это только тогда, когда ни одному пользовательскому идентификатору не нужен свой собственный пир. Если отдельные агенты достигают шлюза и каждому нужен отдельный пир, не привязывайте — оставьте pinUserPeer: false и сопоставьте их через userPeerAliases (редактор [e]) |
| я + другие люди (объединенные) | pinUserPeer: false + userPeerAliases, сопоставляющие ваши идентификаторы времени выполнения с peerName — вы остаетесь на своей общей истории, другие получают своих собственных пиров |
| только другие люди | pinUserPeer: false, опционально runtimePeerPrefix — каждый пользователь получает своего собственного пира |
Выберите [e] в приглашении, чтобы установить три ключа напрямую.
Резолвер пробует ключи сверху вниз, первое совпадение выигрывает: pinUserPeer → userPeerAliases[id] → runtimePeerPrefix + id → сырой идентификатор времени выполнения → peerName → запасной вариант ключа сессии.
Переключение pinUserPeer с true на false не переносит данные — память, накопленная под peerName, остается там, а пользователи платформы разрешаются в новые, пустые пиры. Чтобы сохранить свою собственную непрерывность, выберите путь объединения, чтобы ваши идентификаторы времени выполнения ссылались обратно на peerName. Мастер автоматически предлагает это, когда обнаруживает переход.
pinPeerName — это устаревший псевдоним для pinUserPeer — все еще читается для обратной совместимости (pinUserPeer выигрывает, если установлены оба), никогда не записывается. Повторный запуск настройки переносит его на канонический ключ.
Наблюдение (направленное vs. единое)
Honcho моделирует разговор как обмен сообщениями между пирами. У каждого пира есть два переключателя наблюдения, которые сопоставляются 1:1 с SessionPeerConfig Honcho:
| Переключатель | Эффект |
|---|---|
observeMe | Honcho строит представление этого пира на основе его собственных сообщений |
observeOthers | Этот пир наблюдает за сообщениями другого пира (питает перекрестное рассуждение) |
Два пира × два переключателя = четыре флага. observationMode — это сокращенный пресет:
| Пресет | Флаги пользователя | Флаги ИИ | Семантика |
|---|---|---|---|
"directional" (по умолчанию) | я: вкл, другие: вкл | я: вкл, другие: вкл | Полное взаимное наблюдение. Включает перекрестную диалектику пиров — «что ИИ знает о пользователе, основываясь на том, что пользователь сказал и что ИИ ответил». |
"unified" | я: вкл, другие: выкл | я: выкл, другие: вкл | Семантика общего пула — ИИ наблюдает только за сообщениями пользователя, пир пользователя моделирует только себя. Пул с одним наблюдателем. |
Переопределите пресет с помощью явного блока observation для контроля над каждым пиром:
"observation": {
"user": { "observeMe": true, "observeOthers": true },
"ai": { "observeMe": true, "observeOthers": false }
}
Распространенные паттерны:
| Намерение | Конфигурация |
|---|---|
| Полное наблюдение (большинство пользователей) | "observationMode": "directional" |
| ИИ не должен перемоделировать пользователя на основе своих собственных ответов | "ai": {"observeMe": true, "observeOthers": false} |
| Сильная персона, которую пир ИИ не должен обновлять из самонаблюдения | "ai": {"observeMe": false, "observeOthers": true} |
Переключатели на стороне сервера, установленные через панель управления Honcho, имеют приоритет над локальными значениями по умолчанию — VibeOS синхронизирует их обратно при инициализации сессии.
Инструменты
Когда Honcho активен в качестве провайдера памяти, становятся доступны пять инструментов:
| Инструмент | Назначение |
|---|---|
honcho_profile | Чтение или обновление карточки пира — передайте card (список фактов) для обновления, опустите для чтения |
honcho_search | Семантический поиск по контексту — сырые выдержки, без синтеза LLM |
honcho_context | Полный контекст сессии — сводка, представление, карточка, последние сообщения |
honcho_reasoning | Синтезированный ответ от LLM Honcho — передайте reasoning_level (minimal/low/medium/high/max) для контроля глубины |
honcho_conclude | Создание или удаление выводов — передайте conclusion для создания, delete_id для удаления (только PII) |
Команды CLI
Подкоманда vibeos honcho регистрируется только тогда, когда Honcho является активным провайдером памяти (memory.provider: honcho в config.yaml). При новой установке настройте Honcho напрямую с помощью vibeos memory setup honcho (или запустите vibeos memory setup и выберите его из списка); подкоманда vibeos honcho появится при следующем вызове.
vibeos memory setup honcho # Настройка Honcho напрямую (работает до активации)
vibeos honcho status # Статус подключения, конфигурация и ключевые настройки
vibeos honcho setup # Перенаправляет на `vibeos memory setup` (псевдоним после активации)
vibeos honcho strategy # Показать или установить стратегию сессии (per-session/per-directory/per-repo/global)
vibeos honcho peer # Показать или обновить имена пиров + уровень диалектического рассуждения
vibeos honcho mode # Показать или установить режим извлечения (hybrid/context/tools)
vibeos honcho tokens # Показать или установить бюджет токенов для контекста и диалектики
vibeos honcho identity # Заполнить или показать идентичность пира ИИ в Honcho
vibeos honcho sync # Синхронизировать конфигурацию Honcho со всеми существующими профилями
vibeos honcho peers # Показать идентичности пиров во всех профилях
vibeos honcho sessions # Список известных сопоставлений сессий Honcho
vibeos honcho map # Сопоставить текущую директорию с именем сессии Honcho
vibeos honcho enable # Включить Honcho для активного профиля
vibeos honcho disable # Отключить Honcho для активного профиля
vibeos honcho migrate # Пошаговое руководство по миграции с openclaw-honcho
Миграция с vibeos honcho
Если вы ранее использовали отдельный vibeos honcho setup:
- Ваша существующая конфигурация (
honcho.jsonили~/.honcho/config.json) сохраняется - Ваши данные на стороне сервера (воспоминания, выводы, профили пользователей) остаются нетронутыми
- Установите
memory.provider: honchoв config.yaml для реактивации
Повторный вход или повторная настройка не требуются. Запустите vibeos memory setup и выберите «honcho» — мастер обнаружит вашу существующую конфигурацию.
Полная документация
См. Провайдеры памяти — Honcho для полной справки.