Перейти к основному содержимому

Провайдеры памяти

VibeOS поставляется с 8 плагинами внешних провайдеров памяти, которые дают агенту постоянные, межсессионные знания, выходящие за рамки встроенных MEMORY.md и USER.md. Одновременно может быть активен только один внешний провайдер — встроенная память всегда активна параллельно с ним.

Быстрый старт​

vibeos memory setup      # интерактивный выбор + настройка
vibeos memory status # проверить, что активно
vibeos memory off # отключить внешнего провайдера

Вы также можете выбрать активного провайдера памяти через vibeos plugins → Provider Plugins → Memory Provider.

Или задать вручную в ~/.vibeos/config.yaml:

memory:
provider: openviking # или honcho, mem0, hindsight, holographic, retaindb, byterover, supermemory

Как это работает​

Когда провайдер памяти активен, VibeOS автоматически:

  1. Внедряет контекст провайдера в системный промпт (то, что знает провайдер)
  2. Предварительно извлекает релевантные воспоминания перед каждым шагом (в фоне, неблокирующе)
  3. Синхронизирует шаги разговора с провайдером после каждого ответа
  4. Извлекает воспоминания при завершении сессии (для провайдеров, которые это поддерживают)
  5. Зеркалирует записи встроенной памяти во внешнего провайдера
  6. Добавляет инструменты, специфичные для провайдера, чтобы агент мог искать, хранить и управлять воспоминаниями

Встроенная память (MEMORY.md / USER.md) продолжает работать как и прежде. Внешний провайдер является дополнением.

Доступные провайдеры​

Honcho​

AI-нативное межсессионное моделирование пользователя с диалектическим рассуждением, внедрением контекста в рамках сессии, семантическим поиском и постоянными выводами. Базовый контекст теперь включает сводку сессии наряду с представлением пользователя и карточками пиров, давая агенту осведомлённость о том, что уже обсуждалось.

Лучше всего дляМногоагентных систем с межсессионным контекстом, согласованием пользователь-агент
Требуетpip install honcho-ai + API-ключ или собственный экземпляр
Хранение данныхHoncho Cloud или собственный сервер
СтоимостьЦены Honcho (облако) / бесплатно (собственный сервер)

Инструменты (5): honcho_profile (чтение/обновление карточки пира), honcho_search (семантический поиск), honcho_context (контекст сессии — сводка, представление, карточка, сообщения), honcho_reasoning (синтезированный LLM), honcho_conclude (создание/удаление выводов)

Архитектура: Двухуровневое внедрение контекста — базовый слой (сводка сессии + представление + карточка пира, обновляется с частотой contextCadence) плюс диалектическое дополнение (рассуждение LLM, обновляется с частотой dialecticCadence). Диалектика автоматически выбирает между холодными промптами (общие факты о пользователе) и тёплыми промптами (контекст в рамках сессии) на основе наличия базового контекста.

Три ортогональных параметра конфигурации независимо контролируют стоимость и глубину:

  • contextCadence — как часто обновляется базовый слой (частота вызовов API)
  • dialecticCadence — как часто срабатывает диалектический LLM (частота вызовов LLM)
  • dialecticDepth — сколько проходов .chat() на один вызов диалектики (1–3, глубина рассуждения)

Автоматически внедряемая диалектика также масштабирует уровень рассуждения в зависимости от длины запроса (чем длиннее запрос, тем глубже рассуждение, ограничено reasoningLevelCap); см. Query-Adaptive Reasoning Level.

Мастер настройки:

vibeos memory setup        # выберите «honcho» — запускает пост-настройку, специфичную для Honcho

Устаревшая команда vibeos honcho setup всё ещё работает (теперь она перенаправляет на vibeos memory setup), но регистрируется только после выбора Honcho в качестве активного провайдера памяти.

Конфиг: $VIBEOS_HOME/honcho.json (локальный для профиля) или ~/.honcho/config.json (глобальный). Порядок разрешения: $VIBEOS_HOME/honcho.json > ~/.vibeos/honcho.json > ~/.honcho/config.json. См. справочник по конфигурации и руководство по интеграции Honcho.

Полный справочник по конфигурации
КлючПо умолчаниюОписание
apiKey--API-ключ из app.honcho.dev
baseUrl--Базовый URL для собственного сервера Honcho
peerName--Идентичность пользовательского пира
aiPeerключ хостаИдентичность AI-пира (один на профиль)
workspaceключ хостаID общего рабочего пространства
contextTokensnull (без ограничения)Бюджет токенов для автоматически внедряемого контекста на шаг. Обрезается по границам слов
contextCadence1Минимальное количество шагов между вызовами API context() (обновление базового слоя)
dialecticCadence2Минимальное количество шагов между вызовами LLM peer.chat(). Рекомендуется 1–5. Применяется только в режимах hybrid/context
dialecticDepth1Количество проходов .chat() на один вызов диалектики. Ограничено 1–3. Проход 0: холодный/тёплый промпт, проход 1: самоаудит, проход 2: согласование
dialecticDepthLevelsnullОпциональный массив уровней рассуждения на проход, например ["minimal", "low", "medium"]. Переопределяет пропорциональные значения по умолчанию
dialecticReasoningLevel'low'Базовый уровень рассуждения: minimal, low, medium, high, max
dialecticDynamictrueЕсли true, модель может переопределять уровень рассуждения при каждом вызове через параметр инструмента
dialecticMaxChars600Максимальное количество символов результата диалектики, внедряемого в системный промпт
recallMode'hybrid'hybrid (автовнедрение + инструменты), context (только внедрение), tools (только инструменты)
writeFrequency'async'Когда сбрасывать сообщения: async (фоновый поток), turn (синхронно), session (пакетно при завершении) или целое число N
saveMessagestrueСохранять ли сообщения в API Honcho
observationMode'directional'directional (все включены) или unified (общий пул). Переопределяется объектом observation
messageMaxChars25000Максимальное количество символов на сообщение (разбивается на части при превышении)
dialecticMaxInputChars10000Максимальное количество символов для ввода запроса диалектики в peer.chat()
sessionStrategy'per-directory'per-directory, per-repo, per-session, global
pinUserPeerfalseТолько для шлюза. Если true, каждый пользователь шлюза, не являющийся агентом, сводится к peerName; привязка переопределяет все псевдонимы
userPeerAliases{}Только для шлюза. Сопоставляет идентификаторы времени выполнения с пирами ({"7654321": "alice"}). Многие к одному
runtimePeerPrefix""Только для шлюза. Пространство имён для неизвестных идентификаторов времени выполнения (telegram_7654321), когда нет совпадения по псевдониму
Минимальный honcho.json (облако)
{
"apiKey": "ваш-ключ-из-app.honcho.dev",
"hosts": {
"vibeos": {
"enabled": true,
"aiPeer": "vibeos",
"peerName": "ваше-имя",
"workspace": "vibeos"
}
}
}
Минимальный honcho.json (собственный сервер)
{
"baseUrl": "http://localhost:8000",
"hosts": {
"vibeos": {
"enabled": true,
"aiPeer": "vibeos",
"peerName": "ваше-имя",
"workspace": "vibeos"
}
}
}
Миграция с vibeos honcho

Если вы ранее использовали vibeos honcho setup, ваша конфигурация и все данные на стороне сервера остались нетронутыми. Просто повторно включите через мастер настройки или вручную установите memory.provider: honcho, чтобы реактивировать через новую систему.

Настройка нескольких пиров:

Honcho моделирует разговоры как пиров, обменивающихся сообщениями — один пользовательский пир плюс один AI-пир на профиль VibeOS, все в одном рабочем пространстве. Рабочее пространство — это общая среда: пользовательский пир глобален для всех профилей, каждый AI-пир имеет свою собственную идентичность. Каждый AI-пир строит независимое представление/карточку на основе своих собственных наблюдений, поэтому профиль coder остаётся ориентированным на код, а профиль writer — на редактирование, работая с одним и тем же пользователем.

Сопоставление:

КонцепцияЧто это
WorkspaceОбщая среда. Все профили VibeOS в одном рабочем пространстве видят одну и ту же идентичность пользователя.
User peer (peerName)Человек. Общий для всех профилей в рабочем пространстве.
AI peer (aiPeer)Один на профиль VibeOS. Ключ хоста vibeos → по умолчанию; vibeos.<profile>` для других.
ObservationПереключатели для каждого пира, контролирующие, что Honcho моделирует из чьих сообщений. directional (по умолчанию, все четыре включены) или unified (единый пул наблюдателей).

Новый профиль, свежий пир Honcho​

vibeos profile create coder --clone

--clone создаёт блок хоста vibeos.coder в honcho.json с aiPeer: "coder", общим workspace, унаследованным peerName, recallMode, writeFrequency, observation и т.д. AI-пир создаётся в Honcho заранее, чтобы он существовал до первого сообщения.

Существующие профили, обратное заполнение пиров Honcho​

vibeos honcho sync

Сканирует каждый профиль VibeOS, создаёт блоки хостов для профилей без них, наследует настройки из блока vibeos по умолчанию и создаёт новые AI-пиры заранее. Идемпотентно — пропускает профили, у которых уже есть блок хоста.

Наблюдение для каждого профиля​

Каждый блок хоста может независимо переопределять конфигурацию наблюдения. Пример: профиль, ориентированный на код, где AI-пир наблюдает за пользователем, но не моделирует себя:

"vibeos.coder": {
"aiPeer": "coder",
"observation": {
"user": { "observeMe": true, "observeOthers": true },
"ai": { "observeMe": false, "observeOthers": true }
}
}

Переключатели наблюдения (один набор на пира):

ПереключательЭффект
observeMeHoncho строит представление этого пира на основе его собственных сообщений
observeOthersЭтот пир наблюдает сообщения другого пира (питает межпировое рассуждение)

Предустановки через observationMode:

  • "directional" (по умолчанию) — все четыре флага включены. Полное взаимное наблюдение; включает межпировую диалектику.
  • "unified" — пользователь observeMe: true, AI observeOthers: true, остальные false. Единый пул наблюдателей; AI моделирует пользователя, но не себя, пользовательский пир только самомоделируется.

Серверные переключатели, установленные через панель управления Honcho, имеют приоритет над локальными значениями по умолчанию — синхронизируются обратно при инициализации сессии.

См. страницу Honcho для полного справочника по наблюдению.

Сопоставление идентичностей в шлюзе​

Модель пиров выше охватывает сессии CLI, TUI и рабочего стола, где каждый разговор сводится к peerName. Шлюз добавляет вторую ось: пользователи приходят с нативными идентификаторами времени выполнения платформы (Telegram UID, Discord snowflake, пользователь Slack), и три ключа определяют, к какому пиру разрешается каждый ID.

КлючЭффект
pinUserPeer: trueКаждый пользователь шлюза, не являющийся агентом, сводится к peerName. Привязка проверяется первой, поэтому она переопределяет все псевдонимы — выбирайте её только тогда, когда ни одна идентичность на стороне пользователя не требует собственного пира
userPeerAliasesСопоставляет конкретные идентификаторы времени выполнения с пирами ({"7654321": "alice"}). Место для маршрутизации различных идентичностей — включая агентов, каждый из которых имеет своего собственного пира
runtimePeerPrefixПространство имён для любого несопоставленного идентификатора времени выполнения (telegram_7654321), чтобы платформы с одинаковыми ID не конфликтовали

Вне шлюза эти ключи ничего не делают. vibeos memory setup запрашивает их только при обнаружении подключённой платформы шлюза. См. страницу Honcho для лестницы разрешения и процесса настройки.

Полный пример honcho.json (несколько профилей)
{
"apiKey": "ваш-ключ",
"workspace": "vibeos",
"peerName": "eri",
"hosts": {
"vibeos": {
"enabled": true,
"aiPeer": "vibeos",
"workspace": "vibeos",
"peerName": "eri",
"recallMode": "hybrid",
"writeFrequency": "async",
"sessionStrategy": "per-directory",
"observation": {
"user": { "observeMe": true, "observeOthers": true },
"ai": { "observeMe": true, "observeOthers": true }
},
"dialecticReasoningLevel": "low",
"dialecticDynamic": true,
"dialecticCadence": 2,
"dialecticDepth": 1,
"dialecticMaxChars": 600,
"contextCadence": 1,
"messageMaxChars": 25000,
"saveMessages": true
},
"vibeos.coder": {
"enabled": true,
"aiPeer": "coder",
"workspace": "vibeos",
"peerName": "eri",
"recallMode": "tools",
"observation": {
"user": { "observeMe": true, "observeOthers": false },
"ai": { "observeMe": true, "observeOthers": true }
}
},
"vibeos.writer": {
"enabled": true,
"aiPeer": "writer",
"workspace": "vibeos",
"peerName": "eri"
}
},
"sessions": {
"/home/user/myproject": "myproject-main"
}
}

См. справочник по конфигурации и руководство по интеграции Honcho.


OpenViking​

Контекстная база данных от Volcengine (ByteDance) с иерархией знаний в стиле файловой системы, многоуровневым поиском и автоматическим извлечением памяти в 6 категорий.

Лучше всего дляСамостоятельного управления знаниями со структурированным просмотром
Требуетpip install openviking + работающий сервер
Хранение данныхСобственный сервер (локальный или облачный)
СтоимостьБесплатно (открытый исходный код, AGPL-3.0)

Инструменты: viking_search (семантический поиск), viking_read (многоуровневый: абстракт/обзор/полный), viking_browse (навигация по файловой системе), viking_remember (сохранение фактов), viking_add_resource (загрузка URL/документов)

Настройка:

# Сначала запустите сервер OpenViking
pip install openviking
openviking-server

# Затем настройте VibeOS
vibeos memory setup # выберите «openviking»
# Или вручную:
vibeos config set memory.provider openviking
echo "OPENVIKING_ENDPOINT=http://localhost:1933" >> ~/.vibeos/.env
# Для аутентифицированных серверов используйте ключ API пользователя/администратора:
echo "OPENVIKING_API_KEY=..." >> ~/.vibeos/.env

Ключевые особенности:

  • Многоуровневая загрузка контекста: L0 (~100 токенов) → L1 (~2k) → L2 (полный)
  • Автоматическое извлечение памяти при завершении сессии (профиль, предпочтения, сущности, события, случаи, шаблоны)
  • Схема URI viking:// для иерархического просмотра знаний

OPENVIKING_ACCOUNT и OPENVIKING_USER используются для локального/доверенного режима. OPENVIKING_AGENT — это ID пира VibeOS в OpenViking для памяти, ограниченной пиром.


Mem0​

Серверное извлечение фактов LLM с семантическим поиском, переранжированием и автоматическим удалением дубликатов. Поддерживает как Mem0 Platform (облако), так и OSS (собственный сервер) режимы.

Лучше всего дляАвтоматического управления памятью — Mem0 обрабатывает извлечение автоматически
Требуетpip install mem0ai + API-ключ (платформа) или LLM/векторное хранилище (OSS)
Хранение данныхMem0 Cloud (платформа) или собственный сервер (OSS)
СтоимостьЦены Mem0 (платформа) / бесплатно (OSS)

Инструменты (5): mem0_list (список всех воспоминаний, с пагинацией), mem0_search (семантический поиск с переранжированием в режиме платформы), mem0_add (сохранение дословных фактов), mem0_update (обновление по ID), mem0_delete (удаление по ID)

Настройка (Платформа):

vibeos memory setup    # выберите «mem0» → «Platform»
# Или вручную:
vibeos config set memory.provider mem0
echo "MEM0_API_KEY=ваш-ключ" >> ~/.vibeos/.env

Настройка (OSS):

vibeos memory setup    # выберите «mem0» → «Open Source (self-hosted)»
# Или через флаги:
vibeos memory setup mem0 --mode oss --oss-llm openai --oss-llm-key sk-... --oss-vector qdrant

Предварительный просмотр без записи файлов:

vibeos memory setup mem0 --mode oss --oss-llm-key sk-... --dry-run

Конфиг: $VIBEOS_HOME/mem0.json (поведенческие настройки). Только секретный MEM0_API_KEY находится в ~/.vibeos/.env.

КлючПо умолчаниюОписание
modeplatformplatform (Mem0 Cloud) или oss (собственный сервер)
user_idvibeos-userИдентификатор пользователя
agent_idvibeosИдентификатор агента
reranktrueПереранжировать результаты поиска для релевантности (только режим платформы)

Поддерживаемые провайдеры OSS:

КомпонентПровайдеры
LLMopenai, ollama
Эмбеддерopenai, ollama
Векторное хранилищеqdrant (локальный/сервер), pgvector

Переключение режимов: Повторно запустите vibeos memory setup mem0 --mode &lt;platform|oss&gt; или отредактируйте mem0.json` напрямую.


Hindsight​

Долговременная память с графом знаний, разрешением сущностей и многостратегическим поиском. Инструмент hindsight_reflect обеспечивает межмемориальный синтез, который не предлагает ни один другой провайдер. Автоматически сохраняет полные шаги разговора (включая вызовы инструментов) с отслеживанием документов на уровне сессии.

Лучше всего дляПоиска на основе графа знаний с отношениями сущностей
ТребуетОблако: API-ключ из ui.hindsight.vectorize.io. Локально: API-ключ LLM (OpenAI, Groq, OpenRouter и т.д.)
Хранение данныхHindsight Cloud или локальный встроенный PostgreSQL
СтоимостьЦены Hindsight (облако) или бесплатно (локально)

Инструменты: hindsight_retain (сохранение с извлечением сущностей), hindsight_recall (многостратегический поиск), hindsight_reflect (межмемориальный синтез)

Настройка:

vibeos memory setup    # выберите «hindsight»
# Или вручную:
vibeos config set memory.provider hindsight
echo "HINDSIGHT_API_KEY=ваш-ключ" >> ~/.vibeos/.env

Мастер настройки автоматически устанавливает зависимости и устанавливает только то, что необходимо для выбранного режима (hindsight-client для облака, hindsight-all для локального). Требуется hindsight-client >= 0.4.22 (автоматически обновляется при запуске сессии, если версия устарела).

Локальный режим UI: hindsight-embed -p vibeos ui start

Конфиг: $VIBEOS_HOME/hindsight/config.json

КлючПо умолчаниюОписание
modecloudcloud или local
bank_idvibeosИдентификатор банка памяти
recall_budgetmidТщательность поиска: low / mid / high
memory_modehybridhybrid (контекст + инструменты), context (только автовнедрение), tools (только инструменты)
auto_retaintrueАвтоматически сохранять шаги разговора
auto_recalltrueАвтоматически извлекать воспоминания перед каждым шагом
retain_asynctrueОбрабатывать сохранение асинхронно на сервере
retain_contextconversation between VibeOS and the UserМетка контекста для сохранённых воспоминаний
retain_tags—Теги по умолчанию, применяемые к сохранённым воспоминаниям; объединяются с тегами инструментов при каждом вызове
retain_source—Опциональный metadata.source, прикрепляемый к сохранённым воспоминаниям
retain_user_prefixUserМетка перед шагами пользователя в автоматически сохранённых транскриптах
retain_assistant_prefixAssistantМетка перед шагами ассистента в автоматически сохранённых транскриптах
recall_tags—Теги для фильтрации при поиске

См. README плагина для полного справочника по конфигурации.


Holographic​

Локальное хранилище фактов SQLite с полнотекстовым поиском FTS5, оценкой доверия и HRR (Holographic Reduced Representations) для композиционных алгебраических запросов.

Лучше всего дляЛокальной памяти с расширенным поиском, без внешних зависимостей
ТребуетНичего (SQLite всегда доступен). NumPy опционально для алгебры HRR.
Хранение данныхЛокальный SQLite
СтоимостьБесплатно

Инструменты: fact_store (9 действий: добавить, искать, проверить, связанное, причина, противоречие, обновить, удалить, список), fact_feedback (оценка полезно/бесполезно, которая обучает оценки доверия)

Настройка:

vibeos memory setup    # выберите «holographic»
# Или вручную:
vibeos config set memory.provider holographic

Конфиг: config.yaml в разделе plugins.vibeos-memory-store

КлючПо умолчаниюОписание
db_path$VIBEOS_HOME/memory_store.dbПуть к базе данных SQLite
auto_extractfalseАвтоматически извлекать факты при завершении сессии
default_trust0.5Оценка доверия по умолчанию (0.0–1.0)

Уникальные возможности:

  • probe — алгебраический поиск, специфичный для сущности (все факты о человеке/вещи)
  • reason — композиционные запросы AND для нескольких сущностей
  • contradict — автоматическое обнаружение конфликтующих фактов
  • Оценка доверия с асимметричной обратной связью (+0.05 полезно / -0.10 бесполезно)

RetainDB​

Облачный API памяти с гибридным поиском (Vector + BM25 + Reranking), 7 типами памяти и дельта-сжатием.

Лучше всего дляКоманд, уже использующих инфраструктуру RetainDB
ТребуетУчётная запись RetainDB + API-ключ
Хранение данныхRetainDB Cloud
Стоимость$20/месяц

Инструменты: retaindb_profile (профиль пользователя), retaindb_search (семантический поиск), retaindb_context (контекст, релевантный задаче), retaindb_remember (сохранение с типом + важностью), retaindb_forget (удаление воспоминаний)

Настройка:

vibeos memory setup    # выберите «retaindb»
# Или вручную:
vibeos config set memory.provider retaindb
echo "RETAINDB_API_KEY=ваш-ключ" >> ~/.vibeos/.env

ByteRover​

Постоянная память через CLI brv — иерархическое дерево знаний с многоуровневым поиском (нечёткий текст → поиск на основе LLM). Локально-ориентированный с опциональной облачной синхронизацией.

Лучше всего дляРазработчиков, которым нужна портативная, локально-ориентированная память с CLI
ТребуетByteRover CLI (npm install -g byterover-cli или скрипт установки)
Хранение данныхЛокально (по умолчанию) или ByteRover Cloud (опциональная синхронизация)
СтоимостьБесплатно (локально) или цены ByteRover (облако)

Инструменты: brv_query (поиск в дереве знаний), brv_curate (сохранение фактов/решений/шаблонов), brv_status (версия CLI + статистика дерева)

Настройка:

# Сначала установите CLI
curl -fsSL https://byterover.dev/install.sh | sh

# Затем настройте VibeOS
vibeos memory setup # выберите «byterover»
# Или вручную:
vibeos config set memory.provider byterover

Ключевые особенности:

  • Автоматическое извлечение перед сжатием (сохраняет инсайты до того, как сжатие контекста их отбросит)
  • Дерево знаний хранится в $VIBEOS_HOME/byterover/ (в рамках профиля)
  • Облачная синхронизация с сертификацией SOC2 Type II (опционально)

Supermemory​

Семантическая долговременная память с поиском по профилю, семантическим поиском, явными инструментами памяти и загрузкой разговора при завершении сессии через API графа Supermemory.

Лучше всего дляСемантического поиска с профилированием пользователя и построением графа на уровне сессии
Требуетpip install supermemory + API-ключ
Хранение данныхSupermemory Cloud
СтоимостьЦены Supermemory

Инструменты: supermemory_store (сохранение явных воспоминаний), supermemory_search (поиск по семантическому сходству), supermemory_forget (забыть по ID или запросу наилучшего совпадения), supermemory_profile (постоянный профиль + недавний контекст)

Настройка:

vibeos memory setup    # выберите «supermemory»
# Или вручную:
vibeos config