В Amazon Bedrock AgentCore появилась возможность управлять памятью долгоживущих агентов. AWS опубликовала описание архитектуры, которая решает проблему накопления устаревших воспоминаний. В основе — три политики жизненного цикла: TTL-истечение, скоринг и консолидация. Они выполняются в ночном процессе, построенном на AWS Step Functions и Amazon Bedrock.
Проблема, которую решает это решение, знакома разработчикам агентов: без контроля память агента растет бесконечно, и он начинает использовать устаревшие данные. В блоге AWS приведен пример: агент поддержки клиентов ссылался на спор о выставлении счетов, который был разрешен четыре месяца назад, как на активный. Другой агент повторял устаревшие советы по развертыванию, потому что в его памяти остался замененный runbook. Такие ошибки снижают качество ответов и создают риски для соответствия требованиям, например GDPR.
| Тип памяти | Пример | Рекомендуемый срок хранения |
|---|---|---|
| Эпизодическая | Записи о прошлых разговорах | 30–90 дней |
| Семантическая | Факты и предпочтения | 6–12 месяцев |
| Процедурная | Рабочие процессы и паттерны | Без TTL или длительный срок |
Чтобы системно подойти к управлению памятью, AWS предлагает разделить ее на три типа. Эпизодическая память — это записи о прошлых разговорах, они привязаны к сессиям и быстро устаревают. Семантическая память — извлеченные факты и предпочтения, например «пользователь предпочитает регион us-east-1 для развертывания». Процедурная память — это знания о рабочих процессах, например «при вопросах о стоимости сначала запросить AWS Cost Explorer API». Каждый тип требует разной стратегии хранения: эпизодическую можно удалять через 90 дней, семантическую хранить 6–12 месяцев, а процедурную — как можно дольше.
Память делится на эпизодическую, семантическую и процедурную с разными сроками хранения.
Первая политика — TTL-истечение. Она удаляет записи старше заданного срока. По умолчанию для эпизодической памяти это 90 дней. TTL не учитывает полезность памяти, но гарантирует, что объем не будет расти бесконечно, и помогает соблюдать требования по удалению данных. В AgentCore нет встроенного автоудаления, поэтому используется фильтр по системному полю x-amz-agentcore-memory-createdAt с оператором BEFORE.
Вторая политика — скоринг. Она оценивает каждую запись по нескольким критериям: частота обращения, редкость, ценность для будущих задач. Например, запись о том, что пользователь предпочитает определенный регион, получает высокий балл, так как она часто используется. Низкие баллы получают записи, которые редко запрашиваются и не несут уникальной информации. После скоринга записи с низким баллом удаляются.
Третья политика — консолидация. Она объединяет несколько эпизодических воспоминаний в одно семантическое. Например, если агент зафиксировал три разных разговора о предпочтении региона, консолидация создает одну запись: «пользователь предпочитает us-east-1». Это снижает объем памяти и повышает ее качество. Консолидация запускается после скоринга, чтобы не тратить ресурсы на записи, которые будут удалены.
Все три политики настраиваются через параметры, например memoryTtlDays. Для низконагруженных агентов, таких как персональные ассистенты, можно ограничиться TTL и соблюдением GDPR. Полное решение доступно в GitHub-репозитории в виде AWS CDK-стека.
Этот подход отражает общий тренд в индустрии: управление памятью становится отдельной дисциплиной при разработке агентов. Без него агенты деградируют со временем, что особенно критично для систем, работающих месяцами. AWS предлагает конкретный инструментарий, но концепции — TTL, скоринг, консолидация — применимы и к другим платформам.
