Память ИИ-агента: краткий контекст, долговременные факты и исправление ошибок

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

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

Что значит память у ИИ-агента

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

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

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

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

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

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

Какие сведения действительно нужно сохранять

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

Минимальная запись памяти может содержать:

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

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

Полезно заранее заполнить сводную таблицу на условных данных:

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

Как разделить краткую и долговременную память

В документации LangGraph v1 описаны два дополняющих механизма. Checkpointer сохраняет состояние графа как checkpoints в рамках конкретного thread. Это краткая, привязанная к потоку память: она помогает продолжать разговор или выполнение с предусмотренного состояния.

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

Упрощённое разделение выглядит так:

1. Сообщения и промежуточные данные относятся к состоянию конкретного thread.
2. Checkpointer сохраняет снимки этого состояния как checkpoints.
3. Подтверждённое предпочтение записывается отдельно в store.
4. При следующей сессии приложение проверяет владельца и только затем добавляет нужный факт в контекст.

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

Как исправлять, ограничивать и удалять память

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

Новое подтверждённое значение заменяет старое только в той же области subject_id + namespace + key. Более свежая гипотеза модели не должна перекрывать подтверждённый факт. Среди подходящих записей приложение выбирает запись со статусом active и максимальной версией. Если действует срок, нужна дополнительная проверка: текущее время должно быть раньше valid_until. Просроченное значение не выдают как действующее — у пользователя запрашивают подтверждение.

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

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

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

Учебная смена предпочтения пользователя

Рассмотрим синтетический пример учебного помощника. Это авторская схема данных, а не интерфейс LangGraph и не результат клиента Switch On AI.

1 октября пользователь u-101 просит присылать отчёт в PDF. Система создаёт v1:

• subject_id: u-101;
• namespace: ["users", "u-101", "preferences"];
• key: report_format;
• value: PDF;
• source: сообщение пользователя от 2026-10-01;
• confirmed_at: 2026-10-01;
• valid_until: 2027-01-01;
• version: 1;
• status: active.

5 октября тот же пользователь пишет: «Теперь присылайте XLSX». Система создаёт v2 со значением XLSX и статусом active, а v1 помечает как superseded. Правило выбора находит максимальную активную версию: max({2}) = 2. Ожидаемое предпочтение u-101 — XLSX.

Для чтения действуют два условия: requested_subject_id = authenticated_subject_id, а namespace разрешён политикой доступа. Когда u-202 запрашивает запись u-101, сравнение u-101 = u-202 даёт false. Помощник отказывает, не называя ни XLSX, ни прежний PDF.

Сохранение предпочтения не заменяет состояние workflow. Checkpoint может показывать, на каком шаге остановилась подготовка конкретного отчёта. Запись report_format=XLSX отвечает на другой вопрос: какой формат подтверждён для будущих обращений пользователя.

Если u-101 просит удалить предпочтение, активную v2 удаляют из рабочего хранилища или закрывают для чтения согласно принятой архитектуре. После этого active_versions = ∅, а ожидаемый ответ — «предпочтение не задано». Запись v1 остаётся устаревшей и не возвращается в работу.

Когда память не нужна и как действовать при ошибке

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

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

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

1. Показать владельцу источник текущей записи.
2. Принять явное исправление.
3. Создать новую версию в той же области пользователя.
4. Повторить чтение по тому же subject_id.
5. Ожидать новое подтверждённое значение и сохранить событие изменения.

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

Как проверить память и обсудить архитектуру

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

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

Для обсуждения проекта подготовьте список нужных фактов: источник, владельца, срок, область доступа, порядок исправления и запрет на сохранение. Отдельно опишите, какое состояние относится только к текущему workflow. Switch On AI может разработать ИИ-помощника, бота или интеграцию для этой операции после проверки данных и доступных API. Совместимость, права и ограничения выбранных компонентов проверяются для конкретного проекта.

Начать можно с разработки ИИ-агента: разобрать одну операцию и согласовать прототип ключевого сценария. Для первого разговора достаточно описать, что помощник должен помнить, какие сведения сохранять запрещено и кто принимает результат. Затем можно обсудить задачу. Прототип не равен готовому внедрению и не обещает одинакового поведения во всех системах.