Краткосрочная, долговременная и эпизодическая память AI-агента

Типы памяти AI-агента отвечают на разные вопросы: что происходит в текущем диалоге, какие устойчивые сведения можно использовать позже и что произошло в конкретном прошлом эпизоде. Это архитектурные роли, а не три обязательных продукта или три скрытых способности модели. Модель получает контекст на каждом вызове; приложение решает, что сохранить, найти, проверить и передать ей. Широкая работа с инструкциями и контекстом описана в prompt engineering, а проектирование процесса — в AI-автоматизации.

Ниже — авторская схема MEMORY-3 и один синтетический пример: агент помогает сотруднику поддержки готовить ответ по заявке. Схема показывает границы проектирования, а не действующую клиентскую систему или измеренные результаты. О том, как сохранять состояние между шагами, отдельно рассказывает статья о state и memory; здесь фокус именно на различии трёх типов памяти.

Определение без маркетинга

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

Долговременная память — сохранённые факты, документы, предпочтения или извлечённые знания, которые могут понадобиться в будущих задачах. Их нужно хранить вне вызова модели, снабжать источником, владельцем, сроком годности и правилами доступа. «Долговременная» не означает «вечная» или «достоверная»: запись может устареть либо требовать удаления.

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

Как это работает: схема MEMORY-3

Проектная схема разделяет три хранилища и ставит проверку перед использованием каждого. Поток выглядит так:

задача + личность пользователя
    → рабочий контекст (только текущие данные)
    → поиск разрешённых знаний (источник, версия, срок)
    → выбор относящихся эпизодов (событие, время, результат)
    → сборка ограниченного контекста для модели
    → предложенное действие → политика → инструмент
    → проверка результата → запись нового эпизода

Сначала приложение проверяет личность, tenant и цель задачи. Затем загружает текущую переписку и только те документы, на которые есть право. Поиск в долговременной памяти может использовать ключи или семантический индекс, но найденный фрагмент остаётся данными, а не инструкцией с правом обходить политику. Эпизоды фильтруются по объекту, времени и статусу результата. Приложение формирует контекст с пределом объёма и метками происхождения. Модель предлагает ответ либо действие; сервер снова проверяет права и эффект. После исполнения сохраняется подтверждённый результат или статус «исход неизвестен».

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

Где MCP и инструменты

MCP может предоставить инструменты чтения документов или событий, но протокол сам не определяет качество памяти. Источник, права, срок хранения и способ обновления задаёт приложение. Permission model должен проверять доступ к каждому найденному объекту и каждому действию. Инструкция в сохранённом тексте не становится системной политикой только потому, что она попала в поиск.

Один сквозной пример

Сотрудник открывает заявку 784: клиент спрашивает о возврате. Краткосрочный контекст содержит текст заявки, выбранный язык и цель «подготовить черновик». Долговременное хранилище возвращает актуальную инструкцию по возврату с версией и ссылкой на источник, доступную этому сотруднику. Эпизодический журнал показывает, что вчера по той же заявке был создан черновик, но подтверждения отправки нет.

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

Условный контракт записи и выборки:

const context = await loadCurrentTask(taskId, actor);
const knowledge = await retrieveKnowledge({
  tenant: actor.tenant, scope: "returns", asOf: now, requireSource: true
});
const events = await loadEvents({ ticketId: 784, actor, limit: 10 });
const proposal = await model.propose({ context, knowledge, events });
if (proposal.action === "send") return holdForExactApproval(proposal);
return saveDraftWithProvenance(proposal);

Это псевдокод. В реальной системе доступ к документам и событиям проверяется на стороне сервера, а результат отправки читается из целевой системы. Модель не выбирает себе tenant и не получает сырой общий архив.

Где каждый тип подходит, а где нет

Часто достаточно короткого контекста и обычной базы документов. Отдельную эпизодическую память имеет смысл вводить, когда нужны восстановление процесса, разбор действий и точное различение «предложено», «выполнено» и «подтверждено». Сложный векторный поиск не обязателен для небольшого набора правил; точный поиск по ID и версии бывает проще проверить.

Ограничения и контроль качества

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

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

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