Компоненты памяти агента (Extractor / Store / Retriever)

Любая система "памяти" агента, как бы её ни брендировали терминами из когнитивных наук, состоит из трёх последовательных компонентов: extractor преобразует диалоги в утверждения, store их хранит, а retriever возвращает релевантные данные обратно в контекст. Ценность такой декомпозиции в том, что на каждом уровне есть ровно одно по-настоящему сложное решение, тогда как маркетинг обычно рассуждает совсем не о том слое, в котором возникает сбой. Эта страница выделяет данную структуру из agent-memory-anatomy, чтобы другие страницы могли ссылаться на неё напрямую.

Extractor - решение по таймингу

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

Нетерпеливое извлечение (eager extraction) срабатывает на каждое сообщение. Память остаётся актуальной, и её не нужно сворачивать из огромного накопившегося хвоста, но приходится платить за вызов LLM на каждом шаге и фиксировать утверждения до того, как завершится ветка обсуждения: система может сохранить гипотезу, которую следующее же сообщение опровергнет. Ленивое извлечение (lazy extraction) запускается в конце сессии. Оно дешевле и видит диалог целиком, поэтому может извлекать выводы, а не догадки. Его уязвимость - длина контекста: длинный транскрипт приводит к деградации lost-in-the-middle, когда модель обращает внимание на начало и конец, теряя середину. Ни один из вариантов не даётся бесплатно, и этот выбор - реальный компромисс, а не решённый вопрос.

Store - решение по противоречиям

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

Здесь есть три пути. Перезапись (overwrite) заменяет старый факт - это аккуратно, но уничтожает историю, позволяющую системе ответить на вопрос "во что я верил месяц назад?". Добавление (append) сохраняет оба факта без потерь, но теперь выборка возвращает устаревшие и актуальные данные вперемешку, если только что-то явно не помечает их статус. Замещение (supersede) - промежуточный вариант: старое утверждение сохраняется, помечается устаревшим и связывается ссылкой с новым. Замещение - единственный подход, который сохраняет аудит без засорения выдачи, но и реализовать его сложнее всего. Это проблема memory-conflict-detection, и именно в этот уровень большинство библиотек вкладывает меньше всего усилий.

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

Retriever - качество по мере роста хранилища

Retriever - это RAG по накопленным утверждениям: векторное сходство, поиск по ключевым словам, реранкер поверх них, плюс фильтры по времени и проверки пресуппозиций (не опирается ли запрос неявно на факт, которому хранилище теперь противоречит?). Важно понимать: по мере роста хранилища деградирует именно извлечение (retrieval), а не хранение (storage). Десять утверждений искать тривиально, сто тысяч - нет. Нужные факты по-прежнему внутри; проблема в том, чтобы найти их среди дубликатов и устаревших версий. Вот почему тезис "просто сохраняйте всё, диск дешёвый" верен в отношении хранилища, но неполон для системы в целом: хранить всё подряд допустимо лишь тогда, когда retriever и логика замещения в store способны стабильно находить актуальный ответ. См. ai-cannot-forget-forgive о том, почему ответом является улучшение поиска, а не удаление, и agent-memory-decay о подходе с сигналами затухания, закладывающем свежесть в ранжирование.

Главный тезис: в итоге вы построили автобиографическую семантическую память

Все три компонента вместе формируют один конкретный вид памяти, независимо от таксономии на упаковке. Extractor сжимает эпизоды в факты, отбрасывая "когда и где", которые делали бы их эпизодическими. Процедурная память - изменение того, как агент действует - требует механизма, которого в связке store-and-retrieve попросту нет; тег memory_type="procedural" на векторной строке - это метка, а не процедурная память. Проспективной памяти (сделать Y, когда в следующий раз появится X) в этой схеме нет вовсе. Если вычесть эпизодическую, процедурную и проспективную, остаётся семантическая память о собственном прошлом агента. Это и есть автобиографическая семантическая память, и называть её так честнее, чем использовать четырёхчастную когнитивную таксономию из рекламы библиотек. agent-memory-strategy-decision-tree служит практическим дополнением: для каждой категории информации там показано, за каким уровнем она должна быть закреплена.

Один вариант реализации уровня хранилища стоит упомянуть отдельно: ряд продуктов 2026 года хранит память в виде обычных Markdown-страниц вместо векторных строк, чтобы содержимое можно было читать, править вручную и смотреть через diff. llm-wiki-as-agent-memory разбирает этот компромисс: проверяемость и переносимость в обмен на регулярную уборку и структурирование, поскольку Markdown-хранилище противоречит само себе явно, тогда как векторное хранилище просто начинает хуже выдавать результаты.

Связанные страницы

• agent-memory-anatomy - исходное эссе, из которого выделена эта концепция
• llm-wiki-as-agent-memory - Markdown-вики как ответ на вопрос об организации хранилища
• agent-memory-decay - свежесть и консолидация как сигналы при поиске
• agent-memory-strategy-decision-tree - выбор уровня для каждого типа фактов
• memory-conflict-detection - детальный разбор проблемы противоречий в хранилище
• ai-cannot-forget-forgive - почему забывание - неподходящий инструмент
• memorizing-session-transcripts - отрицательный результат: отсутствие измеримой пользы от поиска агентов по собственным транскриптам, а также аргумент о том, что автоматическое запоминание добавляет мусорный контекст и размывает намерения. Материал направлен на поиск по тексту транскрипта через индекс сходства, а не на связку extractor/store/retriever с этой страницы, но представляет собой сильнейший аргумент против создания такого пайплайна в принципе