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

Эксперименты

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

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

Почему изменения?​

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

  • ведения «только для добавления» журнала
  • редактирования человеком
  • устойчивости и аудируемости с поддержкой git
  • простого захвата («просто запиши это»)

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

  • высококачественного поиска («что мы решили насчёт X?», «в прошлый раз, когда мы пробовали Y?»)
  • ответов, ориентированных на сущности («расскажи об Алисе / Замке / warelay») без перечитывания многих файлов
  • стабильности мнений/предпочтений (и доказательств, когда они меняются)
  • временных ограничений («что было правдой в ноябре 2025?») и разрешения конфликтов

Цели проектирования​

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

Модель конечной цели (Hindsight × Letta)​

Две части для объединения:

  1. Цикл управления в стиле Letta/MemGPT
  • сохранять небольшое «ядро» всегда в контексте (персона + ключевые факты о пользователе)
  • всё остальное находится вне контекста и извлекается с помощью инструментов
  • записи в память — это явные вызовы инструментов (добавить/заменить/вставить), которые сохраняются, а затем повторно вводятся в следующий ход
  1. Субстрат памяти в стиле Hindsight
  • разделять наблюдаемое, во что верят и что обобщено
  • поддерживать retain/recall/reflect
  • мнения с указанием уверенности, которые могут эволюционировать с доказательствами
  • поиск с учётом сущностей + временные запросы (даже без полных графов знаний)

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

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

Сохранить ~/.openclaw/workspace как каноническую, читаемую человеком память. Предлагаемая структура рабочего пространства:

~/.openclaw/workspace/
  memory.md                    # небольшой: долговечные факты + предпочтения (ядро)
  memory/
    YYYY-MM-DD.md              # ежедневный лог (добавление; повествование)
  bank/                        # «типизированные» страницы памяти (стабильные, проверяемые)
    world.md                   # объективные факты о мире
    experience.md              # что агент сделал (от первого лица)
    opinions.md                # субъективные предпочтения/суждения + уверенность + указатели на доказательства
    entities/
      Peter.md
      The-Castle.md
      warelay.md
      ...

Примечания:

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

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

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

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

Поддерживать его с помощью:

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

Индекс всегда можно перестроить из 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, и т.д. (слаг соответствует bank/entities/*.md)
  • Уверенность мнения: O(c=0.0..1.0) опционально

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

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

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

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

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

  • 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 («ядро» долговечных фактов)

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

  • каждое мнение имеет:
    • утверждение
    • уверенность 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
  • повторное использование в других контекстах (локальные скрипты, будущее десктопное приложение и т.д.)

Форма: Инструментарий памяти задуман как небольшой слой 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 существенно ограничено лексическим поиском

Offline-дружелюбные альтернативы (по возрастанию сложности):

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

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

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

Самый маленький полезный пилот​

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

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

Ссылки​

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

План привязки сессии, независимый от каналаИсследование конфигурации модели