Agent Memory и RAG: как выбрать архитектуру в 2026

По данным исходной работы о RAG, опубликованной в 2020 году, архитектура объединяет языковую модель с внешней непараметрической памятью, доступной через поиск. Это уже подсказывает правильный выбор: RAG отвечает за внешние знания, а Agent Memory — за сохранение пользователя, диалога и состояния задачи. Для большинства долгоживущих AI Agent нужен не один универсальный индекс, а двухконтурная схема с разными правилами записи, доказательствами происхождения и удалением данных. (исходная статья о RAG) (arxiv.org)

Эта статья предназначена для разработчиков, которые строят агентов поддержки клиентов, персональных помощников, кодирующих агентов и многошаговых систем. Она также пригодится командам, уже использующим корпоративный RAG, но не уверенным, можно ли на его базе реализовать долгосрочную память.

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

Последнее обновление — 10 августа 2026 года. Сведения о TencentDB-Agent-Memory сверены с официальным README, конфигурационными файлами и журналом изменений проекта; конкретные параметры следует перепроверять перед развёртыванием.

Данные и границы ответственности

Главная ошибка — отправлять документы, пользовательские предпочтения, историю действий и текущую задачу в одну и ту же векторную базу. Технически это возможно, но ответственность за обновление становится неясной.

RAG обычно получает данные извне: инструкции, регламенты, технические статьи, каталоги, тикеты, базы знаний и другие материалы, на которые агент должен ссылаться при ответе. Его основной вопрос звучит так: «Какой фрагмент внешнего источника нужен для ответа сейчас?»

Agent Memory работает с другой категорией информации:

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

Входом для RAG является документ или коллекция документов. Выходом — найденные фрагменты с источником, версией и правами доступа. Входом для Memory является событие взаимодействия, результат действия, обратная связь или изменение состояния. Выходом — компактный факт, эпизод, профиль, план или связанный с задачей контекст.

Именно поэтому Agent Memory и векторная база данных — не одно и то же. Векторная база данных — это способ хранения и поиска. Memory — это прикладной слой, который решает, что считать воспоминанием, когда его записывать, как объединять дубликаты, как исправлять противоречия и кому разрешено его видеть.

RAG тоже не ограничен только статичными PDF-файлами. Индекс может обновляться, использовать гибридный поиск, фильтры по времени и правам, а также обращаться к живым источникам. Но его жизненный цикл обычно определяется процессом загрузки и публикации знания, тогда как Memory должна реагировать на события самого агента.

Нужно ли сохранять всю историю диалогов AI Agent?

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

1. исходные сообщения и результаты инструментов;
2. краткие сводки текущей сессии;
3. отобранные долговременные факты и состояния.

Если сохранять каждую реплику как «важное воспоминание», поиск быстро начинает возвращать случайные фразы, временные намерения и устаревшие планы. Если же удалять исходные события сразу после суммаризации, вы теряете возможность доказать, откуда появился спорный факт.

Официальный README TencentDB-Agent-Memory описывает именно многоуровневый подход: от исходных материалов и промежуточных сводок к компактному представлению состояния, с возможностью вернуться к нижнему уровню по идентификатору узла. Это полезная модель для производства, поскольку сжатие не должно уничтожать исходное доказательство. (README TencentDB-Agent-Memory) (github.com)

Запись и обновление

RAG чаще всего записывается через явный конвейер:

1. получить документ;
2. проверить формат и права;
3. разбить материал на фрагменты;
4. добавить метаданные;
5. построить представления для поиска;
6. опубликовать новую версию;
7. удалить или пометить старые фрагменты.

Для Memory такой конвейер недостаточен. Агент должен постоянно решать, является ли событие временным или долговременным. Например, фраза «сегодня мне нужен краткий ответ» не равна устойчивому предпочтению пользователя. Сообщение «всегда отвечайте в формате JSON» уже может быть долговременным правилом, но только если его область действия подтверждена.

На практике применяются два режима:

• синхронное формирование — память извлекается до ответа или сразу после события;
• фоновое формирование — отдельный процесс анализирует историю и обновляет память позднее.

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

Концептуальные руководства по долгосрочной памяти выделяют семантические факты, эпизодический опыт и процедурные правила. Такая классификация полезнее, чем простая метка «текст для векторного поиска», потому что для каждой категории нужны разные способы обновления. (руководство по типам памяти) (docs.langchain.com)

Ошибки обновления

У Memory есть четыре проблемы, которые нельзя решать теми же правилами, что и загрузку документов:

• конфликт — пользователь сначала указал один стек, а затем перешёл на другой;
• устаревание — временный план ошибочно остался постоянным;
• дублирование — один факт записан после каждой похожей реплики;
• ошибочное извлечение — модель неверно поняла сарказм, гипотезу или цитату.

Правило «последняя запись всегда главнее» слишком грубое. Последнее сообщение может быть ошибкой. Лучше хранить источник, время, область действия, уверенность и статус подтверждения. При конфликте агент должен либо выбрать более свежий подтверждённый факт, либо запросить уточнение.

TencentDB-Agent-Memory следует проверять именно по этим сценариям, а не только по успешному сохранению одной фразы. В журнале изменений и конфигурации проекта нужно отдельно смотреть, какие уровни памяти, локальные хранилища и варианты бэкенда поддерживаются текущей версией. (журнал изменений проекта)

Метрики выбора: поиск, доказательства и стоимость ошибки

RAG оптимизируется под релевантность внешнего источника. Здесь важны полнота поиска, точность найденных фрагментов, фильтрация по правам, свежесть версии и наличие ссылки на первоисточник.

Memory оптимизируется под полезность контекста для продолжения работы. Важны корректность профиля пользователя, восстановление состояния задачи, отсутствие межпользовательской утечки, устойчивость после перезапуска и возможность объяснить происхождение факта.

В RAG ссылка на источник часто является частью ответа. В Memory доказательство может не показываться пользователю, но обязано сохраняться для оператора. Если агент говорит: «Вы уже согласовали миграцию», команда должна найти событие, на котором основан этот вывод.

В этом отношении многоуровневое и трассируемое представление TencentDB-Agent-Memory полезно как архитектурный ориентир: компактный слой используется для работы агента, а исходные данные остаются доступными для проверки. Это не отменяет собственный аудит, но задаёт правильное требование — каждый важный факт должен иметь путь назад к первоисточнику. (описание слоёв и трассировки) (github.com)

Как отслеживать ошибочный вызов долгосрочной памяти?

Сохраняйте не только текст найденного факта, но и технический конверт:

• идентификатор пользователя или организации;
• идентификатор сессии и задачи;
• версию памяти;
• время создания и последнего обновления;
• причину записи;
• уровень уверенности;
• список исходных событий;
• идентификатор операции поиска;
• решение маршрутизатора: почему память была добавлена в контекст.

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

Политики приватности и удаления

Для RAG и Memory нельзя использовать одну политику доступа по умолчанию.

Документная база обычно проверяется по владельцу документа, роли сотрудника, проекту, отделу или уровню конфиденциальности. Пользовательская память должна дополнительно учитывать владельца профиля, организацию, рабочее пространство, конкретного агента и иногда отдельную задачу.

Минимальная схема изоляции выглядит так:

пространство организации
  └── пользователь
      └── агент
          └── проект
              └── сессия и задача

Такая иерархия не является готовой гарантией безопасности. Её нужно проверять на уровне запросов, индексов, файлов, резервных копий и журналов. Локальное развёртывание может сократить путь передачи данных во внешние сервисы, но само по себе не означает соблюдение требований к защите данных. Остаются вопросы шифрования, управления ключами, резервного копирования, доступа операторов и удаления из всех копий.

Для каждого слоя заранее задайте:

1. срок хранения исходных событий;
2. срок хранения производных сводок;
3. условия повышения факта до долгосрочной памяти;
4. процедуру исправления;
5. процедуру удаления;
6. способ проверки, что удаление распространилось на кэш, индекс и резервные копии.

Если пользователь просит удалить свои данные, недостаточно убрать одну запись из векторного индекса. Нужно определить, какие сводки, связи, кэши и резервные копии были построены на её основе. Для критичных систем полезно хранить происхождение производных объектов, чтобы удаление можно было проверить автоматически.

Условия выбора архитектуры

Используйте следующие ветвления до того, как покупать или разворачивать дополнительный слой хранения:

• Если агент отвечает на разовые вопросы по регламентам, документации или каталогу, выбирайте RAG. Добавляйте фильтры доступа, версии документов и ссылки на источники.
• Если агент должен помнить пользователя между сессиями, добавляйте Agent Memory. Не превращайте всю историю в постоянные факты; используйте отбор, сводку и подтверждение.
• Если задача продолжается после паузы или перезапуска, используйте память состояния и трассируемые события. Одного окна контекста недостаточно.
• Если в системе одновременно есть корпоративные знания и индивидуальные предпочтения, выбирайте двойной контур. RAG ищет документы, Memory восстанавливает личный и рабочий контекст.
• Если данные имеют разные сроки хранения или владельцев, разделяйте хранилища логически или физически. Общий индекс усложнит удаление и аудит.
• Если каждый факт должен быть доказан пользователю, не подменяйте RAG памятью. Память может подсказать контекст, но документный ответ должен ссылаться на источник.
• Если ошибка памяти опаснее пропущенного результата, вводите подтверждение человека. Это особенно важно для финансовых лимитов, медицинских сведений, прав доступа и автоматических действий.

Такой подход отвечает и на вопрос, нужна ли долгосрочная память команде, у которой уже есть RAG. RAG достаточно для внешнего знания, но не заменяет память пользователя и состояние многошаговой задачи. Если агент должен одинаково продолжать работу через неделю, помнить предпочтения и не просить повторно одни и те же сведения, нужен отдельный Memory-контур.

Реализация двойного контура

Практическое внедрение лучше проводить поэтапно.

1. Разметьте типы данных

Создайте явные классы: document, user_fact, episode, task_state, tool_output, summary. Не начинайте с одного поля text. Разметка определит политику хранения и способ поиска.

2. Опишите события записи

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

3. Добавьте происхождение

Каждая долговременная запись должна ссылаться на исходную реплику, результат инструмента, документ или действие пользователя. Для сводок сохраняйте список входных событий, а не только финальный текст.

4. Разделите маршрутизацию

Перед поиском определяйте намерение:

• вопрос о внешнем факте — в RAG;
• запрос о предпочтении или истории пользователя — в Memory;
• продолжение задачи — в Memory состояния;
• смешанный запрос — параллельный поиск с отдельными лимитами и приоритетами.

Не смешивайте результаты без меток. Модель должна понимать, где источник, где воспоминание, а где предположение.

5. Настройте конфликтные правила

Опишите, что делать при двух несовместимых предпочтениях, смене проекта, отменённой задаче и неуверенном извлечении. Для спорных фактов предусмотрите статус needs_confirmation, а не принудительное объединение.

6. Проверьте перезапуск

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

7. Проверьте изоляцию

Создайте два тестовых пользователя и два проекта с похожими формулировками. Затем намеренно запросите память из неправильного пространства. Ожидаемый результат — отсутствие записи, а не просто низкий балл релевантности.

8. Проверьте удаление

Удалите исходное событие, производную память, связанный индекс и кэш. После этого повторите запросы по прямому ключу, семантическому сходству и старому идентификатору. Удаление считается завершённым только после проверки всех путей.

9. Зафиксируйте эксплуатационные метрики

Минимальный набор включает долю правильных воспоминаний, ошибочные вызовы, пропущенные релевантные факты, время восстановления после перезапуска, результаты проверки изоляции и полноту удаления. Для RAG добавьте точность источников и актуальность версии документа.

Для долгоживущих агентов важна и среда исполнения. Если процесс должен работать постоянно, хранить журналы и восстанавливать состояние после разрыва соединения, заранее проверьте доступ к диску, SSH, резервному копированию и наблюдаемости. Для временного тестового стенда можно использовать аренду Mac mini для разработки и AI-задач, а варианты размещения сравнить через каталог Mac-сред Kvmzen.

Эксплуатационный выбор

Не разворачивайте Memory только потому, что в продукте появился длинный диалог. Длинный контекст — это способ передать сообщения текущему вызову. Memory — это управляемое долговременное состояние с правилами отбора, обновления, доступа и удаления.

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

• документный фрагмент — основание для фактического ответа;
• пользовательская память — контекст персонализации;
• состояние задачи — инструкция для продолжения;
• необработанный журнал — материал для аудита, но не готовая истина.

Если текущий вариант — один общий векторный индекс, у него есть реальные недостатки: трудно объяснить происхождение факта, сложно удалить данные конкретного пользователя, возрастает риск смешения проектов, а переиндексация начинает затрагивать несвязанные типы информации. Переход на отдельные контуры потребует устойчивой среды, постоянного диска и тестов после перезапуска; временная аренда Mac у Kvmzen может быть разумнее покупки отдельного устройства, когда вам нужно проверить Agent Memory, RAG или двойную схему перед долгосрочным развёртыванием.

Начните с простого самотеста: агенту нужно только находить знания или он обязан помнить пользователя и продолжать задачи? В первом случае стройте RAG с источниками и правами. Во втором — добавляйте Memory с подтверждением и трассировкой. Если ответ «и то и другое», проектируйте два слоя сразу, а затем проверяйте не демо-ответ, а конфликт, изоляцию, восстановление и удаление.