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

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

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

Сейчас в фокусе пять систем:

• Lossless Claw
• OpenViking
• ByteRover
• MemPalace
• LLM Wiki — теперь и встроен в OpenClaw

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

Кратко:

• Lossless Claw — сохраняет историю диалога.
• OpenViking — строит контекстное пространство для агентов.
• ByteRover — превращает опыт в знания по проекту.
• MemPalace — хранит всё дословно и ищет потом.
• LLM Wiki — ведёт живую wiki, которую агент обновляет сам.

Ниже — как устроены, как подключаются к OpenClaw и для каких задач подходят.

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

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

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

И вот каждый подход отвечает на свой вопрос:

• Lossless Claw: главное — не потерять историю.
• OpenViking: нужно хранить всё контекстное пространство.
• ByteRover: ценность — в полезном знании, а не в архиве.
• MemPalace: не сокращайте память — храните всё и ищите.
• LLM Wiki: память — это живая, растущая wiki, а не архив.

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

Lossless Claw: память разговора без потерь

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

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

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

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

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

Типичные настройки:

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

Ограничение: это не база знаний команды и не универсальный контекст. Это — сильное решение для памяти сессии.

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

OpenViking: память как инфраструктура

OpenViking — это не просто модуль, а полноценная база контекста для агентов.

Он предлагает структурированную память, похожую на виртуальную файловую систему. Ресурсы, пользовательская память, навыки, сессионные данные — всё живёт в пространстве viking://....

Память здесь — не побочный эффект поиска, а самостоятельный слой платформы.

Сильные стороны:

• Разделение типов контекста.
• Уровни детализации: краткое описание, обзор, полные данные.
• Наблюдаемость: адресация, явные области поиска, инструменты отладки.

Это делает OpenViking ближе к инфраструктурному решению, чем к плагину.

Ставится сложнее:

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

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

С OpenClaw работает как нативный движок контекста. Пример настройки:

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

Минус: за широту — сложность. Если нужна только память диалога, он будет избыточен. Но если нужен контекстный слой уровня платформы — сильный кандидат.

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

ByteRover не стремится хранить всё и не претендует на универсальность. Его цель: превратить рабочие сессии в полезные знания.

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

В основе — дерево контекста в .brv/context-tree/. Знания раскладываются по доменам, темам, подтемам. Каждый файл — markdown с метаданными, фактами, описанием и связями. Строятся обзоры, сводки и индекс для запросов.

Сильная сторона — прозрачность. Память можно открыть, отредактировать, положить в Git, обсудить. Это важно для инженерной работы: когда память — чёрный ящик, ей быстро перестают доверять.

Рабочий цикл:

• Перед ответом — brv query ищет релевантные знания.
• После хода — brv curate обновляет или создаёт файлы знаний.

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

Поиск — поэтапный: сначала кэш, потом полнотекстовый, затем тяжёлые методы. Это инженерная дисциплина, а не постоянная нагрузка.

С OpenClaw работает как нативный движок. Две полезные особенности:

• Автоматический сброс знаний перед сжатием контекста — чтобы важное не исчезло.
• Ежедневная добыча знаний — задача по расписанию переносит из memory/ в долговременную базу то, что важно: причины багов, практики, решения.

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

Интеграция с OpenClaw:

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

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

MemPalace: дословное хранение и сильный поиск

MemPalace исходит из простой мысли: многие системы теряют ценность, когда решают, что именно запомнить. Исчезают причины, альтернативы, споры.

Решение: хранить разговоры дословно и делать ставку на поиск.

В базовом режиме — хранение в ChromaDB без сводок и извлечения. Такой подход дал 96.6% R@5 на LongMemEval — без внешних API и участия модели в хранении.

Это главный факт: дословное хранение + хороший поиск оказалось сильнее «умных» схем с предварительным извлечением.

Поверх архива строится иерархия — «дворец памяти»: крылья, комнаты, типы памяти, указатели, связи. Без образов — это структурированная адресация, фильтрация и навигация.

Установка:

Инициализация:

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

Поиск:

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

Авторы честно признали, что часть заявлений была завышена: слой AAAK не даёт чудес, «30-кратное сжатие» — преувеличение, некоторые функции — в разработке. Это скорее плюс: прозрачность.

С OpenClaw — особая история. MemPalace не выглядит нативным движком контекста. Логичнее воспринимать его как внешний слой памяти.

Практически: OpenClaw — основной агент, MemPalace — локальный архив, к которому агент обращается через инструменты или сервер.

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

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

LLM Wiki: память как живая wiki

LLM Wiki — не просто ещё одна система. Это отдельный подход, описанный Андреем Карпатым в заметке про personal knowledge bases с помощью LLM.

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

LLM Wiki предлагает иное: агент постепенно строит и поддерживает постоянную wiki из markdown-файлов — между источниками и ответами.

При добавлении нового материала модель не просто индексирует его. Она:

• обновляет страницы,
• правит связи,
• добавляет утверждения,
• отмечает противоречия,
• пересобирает обзоры.

Знание компилируется один раз и поддерживается — а не добывается заново при каждом запросе.

В git описана трёхслойная схема:

• сырые источники — неизменяемые;
• wiki — сгенерированные и поддерживаемые страницы;
• протокол — как вести wiki.

Это не retrieval. Это накопительный рабочий артефакт.

Почему это важно сейчас

Потому что OpenClaw в релизе v2026.4.7 вернул встроенный memory-wiki stack.

В нём:

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

LLM Wiki перестаёт быть практикой в Obsidian — он становится частью OpenClaw.

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

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

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

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

Там, где знание накапливается неделями и месяцами: исследования, конкурентный анализ, длительные проекты, личные и командные wiki.

Важно не просто найти, а иметь собранную, связанную и актуальную картину.

Появление memory-wiki stack — важный шаг. OpenClaw теперь поддерживает память как:

• историю сессий,
• поиск,
• поддерживаемый накопительный слой знания.

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

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

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

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

Главная сильная сторона, что запоминает, как работает с OpenClaw:

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

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

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

• Длинные сессии, не терять ход обсуждения — Lossless Claw.
• Контекстный слой уровня платформы — OpenViking.
• Агент как инженер, память как знание по коду и правилам — ByteRover.
• Локальная память без сокращения, не доверять модели выбор — MemPalace.
• Поддерживаемая wiki с утверждениями, проверкой, обновлением — LLM Wiki, особенно с встроенным memory-wiki stack в OpenClaw.

Рынок памяти для ИИ-агентов перестаёт сводиться к одному трюку.

• Память разговора — Lossless Claw.
• База контекста уровня платформы — OpenViking.
• Память проекта и кодовой базы — ByteRover.
• Локальный дословный архив с поиском — MemPalace.
• Накапливающаяся живая wiki — LLM Wiki / memory-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 внешний модуль памяти подключается какдвижок контекста. На уровне конфига это выглядит так:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Есть и дополнительные команды вроде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

Широкий контекстный слой

Память, ресурсы, навыки, служебные данные

Нативный движок контекста

Память проекта и команды

Решения, правила, наработки, знания по коду

Нативный движок контекста

Дословный архив и сильный поиск

Разговоры, выгрузки чатов, причинно-следственный контекст

Внешний слой памяти рядом с 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.

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

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

Lossless Claw

• GitHub:https://github.com/martian-engineering/lossless-claw

OpenViking

• GitHub:https://github.com/volcengine/OpenViking
• Пример интеграции с OpenClaw:https://github.com/volcengine/OpenViking/tree/main/examples/openclaw-plugin

• Документация:https://docs.byterover.dev/
• Интеграция с OpenClaw:https://docs.byterover.dev/autonomous-agents/openclaw
• Справка по настройке:https://docs.byterover.dev/autonomous-agents/openclaw-reference

• GitHub:https://github.com/milla-jovovich/mempalace
• Бенчмарки:https://github.com/milla-jovovich/mempalace/blob/main/benchmarks/BENCHMARKS.md

• Заметка Карпаты:https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
• Релиз OpenClawv2026.4.7:https://github.com/openclaw/openclaw/releases/tag/v2026.4.7

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

https://t.me/openclaw_lab