Память агента: четыре слоя, которые я собирал методом ошибок

Когда говорят "добавим агенту память" - почти всегда имеют в виду что-то одно. Либо историю диалогов в контексте, либо векторную базу куда грузится "всё". И почти всегда это работает хуже чем ожидали: агент либо не помнит ничего между сессиями, либо тащит за собой горы нерелевантного контекста.

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

В этом посте - полная картина: классификация из когнитивных наук, что конкретно предлагают Anthropic, MemGPT и mem0, почему Postgres + pgvector, и архитектура которую я строю сейчас. Плюс один инсайт в конце который меняет взгляд на весь подход.

Почему одна "векторная база" не решает проблему

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

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

Альтернатива - грузить всё в контекст - тоже не работает. Full-context подход набирает лучшие баллы в изолированных бенчмарках, но в реальном проде нежизнеспособен. Одна сессия съедает ~26 000 токенов против ~1 800 при умном retrieval. Латентность p95 - 17 секунд против 1.4 секунды. И при этом у моделей развивается "context rot": когда объём window превышает определённый порог, модель начинает игнорировать части контекста. Вы туда всё положили, но агент туда не смотрит.

Пять типов памяти: откуда берётся классификация

Разделение пришло из когнитивных наук - именно оттуда его взяла научная работа CoALA (Cognitive Architectures for Language Agents, 2023), которая стала основой для большинства современных фреймворков агентной памяти.

Люди используют несколько принципиально разных систем памяти. Агент устроен аналогично - и попытка свести всё к одному хранилищу создаёт те же проблемы, что возникли бы если бы у человека была только долгосрочная эпизодическая память и не было бы рабочей.

Рабочая память - это "RAM" агента. Всё что прямо сейчас в context window: текущая задача, последние сообщения, инструкции этой сессии. Сбрасывается между сессиями. Никаких специальных технологий - просто промпт.

Эпизодическая память - личная история агента. Что делали на прошлой неделе, какие решения принимали, что попробовали и что сработало. Помогает не начинать с нуля в каждой сессии. Технически: база диалогов, conversation history с поисковым доступом. MemGPT называет это "recall memory".

Семантическая память - структурированные факты и знания. Не "что мы делали", а "как оно устроено". Доменные знания агента: документация, описания инструментов, концепты. Именно здесь своё место у RAG и embeddings - семантический поиск по смыслу. Технологии: pgvector, Pinecone, Qdrant, Weaviate, Chroma.

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

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

Что предлагает Anthropic: прозрачность против сложности

В сентябре 2025 года Anthropic выкатил официальный Memory Tool для Claude. И сделал неожиданный выбор: вместо сложной RAG-системы с векторными embeddings - обычные Markdown-файлы.

Память хранится в директории /memory как текстовые файлы. Агент создаёт, читает, обновляет и удаляет их через tool calls. В Claude Code это файлы CLAUDE.md в проекте и домашней директории. Всё прозрачно: открыл файл - увидел что агент помнит. Отредактировал вручную - изменил его память.

Это принципиальная позиция Anthropic: прозрачность важнее оптимальности. Разработчик полностью контролирует где и как хранится память. Нет скрытой магии, нет чёрного ящика embeddings. Memory tool работает client-side: агент делает tool call, приложение выполняет операцию локально.

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

Что предлагает MemGPT: операционная система для памяти

MemGPT (сейчас развивается как фреймворк Letta) решает ту же задачу через аналогию с операционными системами. Классическая ОС управляет ограниченной RAM через виртуальную память и paging. MemGPT делает то же с context window.

Три уровня памяти:

Core memory - всегда в контексте. Persona агента, ключевая информация о пользователе, текущий статус. Маленький, стабильный блок который никогда не вытесняется.

Recall memory - история разговоров с поисковым доступом. Когда context window заполняется, MemGPT не отбрасывает старые сообщения - делает рекурсивный summary и отправляет в recall memory. Данные уходят "на диск", но остаются доступными через поиск.

Archival memory - неограниченное внешнее хранилище. Документы, базы знаний, всё что не влезает в контекст. Агент явно вызывает поиск когда нужно.

Агент сам решает что хранить, что выгружать и что подтягивать - через function calls с request_heartbeat=true для продолжения цепочки без вмешательства пользователя. Это позволяет выполнять многошаговый retrieval: искать, читать, связывать с контекстом, искать ещё.

На бенчмарке LOCOMO MemGPT-подход показывает кратное преимущество над fixed-context решениями именно на длинных многосессионных задачах - там где агент должен помнить что было неделю назад и связывать это с текущей задачей.

Почему mem0 выбрал Postgres + pgvector

Это прагматичный архитектурный выбор, который нравится не всем - но у него есть чёткая логика.

Проблема с отдельной векторной базой. Если у тебя Postgres для основных данных и Pinecone или Qdrant для embeddings - ты получаешь две инфраструктуры которые нужно синхронизировать. Данные агента живут в Postgres, векторы - в векторной базе. Когда что-то меняется в основных данных, нужно обновлять embeddings отдельно. Отдельный backup, отдельный мониторинг, отдельный деплой, отдельный сбой.

Что даёт pgvector:

Один стек. Реляционные данные и векторные embeddings в одной базе. Те же инструменты мониторинга, те же backup-процедуры, та же схема HA. Нет ещё одного рантайма который нужно поднимать и тюнить.

ACID-транзакции. Когда агент сохраняет что-то в память, транзакция атомарна. Не получится состояния когда структурированные данные обновились, а embeddings нет.

JOIN в одном запросе. Память агента можно джойнить с другими таблицами приложения. Например: найти похожие прошлые задачи и одновременно проверить их статус в основной базе - всё в одном SQL-запросе.

Фильтрация + семантический поиск вместе. WHERE user_id = X AND project = 'Y' ORDER BY embedding <-> $query_embedding LIMIT 10 - фильтр по структурированным полям и семантический поиск работают вместе. В отдельной векторной базе это обычно post-filtering со своими edge cases.

Ограничения pgvector. Index build memory-intensive - при активной перестройке индекса на продакшн-базе это проблема. Filtering complexity: при плохой избирательности фильтров разница между pre-filter и post-filter может быть разницей между 50ms и 5 секундами. При миллиардах векторов специализированные базы (Qdrant, Weaviate) дадут лучшую производительность.

Практическое правило. pgvector - до десятков миллионов векторов, если Postgres уже в стеке. Выделенная база - при очень большом масштабе или специфических требованиях к производительности ANN.

Именно поэтому mem0 выбрал Postgres как дефолтный бэкенд: для большинства production-систем это pragmatic win. Один стек, быстрый старт, понятная экосистема.

Мой опыт: что работает в реальной системе

Я строю агентов несколько лет. У меня сейчас три агента в проде: DevOps-агент держит инфру и CI/CD, сайт-агент пишет код и деплоит, SMM-агент занимается контентом. Все три на своём железе, суммарно ~$200/мес. Вот что я обнаружил на практике.

Гибридная схема которую я использую

Я не выбирал между "держать всё в промпте" и "грузить из векторки". Я пришёл к гибридной схеме. Есть короткий in-context слой: роль агента, текущая задача, базовые правила работы, ссылки на нужные capability и описание доступных инструментов. Поверх этого - внешняя память через mem0, откуда в момент работы подтягивается релевантный контекст.

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

Главная проблема оказалась не там где ожидал

Я думал, что основная проблема - агент "забывает" что было между сессиями. Но на практике это оказалось не так. Основная проблема - не в том, что агент совсем ничего не помнит. А в том, что он не всегда подтягивает нужный слой контекста в нужный момент.

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

Проблема не в хранилище - проблема в retrieval strategy.

Just-in-time против наперёд

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

Сейчас у меня это частично реализовано через retrieval. Следующий шаг - сделать этот слой более явным через ссылки на wiki и карточки знаний, чтобы агент сначала шёл по маршруту, а не тащил всё наперёд.

Это совпадает с тем что описывает Anthropic как "just in time retrieval": тащить контекст только когда нужен, а не грузить всё на старте.

Поведение важнее фактов

Если приходится выбирать что важнее - помнить что было сделано или помнить как делать - ответ однозначный: важнее поведение.

Факты полезны для continuity: что уже пробовали, какие были решения, что уже известно. Но именно поведенческая память определяет качество агента как системы: как он должен искать информацию, как принимать решения, в каком порядке проверять гипотезы, когда идти в tool, когда идти в knowledge base, когда не доверять старому контексту.

Факты отвечают за историю. Поведение - за воспроизводимое качество.

Разница между разовым и постоянным агентом

Это важное архитектурное разделение которое часто игнорируют.

Одноразовому агенту (задача → результат) память нужна в основном как task context: дать ему всё нужное на вход, провести через задачу, получить результат. Там можно жить довольно просто: хороший промпт, несколько документов, maybe retrieval по ходу работы.

У постоянно живущего агента появляется совсем другой класс задач: continuity, накопление опыта, обновление знаний, сохранение предпочтений, борьба с устареванием и конфликтом данных. Поэтому у long-lived агента архитектура памяти должна быть многослойной: оперативный контекст, долговременная память, источник истины, правила обновления и извлечения.

Иначе он либо всё забывает, либо начинает тащить за собой мусор.

Векторный поиск: где работает и где нет

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

Но как источник истины она неидеальна. Если нужна актуальная, проверяемая, каноническая инструкция - векторный поиск может переусложнять: он возвращает похожее, а не обязательно правильное и актуальное. Для facts-of-record и runbooks лучше работает структурированный knowledge layer.

Простое правило: вектор = recall, структурированное = source of truth.

Граница: системный промпт против базы

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

В промпте: роль, приоритеты, стиль принятия решений, правила безопасности, схема tool use, навигационные указатели.

В базе: знания о проектах, инструментах, runbooks, детали интеграций, история решений, карточки сущностей, доменные инструкции.

То есть prompt - это "как работать", а база - "с чем работать".

Четыре слоя: архитектура которая работает

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

Слой 1 - Оперативный: минимальный промпт с ролью, текущей задачей и навигационными указателями. 1-5K токенов. Принципиально: здесь не знания, а адреса где знания лежат.

Слой 2 - Навигационный: "карта мира" агента. Не содержимое, а указатели. Где лежит описание Bitbucket, где runbooks, где шаблоны действий, когда какой источник приоритетнее. Агент загружает эту карту один раз и потом ходит по адресам.

Слой 3 - Долгосрочная память: mem0 поверх Postgres + pgvector. Эпизодическая + частично семантическая память. Что делали раньше, предпочтения, decisions. Для ассоциативного recall: "мы же что-то похожее делали".

Слой 4 - Источник истины: типизированные карточки знаний. Самый важный слой для production-систем.

Навигационный слой: новый подход которому нет года

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

Это write-then-read через структурированное хранилище - а не RAG на сырых данных.

Идея: агент не просто "хранит память" - он публикует знания в формате который могут читать другие агенты и люди. Каждая выполненная задача - потенциальный вклад в базу знаний команды.

Практически это выглядит так:

Промпт DevOps-агента:
"Ты DevOps-агент.
Для общих принципов: capability cards.
Для инструментов: tool cards (tool/bitbucket, tool/kubernetes).
Для процедур: сначала runbook.
Если last_verified_at карточки > 30 дней: ищи более свежий источник.
После выполнения задачи: обнови agent_notes в релевантной карточке."

Агент не загружает всё заранее. Он идёт по маршруту. Это работает принципиально иначе.

Typed knowledge cards: структура которая делает wiki полезной

Просто "сходи в wiki" не работает. Нужна типизация. Разные типы карточек для разных типов знаний:

tool/bitbucket
tool/kubernetes
service/deploy-pipeline
runbook/restart-service
policy/prod-access
project/zinovev-org
person/team-responsibilities

У каждой карточки единый шаблон:

• Что это - одно предложение
• Когда использовать - конкретные сценарии
• Ограничения - что нельзя или когда не работает
• Частые ошибки - из реального опыта
• Связанные сущности - ссылки на другие карточки
• last_verified_at - дата последней проверки актуальности
• owner - кто отвечает за актуальность
• Ссылки на первоисточники - документация, репозитории

Это не граф-база данных. Это "граф на уровне ссылок и карточек". Агент переходит по связям, обновляет куски локально, проверяет last_verified_at. Практический эффект почти тот же что у graph RAG - без инфраструктурной сложности.

Что агент обновляет сам и что нет

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

Агент может обновлять самостоятельно:

• Добавлять новые наблюдения из работы
• Пополнять примеры использования
• Обновлять usage notes
• Проставлять last_seen / last_checked
• Создавать черновики новых карточек
• Связывать карточки между собой

Агент НЕ должен молча менять:

• Канонические production-инструкции
• Security policy
• Критические runbooks
• Доступы и разрешения
• Любой canonical section без подтверждения человека

Практическое решение: у каждой карточки есть два раздела - canonical section (только через подтверждение) и agent notes / proposed updates (агент пишет сам). Агент полезен, но не ломает базу знаний.

Ключевое сравнение: Anthropic vs Confluence-подход

Здесь самый важный инсайт, к которому я пришёл.

Anthropic хранит память в локальных CLAUDE.md файлах на машине разработчика. Прозрачно, просто, под контролем. Отлично работает для одного человека с локальным агентом.

Но если есть команда? Если несколько агентов? Если знания должны быть общими, проверяться людьми, версионироваться?

Подход с Confluence/wiki:

Знания хранятся там где живёт компетенция команды - в wiki, где у людей есть доступ, где они правят, где они валидируют. Агент читает из того же места что и люди. Люди видят что агент "знает". Если информация устарела - человек обновляет карточку и агент сразу работает с актуальными данными.

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

Сравнение подходов:

Это не противоречие - это разные задачи. Anthropic делает хорошо для персонального агента. Для командных систем с несколькими агентами - wiki с типизированными карточками даёт лучшую управляемость.

Итоговая формула

Я бы сформулировал это так:

в памяти (mem0)    → что сейчас важно, прошлый опыт, preferences
в векторке         → что может быть полезно вспомнить (recall)
в wiki / карточках → что считается актуальным знанием (source of truth)
в навигации        → как до этого знания добраться (routing)
в правилах агента  → когда что читать, когда чему доверять

Это не "RAG плюс память". Это рабочая память + knowledge routing + governed source of truth.

Разница принципиальная: агент не просто хранит. Он знает как пользоваться тем что хранит.

Следующий шаг у любого кто строит production-агентов - не "ещё одно хранилище", а нормальный knowledge router поверх карточек и источников. Три вещи которые стоит проработать прямо сейчас: формат карточек, политику доверия, и правила извлечения.