> ## Documentation Index
> Fetch the complete documentation index at: https://openclaw.veiseule.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Исследование памяти рабочего пространства

# Workspace Memory v2 (offline): исследовательские заметки

Цель: рабочее пространство в стиле Clawd (`agents.defaults.workspace`, по умолчанию `~/.openclaw/workspace`), где «память» хранится как один Markdown‑файл в день (`memory/YYYY-MM-DD.md`) плюс небольшой набор стабильных файлов (например, `memory.md`, `SOUL.md`).

В этом документе предлагается архитектура памяти **offline-first**, которая сохраняет Markdown в качестве канонического, проверяемого человеком источника истины, но добавляет **структурированный recall** (поиск, сводки по сущностям, обновления уверенности) через производный индекс.

## Зачем менять?

Текущая схема (один файл в день) отлично подходит для:

* «append-only» журналирования
* ручного редактирования человеком
* надёжности и аудируемости на базе git
* низкого порога ввода («просто запиши это»)

Она слаба для:

* извлечения с высоким recall («что мы решили про X?», «когда мы в прошлый раз пробовали Y?»)
* ответов, ориентированных на сущности («расскажи про Alice / The Castle / warelay») без перечитывания множества файлов
* стабильности мнений/предпочтений (и наличия доказательств при их изменении)
* временных ограничений («что было верно в ноябре 2025?») и разрешения конфликтов

## Цели дизайна

* **Офлайн**: работает без сети; может запускаться на ноутбуке/Castle; без облачных зависимостей.
* **Объяснимость**: извлечённые элементы должны быть атрибутируемы (файл + позиция) и отделимы от вывода.
* **Низкая церемониальность**: ежедневное логирование остаётся Markdown, без тяжёлых схем.
* **Инкрементальность**: v1 полезна уже с одним FTS; семантика/векторы и графы — опциональные апгрейды.
* **Дружелюбие к агентам**: упрощает «recall в рамках токен‑бюджетов» (возврат небольших пакетов фактов).

## Модель «северной звезды» (Hindsight × Letta)

Два компонента для объединения:

1. **Контур управления в стиле Letta/MemGPT**

* держать небольшой «core», который всегда в контексте (персона + ключевые факты о пользователе)
* всё остальное — вне контекста и извлекается через инструменты
* записи в память — это явные вызовы инструментов (append/replace/insert), сохраняемые и затем реинжектируемые на следующем ходу

2. **Подложка памяти в стиле Hindsight**

* отдельно, что наблюдалось и что считали против того, что суммировано
* поддержка retain/recall/reflect
* мнения с уровнем уверенности, которые могут эволюционировать с появлением доказательств
* извлечение с учётом сущностей и временные запросы (даже без полноценных графов знаний)

## Предлагаемая архитектура (Markdown как источник истины + производный индекс)

### Каноническое хранилище (дружелюбное к git)

Оставить `~/.openclaw/workspace` в качестве канонической, человекочитаемой памяти.

Предлагаемая структура рабочего пространства:

```
~/.openclaw/workspace/
  memory.md                    # small: durable facts + preferences (core-ish)
  memory/
    YYYY-MM-DD.md              # daily log (append; narrative)
  bank/                        # “typed” memory pages (stable, reviewable)
    world.md                   # objective facts about the world
    experience.md              # what the agent did (first-person)
    opinions.md                # subjective prefs/judgments + confidence + evidence pointers
    entities/
      Peter.md
      The-Castle.md
      warelay.md
      ...
```

Примечания:

* **Ежедневный лог остаётся ежедневным логом**. Нет необходимости превращать его в JSON.
* Файлы `bank/` являются **курируемыми**, создаются задачами рефлексии и всё ещё могут редактироваться вручную.
* `memory.md` остаётся «маленьким + core‑подобным»: тем, что вы хотите, чтобы Clawd видел в каждом сеансе.

### Производное хранилище (машинный recall)

Добавить производный индекс под рабочим пространством (не обязательно отслеживаемый git):

```
~/.openclaw/workspace/.memory/index.sqlite
```

Назад с помощью:

* схема SQLite для фактов + связей сущностей + метаданных мнений
* SQLite **FTS5** для лексического recall (быстро, компактно, офлайн)
* опциональная таблица эмбеддингов для семантического recall (тоже офлайн)

Индекс всегда **перестраиваем из Markdown**.

## Retain / Recall / Reflect (операционный цикл)

### Retain: нормализация ежедневных логов в «факты»

Ключевой инсайт Hindsight, который здесь важен: хранить **нарративные, самодостаточные факты**, а не крошечные фрагменты.

Практическое правило для `memory/YYYY-MM-DD.md`:

* в конце дня (или по ходу) добавлять раздел `## Retain` с 2–5 пунктами, которые:
  * нарративны (межходовой контекст сохранён)
  * самодостаточны (имеют смысл сами по себе позже)
  * помечены типом + упоминаниями сущностей

Пример:

```
## Retain
- W @Peter: Currently in Marrakech (Nov 27–Dec 1, 2025) for Andy’s birthday.
- B @warelay: I fixed the Baileys WS crash by wrapping connection.update handlers in try/catch (see memory/2025-11-27.md).
- O(c=0.95) @Peter: Prefers concise replies (<1500 chars) on WhatsApp; long content goes into files.
```

Минимальный парсинг:

* Префикс типа: `W` (мир), `B` (опыт/биографическое), `O` (мнение), `S` (наблюдение/сводка; обычно генерируется)
* Сущности: `@Peter`, `@warelay` и т. д. (slug’и сопоставляются с `bank/entities/*.md`)
* Уверенность мнения: `O(c=0.0..1.0)` — необязательно

Если вы не хотите, чтобы авторы об этом думали: задача reflect может выводить эти пункты из остальной части лога, но наличие явного раздела `## Retain` — самый простой «рычаг качества».

### Recall: запросы к производному индексу

Recall должен поддерживать:

* **лексический**: «найти точные термины / имена / команды» (FTS5)
* **по сущностям**: «расскажи про X» (страницы сущностей + связанные с сущностью факты)
* **временной**: «что происходило около 27 ноября» / «с прошлой недели»
* **по мнениям**: «что предпочитает Peter?» (с уверенностью + доказательствами)

Формат возврата должен быть удобным для агента и содержать ссылки на источники:

* `kind` (`world|experience|opinion|observation`)
* `timestamp` (день‑источник или извлечённый временной диапазон, если присутствует)
* `entities` (`["Peter","warelay"]`)
* `content` (нарративный факт)
* `source` (`memory/2025-11-27.md#L12` и т. д.)

### Reflect: создание стабильных страниц + обновление убеждений

Рефлексия — это плановая задача (ежедневно или по heartbeat `ultrathink`), которая:

* обновляет `bank/entities/*.md` на основе недавних фактов (сводки по сущностям)
* обновляет уверенность `bank/opinions.md` на основе подкрепления/противоречий
* опционально предлагает правки в `memory.md` («core‑подобные» устойчивые факты)

Эволюция мнений (простая, объяснимая):

* каждое мнение имеет:
  * формулировку
  * уверенность `c ∈ [0,1]`
  * last\_updated
  * ссылки на доказательства (поддерживающие + противоречащие ID фактов)
* при поступлении новых фактов:
  * находятся кандидаты‑мнения по пересечению сущностей + сходству (сначала FTS, затем эмбеддинги)
  * уверенность обновляется малыми дельтами; большие скачки требуют сильного противоречия + повторяющихся доказательств

## Интеграция с CLI: автономно vs глубокая интеграция

Рекомендация: **глубокая интеграция в OpenClaw**, но с сохранением отделяемого ядра‑библиотеки.

### Почему интегрировать в OpenClaw?

* OpenClaw уже знает:
  * путь к рабочему пространству (`agents.defaults.workspace`)
  * модель сеансов + heartbeats
  * паттерны логирования и устранения неполадок
* Нужно, чтобы сам агент вызывал инструменты:
  * `openclaw memory recall "…" --k 25 --since 30d`
  * `openclaw memory reflect --since 7d`

### Почему всё же отделять библиотеку?

* логика памяти остаётся тестируемой без Gateway (шлюз)/runtime
* повторное использование в других контекстах (локальные скрипты, будущие desktop‑приложения и т. д.)

Форма:
Инструментарий памяти задуман как небольшой слой CLI + библиотека, но это лишь исследовательский вариант.

## «S‑Collide» / SuCo: когда использовать (исследование)

Если «S‑Collide» означает **SuCo (Subspace Collision)**: это подход ANN‑извлечения, нацеленный на выгодный компромисс между recall и латентностью за счёт обученных/структурированных коллизий в подпространствах (статья: arXiv 2411.14754, 2024).

Прагматичный вывод для `~/.openclaw/workspace`:

* **не начинать** с SuCo.
* начать с SQLite FTS + (опционально) простых эмбеддингов; вы сразу получите большую часть UX‑выигрышей.
* рассматривать решения класса SuCo/HNSW/ScaNN только когда:
  * корпус становится большим (десятки/сотни тысяч чанков)
  * брутфорс‑поиск по эмбеддингам становится слишком медленным
  * качество recall заметно упирается в лексический поиск

Офлайн‑дружелюбные альтернативы (по возрастанию сложности):

* SQLite FTS5 + фильтры по метаданным (0 ML)
* Встроение + грубая сила (работает, как удивительно, далеко если количество чанков невелико)
* Индекс HNSW (распространённый, надёжный; требует биндинга библиотеки)
* SuCo (исследовательский уровень; привлекателен при наличии надёжной встраиваемой реализации)

Открытый вопрос:

* какая **лучшая** офлайн‑модель эмбеддингов для «памяти персонального ассистента» на ваших машинах (ноутбук + десктоп)?
  * если у вас уже есть Ollama: делать эмбеддинги локальной моделью; иначе поставлять небольшую модель эмбеддингов в составе инструментария.

## Минимально полезный пилот

Если нужен минимальный, но всё ещё полезный вариант:

* Добавить страницы сущностей `bank/` и раздел `## Retain` в ежедневные логи.
* Использовать SQLite FTS для recall с цитированием (путь + номера строк).
* Добавлять эмбеддинги только если качество recall или масштаб этого требуют.

## Ссылки

* Концепции Letta / MemGPT: «core memory blocks» + «archival memory» + память с саморедактированием через инструменты.
* Технический отчёт Hindsight: «retain / recall / reflect», память из четырёх сетей, извлечение нарративных фактов, эволюция уверенности мнений.
* SuCo: arXiv 2411.14754 (2024): «Subspace Collision» — приближённое извлечение ближайших соседей.