Память агента — это механизм, который позволяет LLM-агенту не терять рабочее состояние во время выполнения задачи и при необходимости сохранять устойчивые факты между сессиями. Краткосрочная память хранит то, что нужно агенту прямо сейчас: последние сообщения, промежуточные выводы, результаты вызовов инструментов, текущий план. Долгосрочная память хранит то, что должно пережить завершение сессии: подтвержденные предпочтения пользователя, профиль, историю кейсов, полезные выводы. Такой подход нужен не всегда: если задача полностью укладывается в один запрос, если важен строгий детерминизм или если нельзя безопасно хранить пользовательские данные, память агента лучше не включать.
Простыми словами
Если упростить, краткосрочная память отвечает за непрерывность внутри текущего диалога или workflow, а долгосрочная — за накопление опыта и персонализацию между диалогами.
| Слой | Что хранит | Срок жизни | Типичные проблемы |
|---|---|---|---|
| Краткосрочная память | История сообщений, шаги плана, результаты инструментов, рабочие переменные | Пока идет текущая задача или сессия | Переполнение контекста, шум, потеря важных деталей при суммаризации |
| Долгосрочная память | Профиль пользователя, подтвержденные факты, прошлые кейсы, устойчивые предпочтения | Дни, недели, месяцы или до удаления | Устаревание, ложные записи, утечки данных, сложность исправления |
Для практики важно не само наличие памяти, а ее разделение по назначению. Если смешать все в одну историю переписки, агент быстро начинает либо забывать важное, либо тянуть в контекст лишнее. Поэтому краткосрочную память обычно держат рядом с потоком выполнения, а долгосрочную — во внешнем хранилище с отдельными правилами записи и доступа.
Еще одно полезное различие: краткосрочная память обычно нужна агенту для рассуждения и продолжения работы, а долгосрочная — для выбора лучшего действия на основе прошлого опыта. Это разные задачи, и их не стоит решать одним и тем же механизмом.
Как это работает
Краткосрочная память
Краткосрочная память обычно строится поверх состояния сессии или треда. В нее входят:
- последние сообщения пользователя и агента;
- результаты вызовов инструментов;
- текущий план или список подзадач;
- временные переменные, например выбранный проект, тикет, среда или дата;
- суммаризация старых сообщений, если полная история уже не помещается в контекстное окно.
На практике агент не должен слепо передавать модели всю историю. Обычно применяют одно или несколько правил: обрезку по размеру, выделение важных сообщений, суммаризацию старых шагов, хранение tool outputs отдельно от человеческого текста. Иначе модель тратит контекст на шум и ухудшает точность.
Долгосрочная память
Долгосрочная память хранится вне модели: в SQL, key-value хранилище, документной базе, векторном индексе или их комбинации. Сами данные часто делят на несколько типов:
- Профильная память — язык, роль, стек, предпочтения, ограничения доступа.
- Семантическая память — устойчивые факты о пользователе, компании, проекте или домене.
- Эпизодическая память — краткие записи о прошлых сессиях: что произошло, чем закончилось, какие решения сработали.
- Процедурная память — рабочие инструкции и проверенные паттерны действий.
Критический момент здесь — не хранить все подряд. В long-term стоит записывать только то, что подтверждено, повторно полезно и не нарушает правила приватности. Логи ошибок, черновые гипотезы модели и одноразовые детали обычно лучше не сохранять как долгосрочные факты.
Цикл работы
- Сбор сигнала. Агент получает сообщения, данные от инструментов и состояние процесса.
- Решение о записи. Отдельное правило или модель решает, что стоит сохранить, а что нет.
- Нормализация. Данные переводятся в компактную структуру: факт, источник, время, уровень доверия, владелец, срок жизни.
- Сохранение. Краткосрочное состояние пишется в state store, долгосрочное — во внешнее хранилище.
- Извлечение. Перед следующим шагом агент ищет только релевантные записи по пользователю, задаче, проекту или теме.
- Внедрение в контекст. В prompt попадает не вся память, а отобранные и сжатые фрагменты.
- Обновление или удаление. Устаревшие записи пересматриваются, объединяются или удаляются.
Хорошая реализация памяти всегда опирается на политику: что можно писать, кто может читать, когда запись устаревает, как исправлять ошибочные факты и как подтверждать важные сведения. Без этой политики память быстро превращается в источник галлюцинаций и рисков.
Зачем нужно
- Непрерывность работы. Агент может продолжить многошаговую задачу без повторного объяснения контекста.
- Персонализация. Система учитывает язык общения, роль пользователя, его стек и типичные сценарии.
- Снижение лишних запросов. Не нужно каждый раз уточнять одни и те же факты.
- Качество решений. Агент опирается на прошлые кейсы, а не только на текущую реплику.
- Экономия контекста. Вместо полной истории можно подать модели короткое релевантное извлечение.
Но память нужна не в каждом продукте. Для FAQ-бота с короткими ответами, одноразовых batch-задач, строго регламентированных approval-flow и систем с повышенными требованиями к приватности часто лучше оставить агент статeless. Чем дольше живет память, тем выше цена ошибки в записи.
Пример
Представим support-агента для B2B SaaS, который помогает инженерам разбирать инциденты.
Пользователь пишет: «После обновления ingress в Kubernetes у нас начались 502 на staging. Мы в eu-central-1, Helm chart кастомный».
В этом кейсе краткосрочная память должна сохранить текущий инцидент:
Среда: staging. Регион: eu-central-1. Симптом: 502 после обновления ingress. Подозреваемая область: кастомный Helm chart. Открытые подзадачи: проверить конфиг, сравнить значения chart, посмотреть rollout и health probes.
Параллельно агент может извлечь из долгосрочной памяти профиль аккаунта:
Клиент использует Kubernetes 1.29, предпочитает ответы на русском, change window по пятницам ночью, ранее уже ломал routing из-за несовместимых annotations в ingress.
Что это дает на практике:
- Агент не переспрашивает язык, среду и тип инфраструктуры.
- Он сразу предлагает релевантную проверку по annotations, потому что похожий случай уже был.
- В контекст не попадает весь архив прошлых тикетов, а только одна краткая и полезная запись.
После решения инцидента не надо писать в long-term весь лог сессии. Достаточно сохранить короткий подтвержденный итог, например: «Для проекта X после обновления ingress на staging причиной 502 была несовместимая annotation в кастомном Helm chart; исправление подтверждено пользователем». Если причина не подтверждена, такую запись сохранять нельзя.
Это и есть главный принцип: краткосрочная память помогает вести текущую работу, долгосрочная — переиспользовать проверенное знание.
Заблуждения и ограничения
- «Память обучает модель». Нет. Записи в памяти не меняют веса модели. Они только подмешиваются в контекст или используются логикой приложения.
- «Чем больше памяти, тем умнее агент». Нет. Лишние записи ухудшают retrieval, загрязняют prompt и повышают риск неверных выводов.
- «Можно хранить сырую историю как есть». Обычно это плохая идея. История содержит шум, противоречия, персональные данные и временные гипотезы.
- «Долгосрочная память всегда надежна». Нет. Запись может устареть, быть сделанной по ошибке или конфликтовать с новой информацией. Нужны версии, метки времени и политика исправления.
- «RAG полностью заменяет память». Не совсем. RAG извлекает документы из корпуса знаний, а память агента хранит состояние, профиль и опыт взаимодействий. Эти механизмы часто работают вместе.
- «Память безопасно включать по умолчанию». Нет. Если система работает с чувствительными данными, нужен явный контроль согласия, доступа, удаления и срока хранения.
Есть и прикладные ограничения. Память добавляет задержку, стоимость хранения, сложность схемы данных и отдельную задачу оценки качества. Нужно измерять не только recall извлечения, но и влияние памяти на финальное действие агента. Если вы не готовы поддерживать эти процессы, лучше ограничиться краткосрочным state management без long-term.
Частые вопросы
Чем память агента отличается от контекстного окна?
Контекстное окно — это лимит текста, который модель может учитывать в одном запросе. Память агента — это механизм хранения и отбора данных, которые могут жить дольше одного запроса и попадать в контекст выборочно.
Нужно ли векторное хранилище для long-term памяти?
Не всегда. Для профиля пользователя и структурированных фактов часто лучше подходят SQL или key-value. Векторный поиск полезен, когда нужно находить похожие эпизоды или нестрого совпадающие знания по смыслу.
Что именно стоит записывать в долгосрочную память?
Только подтвержденные, повторно полезные и допустимые по политике данные: предпочтения, роль, стек, проверенные итоги прошлых кейсов. Черновые выводы модели и одноразовые детали лучше не сохранять.
Как исправлять неверную память?
Нужны версии записей, временные метки, источник факта и возможность явного удаления или переопределения. Без этого агент будет продолжать опираться на устаревшие или ложные сведения.
Связанные понятия
- Контекстное окно — объем данных, который модель видит в одном запросе.
- RAG — извлечение релевантных документов из внешней базы знаний перед генерацией ответа.
- State management — хранение и передача состояния многошагового процесса.
- Векторное хранилище — индекс для семантического поиска по embedding-представлениям.
- Профиль пользователя — структурированный набор устойчивых предпочтений и атрибутов.
- Tool calling — вызов внешних инструментов агентом, результаты которых часто попадают в краткосрочную память.
- Суммаризация истории — сжатие старых сообщений для экономии контекста.
- Политика хранения данных — правила записи, доступа, удаления и срока жизни памяти.