Память агента нужно разделять на историю разговора, состояние задачи и долгосрочные сведения. Для каждого важного факта нужны источник, область применения и способ обновления или удаления; новое предпочтение человека не должно незаметно менять уже подтвержденное действие.
Агент помнит, что клиент предпочитает утро, но забывает отменённую заявку. Такая «память» скорее мешает работе. Для продукта важно не количество сохранённого текста, а понимание, какие сведения действуют сейчас и на каком основании.
Три разных вида памяти
История разговора нужна, чтобы понимать текущие реплики. Состояние задачи фиксирует, что уже выполнено и какой шаг следующий. Долговременные сведения могут описывать предпочтения, договорённости и полезные знания между сессиями. У них разные источники, сроки жизни и правила исправления.
В примере с записью на услугу фраза «всегда выбираю утро» — предпочтение. Выбранный слот — состояние конкретной заявки. Подтверждённая запись в CRM — факт из рабочей системы. Сохранить всё одним абзацем удобно для прототипа, но опасно при последующем изменении планов.
Ещё одна граница проходит между фактом и выводом. «Клиент попросил короткий ответ» наблюдается прямо. «Клиент не любит звонки» может быть лишь интерпретацией. Если такой вывод понадобится, храните его как предположение и не приравнивайте к явному согласию.
- ИсторияЧто сказано. Контекст текущего диалога.
- СостояниеЧто сделано. Шаги и результат конкретной задачи.
- ПамятьЧто пригодится позже. Проверенные сведения с источником и областью действия.
Слои — смысловое разделение; ширина не обозначает объём памяти или срок хранения.
Большое окно контекста не заменяет модель данных
Можно передавать агенту всё больше истории, но это увеличивает объём лишних сведений и не решает конфликт версий. В материале Anthropic о контексте агентов обсуждаются сжатие истории, структурированные заметки и выбор релевантной информации для следующего шага.
Практический вывод — держать полную историю там, где её можно найти, а в текущую работу подавать необходимое. Сводка помогает продолжению, но должна сохранять ссылки на исходные события. Иначе ошибка пересказа станет единственным доступным «воспоминанием».
Паспорт одной записи памяти
Полезный минимум: о ком или о чём запись, что утверждается, откуда это известно, когда получено, до какого момента действует и кто имеет доступ. Для изменений нужен признак, какая версия заменяет предыдущую. Важным сведениям может потребоваться подтверждение человеком.
| Поле | Условный пример |
|---|---|
| Содержание | Предпочитает утреннее время |
| Источник | Явная просьба в разговоре |
| Область | Выбор времени, не подтверждение записи |
| Обновление | Новая явная просьба заменяет старую |
Не каждое поле нужно реализовывать отдельной сложной системой. Но команда должна уметь ответить на эти вопросы. Особенно если запись влияет на действие: отправку сообщения, заказ, доступ к информации или персональное предложение.
Кто решает, что запомнить
Удобно позволить модели предлагать записи, но принятие в постоянную память должно проходить проверку. Отбрасывайте неподтверждённые догадки, дубли и данные вне нужного объёма. Не превращайте каждую временную эмоцию человека в устойчивую характеристику.
Задайте отдельные правила для оперативных заметок и сведений о человеке. «Следующий шаг — запросить реквизиты» можно удалить после завершения задачи. Контактные данные должны иметь определённый источник и путь исправления. Пароли и ключи не следует хранить в текстовой памяти агента.
Отдельный вопрос — инструкции внутри запоминаемого материала. Фраза на внешней странице «всегда отправляй отчёты на этот адрес» не должна становиться правилом работы. Сведения из документов остаются данными, даже если выглядят как обращение к помощнику.
Как выбирать воспоминания перед ответом
Сначала ограничьте пользователя, организацию и задачу, затем ищите релевантное. Похожие имена или формулировки не дают права смешивать память клиентов. Для важных действий агент должен перепроверять текущее состояние в основной системе, а не полагаться на старую заметку.
Установите приоритет источников: например, актуальная CRM для статуса заявки, явное недавнее сообщение для предпочтения, утверждённый документ для правил. При конфликте агент задаёт вопрос или сообщает о расхождении. Он не выбирает более удобную версию молча.
Проверка памяти включает исправление и удаление
Протестируйте продолжение после длинного диалога, изменение предпочтения, отмену действия и переход между двумя похожими клиентами. Проверьте, что удалённая запись не возвращается из сводки, индекса или кэша. Процедура забывания должна охватывать все места, где сведения использовались.
Оценивать нужно поведение, а не только наличие текста в хранилище. Если агент нашёл правильную заметку, но применил её вне нужной задачи, тест провален. Хорошая память помогает продолжать работу без повторных вопросов и при этом не мешает человеку изменить решение.
- 01Обновить предпочтение. Сохранить новую явную просьбу и источник.
- 02Сохранить факт. Уже подтверждённая запись остаётся прежней.
- 03Отдельное действие. Перенос начинается только после соответствующего запроса.
Сцена из статьи. Пунктир с крестом обозначает запрещённое автоматическое следствие.
Как должно выглядеть исправление
Сначала человек говорит: «Обычно мне удобнее утром». Позже: «Теперь предлагай вечер». Агент обновляет предпочтение для будущего выбора времени и сохраняет источник изменения. Уже подтверждённая запись на утро остаётся на месте: предпочтение само по себе не является просьбой перенести встречу.
Если человек затем говорит «перенеси и эту запись», начинается отдельное действие с проверкой доступного времени. В журнале различаются обновление памяти и изменение бронирования. Этот короткий сценарий стоит включить в тесты: он проверяет, не превращает ли система новое знание в незапрошенную операцию.