Память Агента

1. Обзор концепции и системная проблема

Без системной памяти каждый запуск автономного агента является полностью изолированным (stateless). Модель ограничена физическим размером контекстного окна (Context Window Limit) и после завершения сессии теряет все сделанные выводы, исправленные ошибки и пользовательские настройки.

Попытка решить эту проблему «в лоб» — отправлять всю историю перед каждым промптом — приводит к трем критическим инженерным тупикам:

1. Экспоненциальный рост затрат на токены и задержки (Time to First Token).
2. Деградация внимания модели (Lost-in-the-Middle): раздутый контекст распыляет механизм Self-Attention, провоцируя пропуск критических инструкций.
3. Отсутствие обучения на ошибках: агент снова наступает на те же баги кодовой базы, которые он уже решал в предыдущей сессии.

Архитектура Agent Memory разделяет сохранение состояния на специализированные уровни, предоставляя агенту долговременную память при минимальном использовании токенов.

2. Архитектурная таксономия и ментальная модель

В современной агентной инженерии память стандартизировано делится на четыре функциональных слоя:

• 1. Краткосрочная (Working / Scratchpad Memory): Оперативный буфер текущей итерации (ReAct loop). Сохраняет промежуточные мысли (thoughts), аргументы вызова инструментов (tool calls) и ответы системного окружения. Существует только на протяжении жизненного цикла текущей задачи (в памяти процесса или Redis).
• 2. Эпизодическая (Episodic Memory): Хроника прошлого опыта агента: последовательность действий, попытки выполнения задач, причины падения тестов и найденные фиксы. Позволяет агенту вспомнить: «Я уже пытался выполнить миграцию этим методом вчера, и возник deadlock — выберу другой путь».
• 3. Семантическая (Semantic Memory): База извлеченных знаний, фактов и сущностей о окружающем мире, пользователе и репозитории. Реализуется как структурированная база фактов (Knowledge Graph) или векторная база данных с эмбеддингами.
• 4. Процедурная (Procedural Memory): «Мышечная память» агента: алгоритмы, фиксированные воркфлоу, синтаксис кастомных инструментов, правила форматирования кода и системные инструкции (включая репозиторные .agents/skills и .agents/rules).

3. Технический пайплайн и внутренняя механика

Жизненный цикл памяти автономного агента реализуется через 4-этапный конвейер:

1. Extraction & Filtering (Извлечение фактов): Фоновый легкий LLM-парсер или эвристический экстрактор анализирует завершенный диалог или шаг тула. Он отсекает коммуникационный шум («спасибо», «понятно») и выделяет атомарные факты (Atomic Facts).
2. Hybrid Indexing (Гибридное индексирование): Полученные сущности записываются в хранилище с двойным индексом: плотные векторы (Dense Embeddings) для поиска по содержанию + BM25/полнотекстовый индекс для точного совпадения идентификаторов, функций и констант.
3. Context-Aware Retrieval (Селективная выборка): Перед генерацией следующего ответа ранжировщик вычисляет интегральный балл релевантности воспоминания по формуле: Score = w1 * Relevance + w2 * Recency (экспоненциальное затухание) + w3 * Importance (важность). К рабочему промпту подгружаются только топ-$K$ самых важных фрагментов.
4. Memory Compaction & Consolidation (Сжатие и забывание): Периодический процесс сворачивает старые эпизодические цепочки в высокоуровневые выводы (Recursive Summarization), освобождая ресурсы базы знаний.

4. Практические инженерные сценарии в продакшене

01. Персонализированный контекст разработчика

Агент автоматически фиксирует и сохраняет правила конкретного разработчика: например, использование строгого TypeScript, специфику обработки ошибок через Result<T, E>, нежелание видеть any или предпочтение определенных библиотек состояния, избавляя от необходимости повторять это в каждом чате.

02. Архитектурный контекст кодовой базы

Сохранение решений, принятых недели назад: «Почему в модуле биллинга используется очередь Redis Streams вместо непосредственного HTTP-вызова». Агент проверяет семантическую память репозитория перед тем, как предложить опасный рефакторинг.

03. Синхронизация состояния между субагентами

В архитектурах Multi-Agent (например, оркестратор -> кодер -> тестировщик) общая память состояния позволяет агенту-тестировщику мгновенно подтянуть все гипотезы агента-архитектора без полной передачи сырых логов.

5. Подводные камни, типовые ошибки и безопасность

• Context Poisoning (Отравление памяти): Если агент зафиксирует галлюцинацию как достоверное знание, он будет повторять эту ошибку во всех будущих сессиях. Защита: валидация фактов через отдельный шаг критики (Verification Step) и явная возможность удалить ложные воспоминания через UI/команду.
• Retrieval Dilution (Размывание внимания): Слишком низкий порог близости (similarity threshold) приводит к подгрузке десятков нерелевантных воспоминаний, что вытесняет актуальные инструкции пользователя.
• Утечка секретов (Secret Leakage): Сохранение в долговременное хранилище чувствительных данных (API-ключи, пароли из логов, токены). Защита: обязательный слой санитации (Secret Redaction Regex/Entropy detection) на уровне pre-save хука памяти.