memory-systems

Memory System Design — навык для проектирования постоянной памяти агентных систем: сохранения знаний между сессиями, отслеживания сущностей, проверки временной актуальности, консолидации и выбора retrieval-подхода или benchmark. Его центральная идея — начинать с самого простого слоя, который действительно закрывает потребность. Обычному агенту не обязательно сразу строить temporal knowledge graph: сначала проверяют, насколько надёжно извлекаются нужные факты, и усложняют архитектуру только при измеримом ухудшении качества или при необходимости многошагового обхода связей и запросов «на дату». Материал рассматривает несколько вариантов. Mem0 описан как векторная и графовая память с подключаемыми backend для multi-tenant-систем и широких интеграций. Zep/Graphiti ориентирован на temporal knowledge graph и bi-temporal model, когда важны отношения и время события и его поступления. Letta предлагает редактируемую память с уровнями in-context, core и archival для интроспекции состояния агента. Cognee строит многослойный semantic graph с настраиваемым ingestion, выделением сущностей, post-processing и retrieval. LangMem подходит командам, уже работающим с LangGraph, а файловая память остаётся вариантом для простых агентов и прототипов. Выбор делается по форме поиска и требованиям к данным, а не по бренду инструмента. Для принятия решения выделены слои памяти: working хранит состояние только в окне контекста; short-term подходит для сессионных файлов или in-memory состояния; long-term сохраняет знания между сессиями; entity помогает не путать одну сущность между разговорами; temporal KG хранит интервалы валидности и историю изменений. Стратегию retrieval нужно подбирать к вопросу: semantic search удобен для прямого факта, entity-based traversal — для обхода всего, что связано с объектом, temporal filtering — для меняющихся фактов, а hybrid сочетает семантический, ключевой и графовый поиск ценой большей инфраструктуры. Рекомендуемый практический путь — файловый JSON с временными метками для прототипа, затем vector store с metadata при необходимости semantic search и multi-tenant-изоляции, затем Graphiti или Cognee для отношений, временной валидности и multi-hop reasoning. Навык отдельно описывает эксплуатационные риски. Память следует загружать just-in-time, а не целиком помещать в prompt; релевантные результаты стоит размещать в позициях, где контекст лучше удерживает внимание. При пустой выдаче сначала расширяют поиск, при устаревших результатах проверяют valid_until и запускают консолидацию, при конфликте фактов сравнивают valid_from и показывают конфликт при низкой уверенности, а сбой хранения ставят на повторную запись, не блокируя ответ агента. Консолидация нужна из-за неограниченного роста: старые сведения следует инвалидировать, но не бездумно удалять, если история нужна для запросов во времени. Для оценки приводятся LoCoMo, LongMemEval, DMR и другие benchmark-сигналы, однако их нельзя превращать в вечный рейтинг: числа нужно перепроверять по исходным исследованиям. Ограничение карточки в том, что она задаёт архитектурные критерии и recovery-практики, но не выбирает backend без требований конкретного продукта, не гарантирует качество retrieval и не заменяет нагрузочный или privacy-аудит.