Memory Wiki

История разговоров — ещё не память.

У AI-ассистента может быть длинная история сессий, но сама по себе она почти не помогает вернуться к прошлому решению. Линейный список отвечает на вопрос «что было последним», но плохо отвечает на вопросы «когда мы это делали», «какие разговоры относятся к этой теме» и «где именно было принято решение».

Memory Wiki появился как небольшой локальный инструмент для восстановления этой навигации. Он не пытается решить всю задачу памяти агента. Его задача уже и практичнее: превратить экспорт разговоров Hermes в карту, которую способен читать и проверять человек.

Что получается на выходе

Одна команда экспорта даёт JSONL, а dependency-free Python generator собирает из него полностью статический сайт:

hermes sessions export data/sessions.jsonl
python3 memory_wiki.py \
  --input data/sessions.jsonl \
  --output site \
  --timezone Europe/Moscow

Готовую папку можно открыть обычным локальным сервером:

cd site
python3 -m http.server 8088

Никакая база данных, backend-процесс или JavaScript framework для просмотра не нужны.

Четыре способа вернуться к прошлой работе

Overview

Главная страница показывает последние сессии и общий индекс. Это не dashboard с искусственными метриками, а точка входа в реальные страницы.

Days

Каждая календарная дата получает отдельную страницу со списком разговоров за этот день. Это полезно, когда память о работе привязана не к точному названию, а к периоду: «мы обсуждали это где-то на прошлой неделе».

Topics

В текущей версии заголовок сессии становится одной стабильной темой. Это намеренно простая модель: она не создаёт шумные автоматически придуманные кластеры и оставляет возможность позднее добавить ручное объединение тем.

Sessions

Каждый разговор получает собственную страницу с source, временем, сообщениями и ссылками обратно на день и тему. Так решение можно увидеть в исходном контексте, а не только в пересказе.

Поиск остаётся локальным

Во время сборки создаётся search-index.json. Небольшой search.js загружает его через fetch() и ищет прямо в браузере:

• по session title;
• по тексту сообщений user и assistant;
• по всем словам запроса;
• с повышенным весом совпадения в заголовке;
• с коротким фрагментом вокруг найденного слова.

Результаты ограничены первыми 50 совпадениями. Это обычный substring search, а не embeddings и не semantic search — ограничение здесь важнее красивого названия функции.

Privacy by default

История агента может содержать команды, локальные пути и чувствительные фрагменты. Поэтому генератор по умолчанию исключает сообщения роли tool и любой tool-output как из session pages, так и из поискового индекса.

Если такие сообщения действительно нужны, их можно включить явно через --include-tools. Кроме этого, весь текст проходит HTML escaping: содержимое разговора не может превратиться в исполняемый HTML или JavaScript на сгенерированной странице.

Сайт задуман как host-local поверхность. Публиковать реальную сборку без отдельной очистки данных нельзя.

---

Что проверено сейчас

Текущая локальная сборка успешно обрабатывает 31 сессию и создаёт 12 дневных страниц и 31 страницу темы. Четыре unit tests проверяют:

• создание кликабельных day, topic и session pages;
• стабильную модель «один session title — одна тема»;
• HTML escaping и исключение tool messages;
• поиск по заголовку и содержимому без попадания tool-output в индекс.

Screenshot выше собран отдельно из двух файлов в examples/sample-sessions.jsonl. Он показывает настоящий интерфейс генератора, но не раскрывает мои реальные разговоры.

Где заканчивается этот инструмент

Memory Wiki не знает, какое решение было правильным, не объединяет похожие темы и не выбирает контекст для следующего запроса агента. Статический сайт также не обновляется сам: сначала нужен новый export, затем rebuild.

Поэтому я разделяю несколько разных слоёв:

• history — исходные разговоры;
• human navigation — Memory Wiki;
• retrieval — поиск подходящего контекста;
• long-term memory — отдельный механизм удержания устойчивых фактов.

Проект отвечает только за второй слой и частично за простой lexical search. Эта узкая граница делает его понятным и проверяемым.

Что имеет смысл сделать дальше

Ближайшие улучшения не требуют превращать проект в платформу:

1. user-level systemd timer для ежедневного export и rebuild;
2. ручной topics.json для переименования и объединения тем;
3. фильтры поиска по дню и source;
4. подсветка совпадений без изменения локальной архитектуры;
5. приватная раздача через Caddy или nginx, если host-local доступа станет недостаточно.

Главная ценность Memory Wiki для меня не в количестве страниц. Он сделал историю работы наблюдаемой: прежде чем просить агента «помнить всё», можно увидеть, какие данные уже существуют, как они организованы и где проходят реальные границы памяти.