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

​
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), сохраняемые и затем реинжектируемые на следующем ходу
  1. Подложка памяти в стиле 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» — приближённое извлечение ближайших соседей.