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

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

Сначала разделите четыре разных сущности

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

Работа CoALA предлагает более подробную типологию для языковых агентов:

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

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

Что нельзя превращать в «воспоминание» автоматически

Фраза пользователя ещё не является фактом. Менеджер мог привести пример, процитировать клиента, исправить себя в следующем сообщении или обсуждать гипотезу. Если модель без проверки сохранит «скидка для клиента — 20%», агент может применить её в будущем уже как установленное правило.

По умолчанию не стоит сохранять:

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

Последний пункт особенно важен. OWASP относит отравление памяти и контекста к рискам агентных систем: недоверенный ввод может попасть в долговременное хранилище и влиять на будущие планы или действия. Запись памяти — это привилегированная операция, а не побочный эффект каждого ответа.

Безопасный путь записи

Хорошая архитектура разделяет предложение памяти и её публикацию.

1. После диалога или бизнес-события модель формирует кандидата в строго заданной схеме: субъект, факт, источник, предполагаемый срок и причина сохранения.
2. Детерминированный код удаляет запрещённые поля, проверяет типы, размер и наличие источника.
3. Политика решает, допустимо ли хранить этот тип данных для данного пользователя, организации и процесса.
4. Факт сверяется с системой-источником либо отправляется человеку на подтверждение, если влияет на цену, обязательства, доступ или внешнее действие.
5. Новая запись получает версию, владельца, область доступа, срок действия и связь с предыдущей версией.
6. Только после этого она становится доступна для поиска агентом.

Для безобидных предпочтений можно использовать мягкое подтверждение: «Запомнить, что отчёт нужен в XLSX?». Для коммерческих условий лучше не создавать копию вообще — хранить идентификатор клиента и при каждом запросе читать актуальное значение из CRM.

Минимальная схема записи

Одна строка памяти должна отвечать не только на вопрос «что запомнить», но и «почему этому можно доверять». Практический набор полей:

  • `memory_id` и стабильный `source_event_id` для защиты от дублей;
  • `tenant_id`, `user_id` или группа доступа;
  • тип памяти и предметная область;
  • нормализованное утверждение или структурированное значение;
  • ссылка на источник, его хеш и время наблюдения;
  • статус проверки: кандидат, подтверждено, отклонено, отозвано;
  • `valid_from`, `valid_until` и срок удаления;
  • идентификатор записи, которую новая версия заменяет;
  • классификация данных и политика доступа;
  • автор подтверждения и время изменения.

Поле confidence модели можно хранить для диагностики, но оно не заменяет проверку источника. Высокая уверенность означает лишь внутреннюю оценку модели, а не юридическую или коммерческую достоверность.

Где хранить локально

Для первого пилота часто достаточно PostgreSQL. Таблицы дают транзакции, уникальность по `source_event_id`, историю версий, сроки и управляемое удаление. Row-Level Security может ограничить строки по организации или пользователю; при включённой RLS без подходящей политики PostgreSQL применяет default-deny для обычного доступа. Сервисный пользователь агента не должен без необходимости владеть таблицей, поскольку владелец обычно обходит RLS.

Простая локальная схема может состоять из:

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

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

Как извлекать память без смешения пользователей

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

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

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

Исправление важнее накопления

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

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

Как оценивать пилот

Качество памяти нельзя измерять количеством сохранённых записей. Чем больше агент «помнит», тем выше стоимость проверки и риск повторного использования ошибки.

Соберите тестовый набор из реальных, но обезличенных диалогов и проверьте отдельно:

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

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

Модельная экономика

Предположим, 20 сотрудников проводят по 50 сессий в месяц, а агент предлагает в среднем пять кандидатов памяти за сессию. Получается 5 000 кандидатов. Если политика пропускает 10%, в постоянном хранилище появляется 500 записей в месяц — небольшой объём, для которого отдельная распределённая платформа обычно не нужна.

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

Практический следующий шаг

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

За две недели можно:

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

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