Постоянная память

У VibeOS ограниченная curated-память между сессиями: предпочтения, проекты, окружение и то, чему агент научился.

Короткий гид «для людей» (ритуал знакомства, portrait, инкогнито, forget, FAQ): Память и знакомство.

User Familiarity также покрывает Machine Portrait (opt-in коллекторы), проактивный episodic prefetch и режим сессии (full / read_only / off / incognito).

Уровни Memory OS (терминология)

Одни и те же пять имён везде — в docs, роли Fleet Archivist, skills и настройках:

Уровень	Простыми словами	Где хранится	В промпте модели?
Core	Краткие «рабочие заметки» агента	~/.vibeos/memories/MEMORY.md	Да — фиксируется в начале сессии
User	Как вы любите работать	~/.vibeos/memories/USER.md	Да — фиксируется в начале сессии
Episodic	Дневник прошлых чатов («что мы делали»)	База данных сессий	Нет — поиск при необходимости
Archival	Долгосрочные факты, не помещающиеся в Core	Активный провайдер памяти (+ локальный индекс)	Нет — поиск при необходимости
Board	Общая папка проекта для команды Kanban	kanban/boards/<slug>/kb/ (в рамках доски)	Нет — команда читает через инструменты доски/CLI

Если что-то «не помещается»: не просите убрать лимиты Core/User. Переносите в Archival (личные долговременные факты) или Board (общие знания проекта). Профили остаются изолированными; База знаний доски — единственный намеренный обмен между профилями на одной доске.

Core + User — это то, что большинство людей подразумевают под «памятью» в повседневном использовании. Остальная часть этой страницы описывает эти два хранилища, внедряемые в промпт; Episodic / Archival / Board — это слои для переполнения и командной работы (Memory OS, фаза 2+).

CLI для дневника Episodic

Просматривайте или ищите прошлые чаты (уровень Episodic — не внедряется в промпт):

vibeos memory episodes                     # последние сессии
vibeos memory episodes "Telegram" --since 7d
vibeos memory episodes deploy --project ~/code/api --json

--since принимает ISO-даты или относительные окна (7d, 2w, 24h). Агенты также могут использовать инструмент session_search / навык episodic-diary.

Archival (внешний провайдер)

Выберите провайдера в три строки (также отображается в Настройках рабочего стола → Память):

1. Нет / встроенный — только файлы Core + User; достаточно для большинства.
2. Mem0 — простое облачное «запомни это / найди позже».
3. Honcho — более богатое моделирование пользователя в нескольких сессиях.
4. Hindsight — структурированное сохранение/воспроизведение, когда нужны более мощные архивные инструменты.

Когда memory.provider установлен, используйте один язык для долгосрочных фактов (не расширяет лимиты Core):

vibeos memory archival matrix                 # провайдер → карта нативных инструментов
vibeos memory archival insert "долговременный факт…"
vibeos memory archival search "предпочтения" --limit 5

Навык: archival-recall. Матрица пробелов: docs/plans/memory-archival-gap-matrix.md.

Консолидация Core (очистка Архивариусом)

Когда MEMORY.md / USER.md接近 лимита, планируйте перенос в Archival (по умолчанию пробный прогон — ничего не удаляется, пока вы не согласитесь):

vibeos memory consolidate                  # пробный план для MEMORY.md
vibeos memory consolidate --target all --json
vibeos memory consolidate --apply --yes    # требует memory.provider

--apply без --yes будет отклонен. Без внешнего Archival-провайдера apply отклоняется, чтобы Core никогда не очищался молча.

Делегирование → Archival (только родитель)

Когда дочерняя задача delegate_task завершается, родитель может извлечь краткие выводы из сводки и:

1. Вставить их в Archival (если установлен memory.provider), и
2. Добавить кандидатов на проверку в ~/.vibeos/memories/proposed_core.jsonl

Листовые/субагенты по-прежнему не могут использовать инструмент memory. Отключите с помощью memory.delegation_promote: false в config.yaml.

Режим памяти для Cron

Запланированные задания всегда выполняются с пропущенными Core/User в середине оборота (skip_memory=True). Включите после успешного выполнения:

Режим	Поведение
off (по умолчанию)	Нет записи в память
archival	Извлечение фактов → Archival (если провайдер установлен)
promote	Archival + proposed_core.jsonl (все еще нет автоматического MEMORY.md)

vibeos cron create --schedule "every 1d" --memory-mode promote \
  --prompt "Обобщи долговременные продуктовые решения за последний день."
vibeos cron edit <job_id> --memory-mode off

Роль Архивариуса (Флот)

В Fleet Control портрет Архивариуса — это специалист по памяти: гигиена Core/User, поиск в Archival, выводы из Базы знаний доски и проверка proposed_core.jsonl — а не вторая поверхность для чата. Портреты поставляются в apps/desktop/public/agent-roster/ (мастер-планы в docs/plans/assets/agent-roster/).

Офлайн-экзамен для золотых задач Memory OS G5–G8:

scripts/smoke-memory-os.sh
# или: python skills/memory/scripts/eval_memory_os.py --all

База знаний доски

Общие выводы для одной Kanban-доски (все профили на этой доске). Хранится в kanban/boards/<slug>/kb/findings.jsonl — никогда не пересекает границы досок:

vibeos kanban kb add --task T1 --confidence 0.85 "Цена конкурента — $12/мес"
vibeos kanban kb list
vibeos kanban kb search pricing
vibeos kanban --board alpha kb path

Каждая запись хранит task_id, confidence (0–1), временную метку, автора и тело. Навык: board-knowledge.

Браузер памяти (Рабочий стол)

В Настройки → Память и контекст браузер памяти показывает записи Core (MEMORY.md) и User (USER.md) с процентом заполнения символов. Вы можете редактировать или удалять записи там. Изменения немедленно записываются на диск, но промпт модели обновляется при следующей сессии, чтобы кеш промпта оставался нетронутым.

Области действия (явные — без скрытого слияния):

Метка	Значение
Profile	Core / User / Archival только для активного профиля
Board	Общая База знаний Kanban для одной доски (vibeos kanban kb)
Session-only	Контекст текущего чата — не Core, пока не закреплено/добавлено

Экспорт этого профиля загружает JSON Core/User только для активного профиля. Экспорта «объединить все профили» не существует.

RPC (TUI / шлюз рабочего стола): memory.browser.get / remove / replace / add / search / pin / export.

Здоровье: vibeos memory status

Показывает активного провайдера плюс процент заполнения Core/User и локальные счетчики (add / replace / remove / overflow / batch), хранящиеся в ~/.vibeos/memories/.stats.json. Счетчики никогда не покидают машину — никакой исходящей аналитики.

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

Два файла составляют Core и User память агента:

Файл	Уровень	Назначение	Лимит символов
MEMORY.md	Core	Личные заметки агента — факты окружения, соглашения, изученное	2 200 символов (~800 токенов)
USER.md	User	Профиль пользователя — ваши предпочтения, стиль общения, ожидания	1 375 символов (~500 токенов)

Для локальных CLI/Desktop оба файла хранятся в ~/.vibeos/memories/. В шлюзе обмена сообщениями MEMORY.md остаётся знаниями профиля/проекта, а USER.md хранится в отдельном непрозрачном каталоге каждого пользователя, поэтому предпочтения одного человека не попадают в промпт другого. Оба внедряются в системный промпт как замороженный снимок в начале сессии. Агент управляет своей памятью через инструмент memory — он может добавлять, заменять или удалять записи.

к сведению

Лимиты символов сохраняют память сфокусированной. Память не сжимается автоматически: когда запись превышает лимит, инструмент memory возвращает ошибку вместо того, чтобы молча отбрасывать записи. Затем агент освобождает место сам — объединяя или удаляя записи в том же обороте перед повторной попыткой (см. Что происходит, когда память заполнена). Обратите внимание, что replace также ограничен лимитом: замена записи на более длинную все еще может вызвать переполнение, поэтому новое содержимое должно быть сокращено (или удалена другая запись), чтобы поместиться.

Как память отображается в системном промпте

В начале каждой сессии записи памяти загружаются с диска и отображаются в системном промпте как замороженный блок:

══════════════════════════════════════════════
ПАМЯТЬ (ваши личные заметки) [67% — 1 474/2 200 символов]
══════════════════════════════════════════════
Проект пользователя — Rust веб-сервис в ~/code/myapi с использованием Axum + SQLx
§
На этой машине установлена Ubuntu 22.04, есть Docker и Podman
§
Пользователь предпочитает краткие ответы, не любит подробные объяснения

Формат включает:

• Заголовок, показывающий, какое хранилище (MEMORY или USER PROFILE)
• Процент использования и количество символов, чтобы агент знал о емкости
• Отдельные записи, разделенные разделителем § (знак параграфа)
• Записи могут быть многострочными

Шаблон замороженного снимка: Внедрение системного промпта захватывается один раз в начале сессии и никогда не изменяется в середине сессии. Это сделано намеренно — это сохраняет кеш префикса LLM для производительности. Когда агент добавляет/удаляет записи памяти во время сессии, изменения немедленно сохраняются на диск, но не появятся в системном промпте до начала следующей сессии. Ответы инструментов всегда показывают текущее состояние.

Действия инструмента памяти

Агент использует инструмент memory со следующими действиями:

• add — Добавить новую запись памяти
• replace — Заменить существующую запись обновленным содержимым (использует поиск подстроки через old_text)
• remove — Удалить запись, которая больше не актуальна (использует поиск подстроки через old_text)

Действия read нет — содержимое памяти автоматически внедряется в системный промпт в начале сессии. Агент видит свои воспоминания как часть контекста разговора.

Поиск подстроки

Действия replace и remove используют короткий уникальный поиск подстроки — вам не нужен полный текст записи. Параметр old_text должен быть уникальной подстрокой, которая идентифицирует ровно одну запись:

# Если память содержит "User prefers dark mode in all editors"
memory(action="replace", target="memory",
       old_text="dark mode",
       content="User prefers light mode in VS Code, dark mode in terminal")

Если подстрока соответствует нескольким записям, возвращается ошибка с просьбой указать более конкретное совпадение.

Две цели объяснены

memory — Личные заметки агента

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

• Факты окружения (ОС, инструменты, структура проекта)
• Соглашения и конфигурация проекта
• Особенности инструментов и найденные обходные пути
• Записи дневника выполненных задач
• Навыки и техники, которые сработали

user — Профиль пользователя

Для информации о личности пользователя, предпочтениях и стиле общения:

• Имя, роль, часовой пояс
• Коммуникационные предпочтения (кратко vs подробно, предпочтения по формату)
• Раздражители и чего следует избегать
• Привычки в работе
• Уровень технических навыков

Что сохранять, а что пропускать

Сохраняйте это (проактивно)

Агент сохраняет автоматически — вам не нужно просить. Он сохраняет, когда узнает:

• Предпочтения пользователя: «Я предпочитаю TypeScript, а не JavaScript» → сохранить в user
• Факты окружения: «Этот сервер работает на Debian 12 с PostgreSQL 16» → сохранить в memory
• Исправления: «Не используй sudo для команд Docker, пользователь в группе docker» → сохранить в memory
• Соглашения: «Проект использует табуляцию, ширину строки 120 символов, докстринги в стиле Google» → сохранить в memory
• Выполненная работа: «Мигрировал базу данных с MySQL на PostgreSQL 2026-01-15» → сохранить в memory
• Явные запросы: «Запомни, что ротация моего API-ключа происходит ежемесячно» → сохранить в memory

Пропускайте это

• Тривиальная/очевидная информация: «Пользователь спросил о Python» — слишком расплывчато, чтобы быть полезным
• Легко перепроверяемые факты: «Python 3.12 поддерживает вложенность f-строк» — можно найти в веб-поиске
• Сырые дампы данных: Большие блоки кода, файлы журналов, таблицы данных — слишком большие для памяти
• Эфемерные данные сессии: Временные пути к файлам, одноразовый контекст отладки
• Информация, уже находящаяся в контекстных файлах: содержимое SOUL.md и AGENTS.md

Управление емкостью

Память имеет строгие лимиты символов, чтобы системные промпты оставались ограниченными:

Хранилище	Лимит	Типичное количество записей
memory	2 200 символов	8-15 записей
user	1 375 символов	5-10 записей

Что происходит, когда память заполнена

Когда вы пытаетесь добавить запись, которая превышает лимит, инструмент возвращает ошибку:

{
  "success": false,
  "error": "Память заполнена на 2 100/2 200 символов. Добавление этой записи (250 символов) превысит лимит. Объедините сейчас: используйте 'replace' для слияния пересекающихся записей в более короткие или 'remove' для устаревших или менее важных записей (см. current_entries ниже), затем повторите добавление — все в этом обороте.",
  "current_entries": ["..."],
  "usage": "2 100/2 200"
}

Затем агент должен:

1. Прочитать текущие записи (показаны в ответе об ошибке)
2. Определить записи, которые можно удалить или объединить
3. Использовать replace для слияния связанных записей в более короткие версии
4. Затем add новую запись

Лучшая практика: Когда память заполнена более чем на 80% (видно в заголовке системного промпта), объединяйте записи перед добавлением новых. Например, объедините три отдельные записи «проект использует X» в одно всеобъемлющее описание проекта.

Практические примеры хороших записей памяти

Компактные, информативные записи работают лучше всего:

# Хорошо: Объединяет несколько связанных фактов
Пользователь работает на macOS 14 Sonoma, использует Homebrew, имеет Docker Desktop и Podman. Оболочка: zsh с oh-my-zsh. Редактор: VS Code с привязками клавиш Vim.

# Хорошо: Конкретное, действенное соглашение
Проект ~/code/api использует Go 1.22, sqlc для запросов к БД, chi router. Запуск тестов через 'make test'. CI через GitHub Actions.

# Хорошо: Извлеченный урок с контекстом
Стейдж-сервер (10.0.1.50) требует SSH порт 2222, а не 22. Ключ находится в ~/.ssh/staging_ed25519.

# Плохо: Слишком расплывчато
У пользователя есть проект.

# Плохо: Слишком многословно
5 января 2026 года пользователь попросил меня посмотреть их проект, который
находится в ~/code/api. Я обнаружил, что он использует Go версии 1.22 и...

Предотвращение дубликатов

Система памяти автоматически отклоняет точные дубликаты записей. Если вы попытаетесь добавить содержимое, которое уже существует, она возвращает успех с сообщением «дубликат не добавлен».

Сканирование безопасности

Записи памяти сканируются на предмет шаблонов инъекций и эксфильтрации перед принятием, поскольку они внедряются в системный промпт. Содержимое, соответствующее угрожающим шаблонам (инъекция промпта, эксфильтрация учетных данных, бэкдоры SSH) или содержащее невидимые символы Unicode, блокируется.

Поиск по сессиям

Помимо MEMORY.md и USER.md, агент может искать в своих прошлых разговорах с помощью инструмента session_search:

• Все сессии CLI и обмена сообщениями хранятся в SQLite (~/.vibeos/state.db) с полнотекстовым поиском FTS5
• Поисковые запросы возвращают фактические сообщения из БД — без обобщения LLM, без усечения
• Агент может найти то, что обсуждалось неделями ранее, даже если этого нет в его активной памяти
• Агент также может прокручивать вперед/назад внутри любой найденной сессии

Если текущая сессия привязана к проекту, session_search по умолчанию ищет только историю этого проекта. Используйте scope="all" только когда нужен поиск между проектами; сессия без подтвержденного проекта остаётся в области всего профиля. Прямое чтение явно указанной сессии не ограничивается.

vibeos sessions list    # Просмотр прошлых сессий

См. Инструмент поиска по сессиям для трех форм вызова (обнаружение / прокрутка / просмотр) и формата ответа.

session_search vs memory

Особенность	Постоянная память	Поиск по сессиям
Емкость	~1 300 токенов всего	Безлимитно (по умолчанию текущий проект; все сессии по запросу)
Скорость	Мгновенно (в системном промпте)	~20мс запрос FTS5, ~1мс прокрутка
Стоимость	Стоимость токенов в каждом промпте	Бесплатно — без вызовов LLM
Сценарий использования	Ключевые факты всегда доступны	Поиск конкретных прошлых разговоров
Управление	Вручную курируется агентом	Автоматически — все сессии хранятся
Стоимость токенов	Фиксированная за сессию (~1 300 токенов)	По запросу (ищется при необходимости)

Память предназначена для критических фактов, которые всегда должны быть в контексте. Поиск по сессиям — для запросов вроде «обсуждали ли мы X на прошлой неделе?», когда агенту нужно вспомнить конкретные детали из прошлых разговоров.

Конфигурация

# В ~/.vibeos/config.yaml
memory:
  memory_enabled: true
  user_profile_enabled: true
  memory_char_limit: 2200   # ~800 токенов
  user_char_limit: 1375     # ~500 токенов
  write_approval: false     # false = свободная запись (по умолчанию) | true = требуется одобрение

Контроль записи в память (write_approval)

По умолчанию агент свободно сохраняет в память — в том числе в фоновом обзоре самоулучшения, который запускается после оборота. Если вы предпочитаете сначала одобрять сохранения, установите memory.write_approval: true. Это простой включатель/выключатель, применяемый как к основным оборотам, так и к фоновому обзору:

write_approval	Поведение
false (по умолчанию)	Свободная запись — шлюз выключен (поведение до шлюза).
true	Требуется одобрение перед сохранением. В интерактивном CLI основные записи запрашивают одобрение в строке (записи достаточно малы, чтобы прочитать их полностью). Во всех остальных местах — платформах обмена сообщениями, скриптах и фоновом обзоре самоулучшения — записи откладываются для проверки с помощью /memory pending. В шлюзе пользователь видит и одобряет только собственные отложенные записи.

Чтобы полностью отключить память (а не просто поставить шлюз), установите memory_enabled: false.

Просматривайте отложенные записи из CLI или любой платформы обмена сообщениями:

/memory pending             # список отложенных записей памяти (автоматические помечены [auto])
/memory approve <id>        # применить одну (или 'all')
/memory reject <id>         # отклонить одну (или 'all')
/memory approval on         # включить шлюз (или 'off') и сохранить настройку

Это ответ на вопрос «агент сохранил неверное предположение обо мне»: установите
`write_approval: true`, и каждое сохранение — особенно фоновые без запроса — будет ждать вашего да/нет, прежде чем попасть в ваш профиль.

## Уведомления фонового обзора (`display.memory_notifications`)

После оборота фоновый обзор самоулучшения может незаметно сохранить запись памяти
или обновить навык. Это цикл обучения VibeOS с учетом согласия: повторяющиеся
исправления и долговременные уроки рабочего процесса становятся компактными записями памяти или
процедурными навыками, в то время как `write_approval` может откладывать эти записи для проверки
перед тем, как они повлияют на будущие сессии. По умолчанию он отображает короткую
строку `💾 Memory updated` в чате, чтобы вы знали, что это произошло. Управляйте тем, насколько
это многословно:

```yaml
display:
  memory_notifications: on    # off | on (по умолчанию) | verbose

Значение	Поведение
off	Нет уведомления в чате. Обзор все еще запускается и все еще записывает — вы просто не видите строку об этом.
on (по умолчанию)	Общая строка, например 💾 Memory updated, 💾 Skill 'foo' patched.
verbose	Включает компактный предварительный просмотр того, что изменилось, например 💾 Memory ➕ User prefers terse replies или фрагмент diff навыка "old" → "new".

Это управляет только шлюзовым уведомлением в чате. Сам обзор и записи в ваши хранилища памяти/навыков не зависят от этой настройки. Устанавливается для каждой платформы через display.platforms.<platform>.memory_notifications.

Запуск обзора на более дешевой модели (auxiliary.background_review)

По умолчанию обзор запускается на вашей основной чат-модели, воспроизводя разговор — который уже прогрет в кеше промпта, поэтому это дешевые чтения из кеша. На дорогой основной модели вы можете запустить обзор на более дешевой модели вместо этого:

auxiliary:
  background_review:
    provider: openrouter
    model: google/gemini-3-flash-preview   # auto (по умолчанию) = основная чат-модель

Когда вы указываете на модель, отличную от вашей основной, обзор запускается там со значительно меньшей стоимостью (~3–5× по бенчмаркам). Поскольку другая модель не может повторно использовать кеш промпта вашей основной модели, ответвление автоматически воспроизводит компактный дайджест разговора (последние обороты дословно + сводка более старых), а не полную стенограмму — минимизируя то, что записывается в новый кеш. Захват сохраняется: в тестировании захват памяти был идентичен, а захват навыков почти идентичен обзору на основной модели.

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

Контроль записи навыков (skills.write_approval)

Навыки используют тот же включатель/выключатель, но UX проверки отличается, потому что SKILL.md слишком велик, чтобы читать его в пузырьке чата:

skills:
  write_approval: false     # false = свободная запись (по умолчанию) | true = требуется одобрение

Когда write_approval: true, записи навыков (create / edit / patch / write_file / delete) всегда откладываются независимо от источника. Вы просматриваете однострочную суть в строке, но полный diff остается вне канала:

/skills pending             # список отложенных записей навыков + однострочная суть каждой
/skills diff <id>           # полный unified diff (лучше всего просматривать в CLI или на панели)
/skills approve <id>        # применить его (или 'all')
/skills reject <id>         # отклонить его (или 'all')
/skills approval on         # включить шлюз (или 'off') и сохранить настройку

На платформе обмена сообщениями одобрите навык по его сути + метаданным или откройте /skills diff в CLI / на панели / в отложенном файле в ~/.vibeos/pending/skills/<id>.json, когда захотите прочитать все изменение. Полные детали в Шлюзование записи навыков агентом.

Внешние провайдеры памяти

Для более глубокой, постоянной памяти, выходящей за рамки MEMORY.md и USER.md, VibeOS поставляется с 8 плагинами внешних провайдеров памяти — включая Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover и Supermemory.

Внешние провайдеры работают параллельно со встроенной памятью (никогда не заменяя ее) и добавляют такие возможности, как графы знаний, семантический поиск, автоматическое извлечение фактов и межсессионное моделирование пользователя.

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

См. руководство Провайдеры памяти для получения полной информации о каждом провайдере, инструкциях по настройке и сравнении.