Persistent Memory:
как агент
помнит контекст
Модель помнит только окно контекста. Runtime помнит недели. Разница между «умным чатом» и agentic-системой — не в размере prompt, а в том, что происходит между сессиями: что записать, что подтянуть, что забыть.
Почему контекстного окна мало
LLM видит только то, что вы положили в prompt прямо сейчас. Даже 200K токенов — это не память, а временная доска: закрыли чат — доска стёрлась. Агент, который вчера договорился с клиентом, сегодня не помнит дедлайн, если вы не перескажете всё заново.
Persistent memory — слой runtime, который переживает сессию: решает, что сохранить, как найти релевантное и когда не мешать модели устаревшим фактом.
Три типа долгосрочной памяти
-
01
Vector / semantic Embeddings + поиск по смыслу. Хорош для документов, заметок, «похожих кейсов». Плох, когда нужна точная структура или актуальность по дате.
-
02
Episodic Хронология событий: «что делали в прошлый вторник». Логи сессий, day monitor, timeline решений. Нужен для continuity и аудита.
-
03
Structured Таблицы, реестры, typed records: задачи, клиенты, правила. Предсказуемые поля, фильтры, статусы. Самый надёжный для операционки.
На практике работает hybrid: structured — источник правды, vector — для fuzzy-поиска по тексту, episodic — для «что менялось и когда».
Как это устроено в AIOS
В Intelligence Runtime IRI Lab память не свалена в один RAG-бucket. Два реестра разделяют ответственность:
MEMORY_REGISTRY — устойчивые факты, решения, протоколы (MEM-XXX). TYPE: decision / rule / knowledge / protocol. Не пишем рабочий шум — только то, что должно пережить месяцы.
TASK_REGISTRY — оперативная память действий (LOS-XXX, BOS-XXX). Статусы OPEN → IN_PROGRESS → DONE. Агент знает, что не закрыто, без пересказа всей истории чата.
Скиллы с CHAT_NAME синхронизируют контекст через skill_context.py: последний NEXT_STEP, открытые задачи, память контура. Модель получает сжатый срез structured + episodic, а не сырой дамп всех файлов.
Цикл записи
1. Сессия → значимое решение или факт → проверка дублей по TOPIC → запись в MEMORY_REGISTRY.
2. Задача с ID → TASK_REGISTRY → статус меняется по ходу работы, не в чате.
3. Следующий старт скилла → контекст подтягивается автоматически, prompt остаётся коротким.
Когда память вредит
Больше памяти ≠ умнее агент. Типичные антипаттерны:
- Dump everything — в vector кладут весь чат; retrieval тащит противоречия и устаревшее.
- Нет TTL и статусов — правило отменили, но MEM-запись active; агент следует мёртвому протоколу.
- Один слой на всё — задачи клиента в том же индексе, что и общие знания; privacy и precision ломаются.
- Память вместо контракта — «агент помнит» без TASK_REGISTRY; после сбоя восстановить нельзя.
Хорошая эвристика: если запись нельзя однозначно найти по ID или полю — это не structured memory, а мусор с отложенным багом.
Vector vs structured: что выбрать
Vector — когда вопрос формулируется естественным языком и ответ «где-то в текстах»: база знаний, документация, архив переписки.
Structured — когда нужны статус, владелец, дедлайн, связь с сущностью: задачи, клиенты, биллинг, конфиг runtime.
Episodic — когда важна линия времени: «что меняли на прошлой неделе», монитор дня, post-mortem после инцидента.
Память в стеке IRI Lab
Gateway даёт доступ к моделям. Runtime даёт им continuity: MEMORY_REGISTRY + TASK_REGISTRY + оркестраторы (/los-personal, /bos-boss, /ai-lab) не дают интelligence распасться на изолированные чаты.
Agentic-система без persistent memory — это дорогой autocomplete с amnesia. С памятью — операционная система, где каждая сессия продолжает предыдущую, а не начинает с нуля.
Дальше по стеку
Следующий слой — Task Registry как память задач между сессиями. Базовый runtime: что такое Intelligence Runtime. Вопросы по архитектуре — форма связи.