Память ИИ-агента: что хранить, проверять и забывать

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

Агент помнит. Осталось понять, что именно

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

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

В разборе context engineering Anthropic описывает сжатие контекста и заметки вне текущего окна как способы продолжать длинную работу. Это инженерные приёмы управления информацией. Они не превращают вчерашнюю фразу клиента в бессрочное правило компании. Такое превращение обычно делает уже наша собственная интеграция. С важным видом и без свидетелей.

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

Четыре слоя, которые нельзя складывать в одну корзину

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

Второй слой — рабочее состояние: какой подбор начат, какие варианты исключены, какого уточнения ждём. Состояние относится к определённой задаче. Закрытый запрос на оборудование не должен превращаться в активный запрос лишь потому, что клиент снова написал «добрый день». Новая беседа может продолжать старую работу, а может начинать другую. Связь требуется установить.

Третий слой — долговременная заметка: предпочтительный язык общения, типичная роль контактного лица, способ доставки материалов. Здесь особенно легко перепутать наблюдение с договорённостью. «Дважды отвечал по электронной почте» и «попросил общаться только по электронной почте» — разные основания. У первого есть вероятность, у второго есть явная реплика и область её действия.

Четвёртый слой — деловая запись: заказ, согласованный срок, подписанное условие, назначенная задача. Это область CRM, учётной системы или другого принятого источника. Агент может помнить ссылку на запись и краткое объяснение. Но перед отправкой актуального счёта ему нужен действующий объект, а не красивая выжимка. Сводка хороша для ориентирования. Для исполнения нужен источник.

Документация LangGraph отдельно описывает сохранение состояния конкретного потока через checkpointer и данных между потоками через store. Это полезный технический пример разделения областей. У конкретного продукта названия компонентов могут отличаться; продуктовые границы всё равно придётся определить самим.

Из чего состоит заметка, которой можно доверять

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

Рабочая запись должна сохранять смысл, происхождение и пределы. Например: «В разговоре по заявке А контакт попросил рассмотреть отсрочку; решение не принято; источник — фрагмент разговора; проверено менеджером такого-то числа». Формулировка длиннее, зато она оставляет заявку на отсрочку заявкой. Не повышает её до финансового обязательства по службе.

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

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

Почему забывать — тоже рабочая функция

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

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

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

Рядом со сроком полезен повод пересмотра: новый контакт, другой заказ, смена роли, явное исправление клиента. Тогда память обновляется событиями, а не только календарём. Если человек говорит «теперь удобнее звонить», это не дополнительная заметка в конце стопки. Это основание проверить и заменить прежнее предпочтение в соответствующей области.

Хорошая память экономит повторные вопросы, а не отменяет уточнения. Иногда самый профессиональный ответ агента — «Раньше вы просили присылать расчёт почтой. Для этой заявки оставляем тот же вариант?» Такой вопрос не демонстрирует слабость машины. Он показывает, что она отличает прошлое от действующего решения.

Память не должна конкурировать с CRM

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

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

При несовпадении агенту полезнее показать расхождение, чем незаметно усреднить два срока. Внутренняя сводка может выглядеть так: «В переписке указана старая дата; в карточке заказа сохранена новая; требуется проверка принятого уведомления». Клиентский ответ зависит от регламента. Главное — несогласованные источники не должны превращаться в новое уверенное обещание.

База знаний решает другую задачу: объясняет продукт, правила и общие условия. Подробности её подготовки разбираем в материале о базе знаний для агента. Здесь мы не строим ещё один справочник. Мы устанавливаем, как агент переносит контекст конкретной работы и когда обязан вернуться к первичной записи.

Один клиент, три канала и чужая память

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

Память нужно привязывать к установленному субъекту и рабочей области. Заметка о компании может быть доступна её команде продаж; личное предпочтение относится к конкретному контакту; детали заказа — к доступной участнику сделке. Чем шире автоматическое объединение, тем важнее возможность проверить основание связи. Семантическое сходство текста не является способом авторизации.

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

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

Что теряется, когда историю сжали до абзаца

После длинного разговора агенту часто передают сводку. Это разумно: для следующего шага не нужны все приветствия и повторные вопросы. Опасность возникает, когда при сокращении исчезает статус фразы. «Обсуждали вариант переноса, клиент пока не подтвердил» превращается в «перенести». Сводка стала короче, а обязательство — сильнее.

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

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

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

Перезапуск: помнит ли приложение, а не только чат

Успешная демонстрация в одной беседе не проверяет работу между запусками. Агенту может помогать история, лежащая в оперативной памяти процесса. После обновления сервера она исчезнет. В документации LangGraph отдельно отмечено, что InMemorySaver не сохраняет состояние после перезапуска; для постоянного хранения требуется соответствующая реализация. Названия библиотек меняются, различие остаётся.

Для сценария продаж тест выглядит земным. Создать задачу, пройти несколько шагов, остановить процесс в контролируемой среде, восстановить его и продолжить с правильного места. Агент должен знать, что уже принято, что только подготовлено и какое действие нельзя выполнить повторно. Сохранённый текст «письмо отправлено» недостаточен: нужен подтверждённый результат интеграции.

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

Не нужно вводить сложную инфраструктуру там, где агент лишь делает разовую внутреннюю сводку. Но если продукт обещает продолжение задач, эту способность проверяют как функцию. «Работало до перезагрузки» — нормальная стадия разработки. В коммерческом предложении она обычно называется немного иначе.

Сколько стоит запоминать всё подряд

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

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

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

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

Приёмка памяти на неприятных сценариях

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

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

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

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

Что попросить у подрядчика завтра утром

Попросите показать одну запись памяти целиком: не карточку на слайде, а источник, дату, область и статус. Затем попросите исправить её, закрыть задачу и повторить обращение после перезапуска. Такая короткая демонстрация показывает больше, чем обещание «персональный агент, который знает вашего клиента».

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

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

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