OpenClaw и память без амнезии: что выбрать между Lossless Claw, OpenViking, ByteRover, MemPalace и LLM Wiki / Хабр

Когда говорят «память для ИИ-агента», очень легко начать спорить о разном, думая, что обсуждается одно и то же.

Один человек хочет, чтобы агент не забывал длинные рабочие диалоги. Другой ждёт от памяти нормальную базу знаний по проекту. Третий хочет отдельный контекстный слой уровня платформы, где рядом живут документы, навыки, пользовательские предпочтения и служебные данные. Четвёртому вообще не нравится идея, что модель заранее решает, что важно, а что можно выбросить. А пятый хочет не архив и не векторную базу, а живую внутреннюю wiki, которую агент сам поддерживает в актуальном состоянии.

На OpenClaw эта развилка видна особенно хорошо. У платформы уже есть понятная архитектура плагинов и отдельный слот plugins.slots.contextEngine, куда можно подключать внешний движок контекста. А в последнем обновлении OpenClaw 2026.4.7 в вернули и встроенный memory-wiki stack — то есть подход с накопительной wiki уже перестал быть просто красивой идеей из заметки и стал частью реального инструментария.

Если смотреть на самые интересные подходы к памяти для OpenClaw прямо сейчас, то разговор крутится вокруг пяти систем и направлений:

Lossless Claw
OpenViking
ByteRover
MemPalace
LLM Wiki как подход, который теперь ещё и встроен в OpenClaw через memory-wiki stack

Все они про память. Но смысл у этой памяти разный.

Если коротко, то картина такая. Lossless Claw решает проблему длинной истории диалога. OpenViking строит полноценную базу контекста для агентов. ByteRover превращает рабочий опыт в аккуратное знание по проекту. MemPalace делает ставку на дословное хранение всего и хороший поиск по архиву. А LLM Wiki вообще смотрит на память как на постоянно растущую и обновляемую wiki, которую агент ведёт сам.

Ниже разберу: как устроено, как ставится, как выглядит рядом с OpenClaw и для каких задач подходит лучше всего.

С чего вообще начинается память в OpenClaw

В OpenClaw внешний модуль памяти подключается как движок контекста. На уровне конфига это выглядит так:

{
  "plugins": {
    "slots": {
      "contextEngine": "<plugin-id>"
    }
  }
}

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

И вот в этот момент каждый подход начинает отвечать на свой вопрос.

Lossless Claw говорит: главное — не потерять историю разговора.

OpenViking говорит: надо мыслить шире и хранить всё контекстное пространство агента.

ByteRover говорит: ценность не в архиве как таковом, а в полезном знании, которое агент накапливает по проекту.

MemPalace говорит: не надо заранее сокращать память, храните всё дословно и хорошо ищите потом.

LLM Wiki говорит: память — это вообще не столько архив и не столько поиск, сколько живая, растущая wiki, которую агент сам ведёт и обновляет.

Именно поэтому сравнивать все эти вещи как «пять похожих систем памяти» не очень честно. На самом деле это пять разных архитектурных взглядов на одну проблему.

Lossless Claw: когда агент должен помнить путь, а не только итог

Lossless Claw — самый прямой и понятный ответ на проблему забывающего агента. Его логика очень простая: если разговор длинный, старые сообщения не должны умирать только потому, что закончилось окно токенов.

Многие сталкивались с этим ощущением. Пока диалог короткий, агент помнит всё довольно уверенно. Потом обсуждение разрастается, появляются инструменты, журналы, ошибки, повторные попытки, архитектурные развилки. В какой-то момент агент вроде бы ещё помнит тему, но уже не помнит, почему пришли именно к этому решению и что именно ломалось по дороге. Это неприятная форма частичной амнезии: общий контур остался, а рабочая память о деталях развалилась.

Lossless Claw пытается закрыть именно эту дыру. Он сохраняет сообщения в SQLite и сворачивает старые части разговора в многоуровневые сводки. При этом свежий хвост диалога остаётся в исходном виде, а старая часть не просто пропадает, а переходит в структурированную память, из которой потом можно снова достать нужное.

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

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

Ставится он довольно просто:

openclaw plugins install @martian-engineering/lossless-claw

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

{
  "plugins": {
    "slots": {
      "contextEngine": "lossless-claw"
    }
  }
}

Обычно ещё рекомендуют такие настройки:

export LCM_FRESH_TAIL_COUNT=32
export LCM_INCREMENTAL_MAX_DEPTH=-1

В реальной жизни Lossless Claw особенно хорош в длинных отладочных сессиях, при сложной разработке, в обсуждениях архитектуры, в инцидентах и во всех случаях, когда важен не только ответ, но и путь к нему.

Его ограничение тоже довольно очевидно. Это не большая база знаний уровня команды и не универсальная контекстная система для всего подряд. Это в первую очередь сильное решение именно для памяти разговора и рабочей сессии.

Если задача звучит как «пусть агент наконец перестанет забывать собственную историю работы», Lossless Claw — один из лучших вариантов рядом с OpenClaw.

OpenViking: память как инфраструктура, а не просто как модуль

OpenViking — это уже другой класс системы. Если Lossless Claw хочется назвать хорошей памятью разговора, то OpenViking больше похож на полноценную базу контекста для агентов.

Его авторы уходят от модели «есть векторная база, назовём её памятью» и предлагают более структурированный взгляд. Контекст у них похож на виртуальную файловую систему, где есть ресурсы, память пользователя, память агента, навыки и сессионные данные. Всё это живёт в пространстве адресов viking://..., и благодаря этому агент работает не просто с кучей похожих фрагментов, а с разделами, путями и уровнями детализации.

В этом и состоит главный смысл OpenViking. Он пытается сделать память не побочным эффектом поиска, а самостоятельным слоем платформы.

Технически у него сразу несколько сильных сторон. Во-первых, он разделяет типы контекста, а не складывает всё в одну кучу. Во-вторых, умеет раскладывать материалы по уровням детализации: короткое описание, обзор и полные подробности. Это удобно, потому что агент не обязан каждый раз читать всё целиком. Он может сначала взять сжатый уровень, затем обзор и только потом углубиться.

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

Именно поэтому он выглядит ближе к инфраструктурному решению, чем к просто удобному плагину.

Ставится OpenViking тяжелее, чем Lossless Claw. Быстрый путь для связки с OpenClaw такой:

npm install -g openclaw-openviking-setup-helper
ov-install

Есть и установка через скрипт:

curl -fsSL https://raw.githubusercontent.com/volcengine/OpenViking/main/examples/openclaw-plugin/install.sh | bash

Если ставить сам OpenViking отдельно, появляются Python, Go, компилятор C++, дополнительные модели для эмбеддингов и визуально-языковых задач. Это сразу показывает масштаб решения: оно шире и тяжелее обычного локального слоя памяти.

С OpenClaw OpenViking работает как нативный движок контекста. Типичный пример настройки удалённого режима выглядит так:

openclaw plugins enable openviking
openclaw config set gateway.mode local
openclaw config set plugins.slots.contextEngine openviking
openclaw config set plugins.entries.openviking.config.mode remote
openclaw config set plugins.entries.openviking.config.baseUrl "http://your-server:1933"
openclaw config set plugins.entries.openviking.config.apiKey "<user-api-key>"
openclaw config set plugins.entries.openviking.config.agentId "<agent-id>"
openclaw config set plugins.entries.openviking.config.autoRecall true --json
openclaw config set plugins.entries.openviking.config.autoCapture true --json
openclaw gateway restart

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

Главный минус предсказуем: за широту приходится платить сложностью. Если вам нужна только хорошая память длинного разговора, OpenViking легко окажется слишком тяжёлым. Но если нужен контекстный слой уровня платформы, это очень сильный кандидат.

ByteRover: память как аккуратно собранное знание по проекту

ByteRover интересен тем, что почти не пытается спорить ни за длинную историю разговора, ни за роль универсальной базы контекста. Его ответ другой: память ценна не сама по себе, а тогда, когда превращается в полезное знание по проекту.

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

В основе у него лежит дерево контекста в .brv/context-tree/. Там знания раскладываются по доменам, темам и подтемам. Каждый файл — обычный markdown с метаданными, фактами, описанием и связями. Поверх этого автоматически строятся обзорные файлы, иерархические сводки и служебный индекс для подмешивания структуры в запросы.

Сильная сторона ByteRover в том, что память здесь становится не невидимой магией, а вполне читаемым артефактом. Её можно открыть, проверить, отредактировать, положить в Git, обсудить на ревью. Для инженерной работы это очень полезное качество. Когда память агента превращается в чёрный ящик, ей быстро перестают доверять.

Рабочий цикл у ByteRover понятный. Перед ответом он извлекает запрос, запускает brv query, ищет релевантные знания в дереве контекста и подмешивает их в системную часть запроса модели. После завершения хода запускается brv curate, который превращает полезные выводы из разговора в новые или обновлённые файлы знаний.

Именно это и определяет характер системы. ByteRover строит память через связку поиска и курирования. Он не стремится сохранить всё подряд. Он стремится постепенно накапливать то, что имеет устойчивую ценность.

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

С OpenClaw ByteRover работает как нативный движок контекста, но особенно полезен он двумя дополнительными вещами.

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

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

Ставится сам ByteRover просто:

curl -fsSL https://byterover.dev/install.sh | sh

или:

npm install -g byterover-cli

Для интеграции с OpenClaw есть отдельный сценарий:

curl -fsSL https://byterover.dev/openclaw-setup.sh | sh

На практике ByteRover особенно хорош там, где агент работает как инженер в кодовой базе: в проектной памяти, памяти команды, базе правил, решений и повторяющихся наработок.

Его ограничение: это не лучший ответ на задачу «помни весь разговор как есть». Он сильнее всего именно там, где память должна стать качественным знанием по проекту.

MemPalace: сильный ответ на вопрос «зачем вообще сокращать память на входе?»

MemPalace сейчас обсуждают много, конечно, из-за Миллы Йовович, которая выступала в роли архитектора в этом проекте.

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

MemPalace предлагает не делать этого заранее. Вместо этого он хранит разговоры дословно и делает ставку на хороший поиск по архиву. То есть память здесь не сводится к раннему извлечению фактов. Она строится через сохранение исходного материала.

В базовом виде MemPalace хранит разговоры в ChromaDB без обязательной сводки и без обязательного извлечения памяти на этапе записи. И именно этот сырой режим дал ему сильный результат на LongMemEval — 96.6% R@5 без внешних API и без модели, которая участвовала бы в самом процессе хранения памяти.

На мой взгляд, это и есть главный факт про MemPalace. Не экспериментальные обещания, не спор вокруг отдельных формулировок, а сама мысль, что дословное хранение плюс хороший поиск оказалось сильнее, чем многие более «умные» схемы с предварительным извлечением памяти.

Поверх архива MemPalace строит иерархию, которую авторы описывают как дворец памяти. Там есть крылья, комнаты, типы памяти, краткие указатели на исходные материалы и связи между темами. Если убрать образный язык, то получится более прагматичная картина: структурированная адресация архива, фильтрация поиска по областям и дополнительные слои навигации.

Ставится он довольно просто:

pip install mempalace

Дальше инициализация:

mempalace init ~/projects/myapp

Затем загрузка данных:

mempalace mine ~/projects/myapp
mempalace mine ~/chats/ --mode convos
mempalace mine ~/chats/ --mode convos --extract general

Поиск выглядит так:

mempalace search "why did we switch to GraphQL"

Есть и дополнительные команды вроде wake-up, status, split и compress, но суть не меняется: хранить как можно ближе к исходному тексту и искать потом.

Здесь важно отдельно отметить вещь, которую авторам MemPalace я бы скорее записал в плюс. Они довольно быстро публично признали, что часть ранних формулировок была слишком смелой. В частности, они отдельно уточнили, что экспериментальный слой AAAK пока не даёт тех чудес, которые ему сначала приписывали, что история про «30-кратное сжатие без потерь» была завышением, а часть заявленных возможностей ещё не была встроена в основной рабочий путь.

С OpenClaw история у него особая. На момент изучения MemPalace не выглядит нативным движком контекста для слота plugins.slots.contextEngine в том же смысле, как Lossless Claw, OpenViking или ByteRover. Его логичнее воспринимать как внешний слой памяти рядом с OpenClaw.

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

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

LLM Wiki: память не как поиск, а как постоянно растущая wiki

Теперь к самому интересному новому слою в этой картине.

LLM Wiki — это не просто ещё одна система рядом с остальными. Это отдельный подход к памяти, который особенно хорошо сформулировал Андрей Карпатый, один из основателей OpenAI, в заметке про personal knowledge bases using LLMs.

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

LLM Wiki предлагает другой путь. Вместо того чтобы каждый раз извлекать знание из сырья, агент постепенно строит и поддерживает постоянную wiki из markdown-файлов, которая живёт между сырыми источниками и ответами пользователю.

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

И вот это и есть суть подхода: знание компилируется один раз и затем поддерживается в актуальном состоянии, а не добывается заново с нуля на каждый запрос.

В git очень хорошо сформулирована трёхслойная схема:

есть сырые источники, которые не меняются и остаются источником истины;
есть сама wiki — набор сгенерированных и поддерживаемых страниц;
есть схема или протокол, который объясняет агенту, как эту wiki вести.

Это очень важное отличие от обычного поиска по документам. Здесь память — это уже не просто retrieval. Это накапливающийся рабочий артефакт.

Почему этот подход особенно важен именно сейчас

Потому что OpenClaw уже не просто «может когда-нибудь это сделать», а в релизе v2026.4.7 прямо вернул bundled memory-wiki stack.

В release notes это описано как встроенный стек с:

плагином;
CLI с sync/query/apply-инструментами;
интеграцией с memory-host;
структурированными полями утверждений и доказательств;
поиск сводных дайджестов;
проверка достоверности утверждений;
кластеризация противоречий;
панели мониторинга устаревших данных;
поиск с учетом актуальности.

Это уже очень важный шаг. Потому что LLM Wiki перестаёт быть просто красивой практикой в Obsidian и становится полноценным встроенным направлением внутри OpenClaw.

Что это значит на практике

Если объяснить без маркетинга, то встроенный memory-wiki stack в OpenClaw делает ставку на то, что память — это не только поиск по архиву и не только сводка разговоров. Это ещё и поддерживаемый набор утверждений, страниц, доказательств, сводок и связей, который можно синхронизировать, проверять, пересобирать и оздоравливать как отдельную систему знаний.

То есть LLM Wiki находится где-то между ByteRover и идеей полноценно поддерживаемой базы знаний, но с ещё более явным упором на wiki как главный артефакт.

Где LLM Wiki особенно силён

Этот подход особенно хорош там, где знание накапливается неделями и месяцами, а не живёт в рамках одной сессии. Исследования, конкурентный анализ, длительные проекты, личные базы знаний, командные wiki, рабочие материалы по теме, где важно не просто что-то найти, а иметь уже собранную, связанную и поддерживаемую картину.

Именно поэтому появление встроенного memory-wiki stack в OpenClaw — важная новость. OpenClaw теперь поддерживает не только память как историю сессий и не только память как поиск, но и память как поддерживаемый накопительный слой знания.

Ограничение подхода тоже честное

LLM Wiki — не лучший ответ, если вам просто нужна хорошая память длинного разговора здесь и сейчас. Это подход более стратегический. Он требует структуры, дисциплины и выгоду даёт сильнее на дистанции, чем в одном конкретном диалоге.

Но если ваша задача звучит как «пусть агент не просто помнит, а ведёт растущую картину знаний», то это один из самых интересных путей вообще.

Чем все эти подходы отличаются на практике

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

Подход	Главная сильная сторона	Что запоминает лучше всего	Как выглядит рядом с OpenClaw
Lossless Claw	Длинная память разговора	Историю сессий, отладку, путь к решению	Нативный движок контекста
OpenViking	Широкий контекстный слой	Память, ресурсы, навыки, служебные данные	Нативный движок контекста
ByteRover	Память проекта и команды	Решения, правила, наработки, знания по коду	Нативный движок контекста
MemPalace	Дословный архив и сильный поиск	Разговоры, выгрузки чатов, причинно-следственный контекст	Внешний слой памяти рядом с OpenClaw
LLM Wiki / memory-wiki	Накопительная живая база знаний	Темы, сущности, утверждения, доказательства, evolving wiki	Уже встроенное направление в OpenClaw

И тут хорошо видно, что вопрос «что лучше» сам по себе почти бесполезен. Гораздо полезнее спрашивать: какая именно память вам нужна.

Что я бы выбрал под разные задачи

Если нужен агент, который ведёт длинные рабочие сессии и не должен забывать ход обсуждения, я бы первым делом смотрел на Lossless Claw. Он лучше всего решает именно проблему длинной истории разговора.

Если нужен отдельный контекстный слой уровня платформы — с ресурсами, навыками, памятью и серверной жизнью — я бы смотрел на OpenViking. Это самый широкий и самый инфраструктурный вариант из всех.

Если агент в основном работает как инженер в проекте, а память должна постепенно превращаться в полезное знание по коду, архитектуре и правилам команды, я бы выбрал ByteRover. Он очень хорош там, где важны качество и читаемость накопленного знания.

Если нужна локальная память без предварительного сокращения разговоров и вообще не хочется доверять модели решение о том, что нужно помнить, я бы очень серьёзно смотрел на MemPalace. Именно как на сильный внешний архив и поисковый слой.

Если же задача шире и память должна превращаться в поддерживаемую wiki — с утверждениями, доказательствами, обновлением страниц, поиском по digest-слоям, проверкой противоречий и устаревания, — тогда самым интересным вариантом становится LLM Wiki, тем более что для OpenClaw это уже не просто идея, а встроенное направление через memory-wiki stack.

Вывод

Рынок памяти для ИИ-агентов наконец перестаёт сводиться к одному и тому же трюку под разными названиями. И это видно очень хорошо.

Lossless Claw силён там, где нужно сохранить именно историю разговора и рабочий путь к решению.

OpenViking силён там, где нужен полноценный контекстный слой, а не просто память отдельной сессии.

ByteRover силён там, где память должна постепенно превращаться в полезное и читаемое знание по проекту.

MemPalace силён там, где хочется хранить всё дословно и не терять нюансы ещё на этапе записи.

LLM Wiki силён там, где память должна быть не архивом и не просто поиском, а живой wiki, которую агент сам поддерживает в актуальном состоянии.

Если совсем коротко:

нужна память разговора — Lossless Claw;
нужна база контекста уровня платформы — OpenViking;
нужна память проекта и кодовой базы — ByteRover;
нужен локальный дословный архив с сильным поиском — MemPalace;
нужна накапливающаяся живая wiki знаний — LLM Wiki / memory-wiki в OpenClaw.

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

Полезные ссылки

👇Русскоязычное сообщество AI энтузиастов

https://t.me/openclaw_lab