Память AI-агента — это не скрытая способность языковой модели, а внешняя система хранения, поиска и обновления контекста. Она позволяет агенту продолжать работу между сессиями, учитывать предпочтения пользователя, использовать накопленные факты и не повторять одни и те же ошибки.

Практическую архитектуру памяти удобно разделить на три слоя: процедурный, семантический и эпизодический. Первый отвечает за навыки и инструкции, второй — за устойчивые знания, третий — за историю событий. Это полезная инженерная модель, но не обязательный стандарт: конкретная реализация зависит от задачи, объёма данных и требований к безопасности.

Почему языковая модель каждый раз начинает с «чистого листа»

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

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

Поэтому полноценному агенту необходима внешняя обвязка:

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

Именно эта архитектура, а не одна лишь LLM, позволяет создавать AI-ассистентов и виртуальных помощников для бизнеса, способных работать с длительными процессами.

Три слоя памяти AI-агента

Слой	На какой вопрос отвечает	Что хранит	Пример
Процедурный	Как выполнять задачу?	Инструкции, навыки, правила использования инструментов	Как проверить заявку и занести результат в CRM
Семантический	Что агент знает?	Факты, предпочтения, сведения о продуктах и процессах	Клиент предпочитает общение на русском языке
Эпизодический	Что произошло?	События, действия, сообщения и изменения во времени	Клиент запросил расчёт, а менеджер отправил предложение

Процедурная память: как агент выполняет работу

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

Например, навык обработки новой заявки может предписывать агенту:

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

Процедурная память не обязательно хранится в одной базе. Небольшие инструкции могут находиться в системном промпте, а объёмные навыки — загружаться только при срабатывании соответствующего триггера. Такой подход уменьшает контекст и не заставляет модель постоянно читать инструкции, не относящиеся к текущей задаче.

Именно так строятся многие практические сценарии AI-автоматизации: агент получает не абстрактную команду «помоги клиенту», а конкретный порядок действий, допустимые инструменты и критерии эскалации.

Семантическая память: факты о пользователе и бизнесе

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

Примеры таких записей:

клиент работает в Болгарии и предпочитает расчёты в евро;
компания обслуживает обращения на русском, болгарском и английском языках;
для возврата товара необходимо подтвердить номер заказа;
менеджер должен согласовывать скидки выше установленного лимита;
отчёт отправляется каждое утро в Telegram и сохраняется в Google Sheets.

Для маленького агента несколько десятков фактов можно хранить в Markdown или JSON и загружать целиком. По мере роста памяти такой способ становится дорогим и неточным: в контекст попадает слишком много лишнего текста.

Как искать нужные факты

На практике используют несколько методов поиска:

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

Размерность embedding-вектора не является универсальной характеристикой памяти: она зависит от выбранной модели. Поэтому правило «память всегда использует вектор 1024×1» было бы технически неверным.

Эпизодическая память: история взаимодействий

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

Например:

10 августа клиент впервые запросил консультацию;
12 августа агент собрал недостающие данные;
13 августа менеджер отправил коммерческое предложение;
15 августа клиент изменил требования к интеграции;
17 августа была согласована новая версия проекта.

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

Поэтому эпизоды обычно проходят консолидацию: система извлекает из истории принятые решения, открытые вопросы, выполненные действия и изменения требований. Частота консолидации определяется нагрузкой и сценарием, а не универсальным правилом «после каждых 5–10 сообщений».

Как работает извлечение памяти перед ответом

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

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

Без такого отбора накопление данных может даже ухудшить работу агента: модель получает устаревшие факты, противоречивые инструкции и лишние фрагменты переписки.

Как обновлять память и не терять историю

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

Основные операции

Add: добавить новый факт или событие.
Update: изменить существующую запись.
Delete: удалить информацию, которая больше не должна храниться.
Supersede: заменить факт новой версией, сохранив историю изменения.
Consolidate: объединить повторяющиеся записи и выделить главное из нескольких эпизодов.

Если клиент сначала назначил встречу на 19:00, а затем перенёс её на 21:00, агент должен использовать новое время. При этом старое значение может остаться в истории с отметкой, когда оно перестало быть действительным.

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

Markdown, SQL, векторы или граф: что выбрать

Хранилище	Когда подходит	Ограничения
Markdown, JSON	Небольшие инструкции, профиль агента, настройки проекта	Сложно искать и обновлять большие объёмы данных
SQLite или PostgreSQL	Сообщения, события, статусы, пользователи, метаданные	Для поиска по смыслу требуется дополнительный механизм
Векторный индекс	Документы, база знаний, похожие обращения и смысловой поиск	Возможны нерелевантные совпадения; нужны фильтры и тестирование
Темпоральный граф	Сложные связи между людьми, компаниями, событиями и изменяющимися фактами	Более сложная разработка, контроль качества и эксплуатация

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

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

Главные риски памяти AI-агента

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

Устаревшие сведения. Агент продолжает использовать старый адрес, цену или договорённость.
Ложная консолидация. Вспомогательная модель неправильно выделяет итог разговора.
Смешивание пользователей. Данные одного клиента попадают в контекст другого.
Инъекция через память. Вредоносный текст сохраняется как инструкция и влияет на будущие действия.
Избыточное хранение. Система накапливает персональные данные без ясной цели и срока удаления.
Отсутствие происхождения факта. Невозможно определить, кто и когда добавил запись.
Неконтролируемые действия. Ошибочно извлечённая память приводит к отправке письма, изменению CRM или другой внешней операции.

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

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

С какого MVP начать бизнесу

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

Например, для агента поддержки минимальная версия может включать:

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

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

Вывод

Память превращает AI-агента из одноразового интерфейса к LLM в систему, способную продолжать работу и учитывать прошлый опыт. Но ценность создаёт не объём сохранённых сообщений, а правильное разделение инструкций, фактов и событий, точное извлечение контекста и контролируемое обновление данных.

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

Если нужно оценить архитектуру памяти для чат-бота, внутреннего ассистента или автоматизации, можно обсудить процесс и состав безопасного MVP с CenterAI.

Частые вопросы

Можно ли просто передавать агенту всю историю переписки?

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

Обязательно ли использовать векторную базу?

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

Может ли агент сам исправлять свою память?

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

Чем память отличается от RAG?

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

Источники и проверка

Дата последней проверки: 20.08.2026.

Память AI-агента: три слоя, архитектура и риски