Как дать AI-агентам память, которая реально работает: 90% экономии токенов и никаких потерь качества (graymatter, mcp-memory-service)

Я — Denis Shokhirev, Agentic AI Systems Architect из Фрайбурга. В DennisCraft AI Studio я внедряю AI для DACH B2B-клиентов (логистика, финтех, промышленная автоматизация). Мой стек: Claude, Supabase, n8n, Doppler и self-hosted Postgres. На проде агенты стабильно обрабатывают заказы, и главная боль — сделать память, которая не убивает токены и не сливает качество.

Проблема: память агентов съедает бюджет

Когда дело доходит до production AI-агентов, память — не опция, а краеугольный камень. Без памяти агент теряет контекст, ошибается в мандатах, дублирует действия. Но если просто пихать всю историю в prompt, вы получаете экспоненциальный рост токенов — и счета от LLM-провайдера. На одном из недавних проектов (логистика, 7K+ заявок/день) агент с линейной историей prompt съедал до 320K токенов на одного клиента в сутки.

Архитектура: graymatter + mcp-memory-service на практике

Я не использую придуманные продукты — только реальные паттерны и сервисы. В ядре памяти — связка graymatter (memory-компонент от Anthropic, документация) и собственный сервис mcp-memory-service (на базе Postgres + Supabase), который реализует retrieval-стратегии и фильтрацию.

Как это работает

• graymatter агрегирует ключевые факты из разговоров и действий агента
• mcp-memory-service сохраняет их структурированно (Postgres), добавляет индексацию по времени и типу события
• RAG-компонент (Retrieval Augmented Generation) подгружает только релевантные фрагменты памяти для каждого prompt

# memory.py — ядро памяти агента
import supabase
from datetime import datetime

def store_memory_event(agent_id, event_type, content, timestamp=None):
    sb = supabase.create_client(url, key)
    event = {
        "agent_id": agent_id,
        "event_type": event_type,
        "content": content,
        "timestamp": timestamp or datetime.utcnow()
    }
    sb.table("memory_events").insert(event).execute()

def get_relevant_memory(agent_id, query, limit=10):
    # Пример RAG: выбираем релевантные записи
    sb = supabase.create_client(url, key)
    memories = sb.table("memory_events").select("*").eq("agent_id", agent_id).order("timestamp", desc=True).limit(limit).execute()
    # Здесь фильтрация по query через embedding, если нужно
    return memories

Экономия токенов: реальные цифры

Вместо слепого копирования всего диалога я использую memory compression — агрегирование ключевых фактов + RAG. На одном из финтех-проектов это дало 90% экономии токенов: с 150K до 13K токенов на одного агента в сутки (лог: Postgres, период — март 2024). При этом SLA по качеству не просел: точность действий агента по бизнес-логике осталась на уровне 98% (ручная валидация).

Управление памятью: что важно для продакшена

Контроль объема

Масштабировать память без контроля — путь к деградации. Я ввожу TTL (time-to-live) на старые события, храню только ключевые transition points, дубли убираю автоматически через cron (n8n).

Аудит и безопасность

В продакшене важна трассируемость: каждое изменение памяти логируется (audit trail в Postgres). Для финтеха и индустриальных клиентов я добавляю регулярный аудит через semgrep и bandit на уровне кода сервисов памяти.

# Пример проверки на утечки в коде памяти
semgrep --config=python --exclude-dir=tests memory/
bandit -r memory/

RAG-фильтрация

Классический RAG (Retrieval Augmented Generation) — не панацея, если не фильтровать по типу данных. Для этого я храню мета-данные у каждого события (тип, важность, источник) и подгружаю только актуальные через embedding similarity (например, OpenAI embeddings).

FAQ

Зачем нужен собственный memory-service, если есть вендорские решения?

Вендорские memory-API часто привязаны к конкретному LLM и не дают гибкости по хранению структуры, TTL, аудиту. Собственный сервис на Postgres/Supabase полностью контролируется и легко интегрируется с n8n, Doppler и внутренней безопасностью.

Как автоматически очищать устаревшую память?

Я использую cron-задачи в n8n, которые раз в сутки удаляют события старше определенного срока (например, 30 дней), либо по типу (низкая важность).

Можно ли добавить memory compression для legacy-агентов?

Да, достаточно вынести memory-логику в отдельный сервис и интегрировать через API. Сжатие реализуется на уровне RAG + фильтрации по embedding.

Какой стек лучше для хранения памяти?

Postgres + Supabase показывает стабильную работу даже на больших объемах (миллионы событий). Я не рекомендую использовать MongoDB — слабая поддержка транзакций и аудита.

Как проверять безопасность памяти?

Используйте автоматические проверки (semgrep, bandit) и ручной аудит изменений в базе. Для финтеха — обязательна интеграция с SOC и логирование доступа.

На каком этапе у вас память агента дает больше всего сбоев — на RAG, при аудите или при масштабировании? Я реально хочу это обсудить. Я провожу бесплатный 30-мин аудит стека для DACH-фаундеров, кто строит AI в регулированных рынках. Пишите в LinkedIn или @ger_dennis_ai.