Память.
Заранее хочу отметить, что текущая вариация памяти — путь проб и ошибок длиною почти в месяц, он не претендует на право единственно-верной истины, но показывает отличные результаты (90% релевантности) и полностью удовлетворяет меня как постоянного пользователя, любящего не углубляться в контекст задачи самостоятельно, делегируя это механизму памяти.
Одно из главных отличий агентного подхода от обычного, сессионного — всё-таки память. В базовой инсталляции OpenClaw вы получаете систему, при которой в контекст постоянно подгружаются файлы со всеми знаниями агента, что в итоге ведёт к разжиранию потребления контекста, повышенному расходу токенов, спутанности сознания (информации много и она начинает путать LLM) и частым компакшенам, уменьшающим отзывчивость. Ну и в любом случае, когда-то это приведёт к тому, что пространства для новой памяти попросту не будет. Да и в целом, очевидно: когда общаешься с агентом по поводу билетов в Таиланд, ему абсолютно не важно знать о том, что обсуждалось на последнем созвоне.
Да, из коробки можно включить какие-то простенькие плагины, отдалённо напоминающие RAG-память, но к более качественным, погружённым в контекст ответам это не приводит — лишь так же забивает контекстное окно алгоритмическим бредом.
В связи с этим и было решено построить новую, вместительную, а самое главное полезную память, состоящую из:
ChromaDB для хранения эмбеддингов, qwen3-embedding:8b за потрясающую возможность развернуть локальную модель с превосходным MTEB на русский язык, и дешёвая, но очень быстрая и умная модель от Anthropic — Haiku 4.5.
Далее был построен пайплайн наполнения ChromaDB, где сырые диалоги и сообщения обрабатывались Haiku, обогащались различными метаданными (участвующие лица, время, тип, важность и т.п.), из них выделялась суть и тейки, а потом сквозь эмбеддинги отправлялось на хранение в базу. На этом этапе очень важно уделить внимание конкретно качеству данных, которыми будет заполняться база, ведь если это будет просто обычный диалоговый мусор, то в будущем это никак не поможет модели при ответах, а вероятно и вовсе ухудшит их.
После того, как со временем у нас набралось достаточное количество различных данных, я приступил к написанию пайплайна обогащения запросов дополнительным контекстом из памяти. Суть его заключается в том, чтобы перед тем как передавать сообщение основной модели, оно идёт в набор скриптов, который в свою очередь с помощью Haiku расширяет запрос, учитывая общий контекст ( http://MEMORY.MD/, http://SOUL.MD/, последние 10 сообщений в сессии, глоссарий), дабы избежать vocabulary mismatch, общую потерю смысла и вычленить из него temporal awareness (что было вчера? → since: 2026-03-03), прогоняет через модель эмбеддингов и отправляет его в ChromaDB.
Полученный ответ от базы подвергается time decay (с разной скоростью у разных категорий), взвешиванию на основе категории воспоминаний и реранкингу, далее это всё прогоняется через Haiku, убирающего шум и оставляющего только действительно релевантные ответы — и уже посредством плагина подставляется к основному сообщению.
В итоге получилась система, которая не просто хранит информацию, а действительно умеет её доставать в нужный момент и в нужном объёме — не перегружая контекст и не путая модель. 90% релевантности на практике — это не магия, а следствие внимания к каждому звену цепочки: качеству данных на входе, грамотному расширению запроса и аккуратному реранкингу на выходе.
Повторюсь: это не единственно верный путь, но рабочий. Если у вас похожая задача — надеюсь, что хотя бы часть из описанного сэкономит вам этот месяц проб и ошибок. Фидбек можно выразить реакциями или комментариями.
