Память для AI-инструментов: как обеспечить кросс-сессионную и кросс-агентную устойчивость знаний

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

Кейс: почему AI-агенты теряют знания

В реальных B2B-проектах, где AI-агенты общаются друг с другом и с пользователями (например, через n8n-воркфлоу или API), я регулярно сталкиваюсь с потерей контекста. Один агент обработал заявку, второй должен подхватить дело через час — но без сохранённой памяти цепочка рвётся. Перезапуск контейнера — и весь прогресс потерян. В финтехе и логистике это приводит к ошибкам, которые нельзя отловить на этапе демо.

Типы памяти: что реально работает в продакшене

На практике для устойчивой памяти между агентами и сессиями я применяю только два типа: Postgres (через Supabase) для структурированных данных и pgvector — для embedding-контекста.

Архитектура: как связать память с агентами

1. Модель данных: что хранить

В каждом проекте я выделяю следующие сущности: Context (контексты задач), AgentState (текущее состояние агента), ConversationHistory, KnowledgeBase. Для гибкости добавляю флаг session_id — позволяет быстро восстанавливать цепочку после сбоя.

CREATE TABLE agent_state (
  id SERIAL PRIMARY KEY,
  agent_id VARCHAR(64),
  session_id VARCHAR(64),
  state JSONB,
  updated_at TIMESTAMP DEFAULT now()
);

CREATE TABLE conversation_history (
  id SERIAL PRIMARY KEY,
  session_id VARCHAR(64),
  message TEXT,
  sender VARCHAR(64),
  ts TIMESTAMP DEFAULT now()
);

2. Интеграция с Supabase и n8n

В 11 из 14 production-агентов я использовал Supabase (Postgres + API). n8n подключаю к Supabase через официальный node. На каждый шаг воркфлоу записываю текущее состояние в таблицу agent_state, а сообщения — в conversation_history.

// Пример из Claude Code: сохранение состояния в Supabase
import { createClient } from '@supabase/supabase-js';

const supabase = createClient(process.env.SUPABASE_URL, process.env.SUPABASE_KEY);

async function saveAgentState(agentId, sessionId, state) {
  await supabase
    .from('agent_state')
    .upsert([{ agent_id: agentId, session_id: sessionId, state }]);
}

3. Векторная память для RAG

Когда агенту нужно искать знания по embedding, использую pgvector. Embedding тексты (например, из документации или чатов) — это отдельная таблица. Важный момент: храню не только embedding, но и метаданные — к какому агенту и сессии они относятся.

CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE embeddings (
  id SERIAL PRIMARY KEY,
  session_id VARCHAR(64),
  content TEXT,
  embedding VECTOR(1536)
);

Безопасность: как защищать память в продакшене

На трёх последних внедрениях я поймал одну и ту же уязвимость: при генерации SQL-запросов из LLM не фильтруются инъекции. Использую bandit и semgrep для анализа backend-кода по базе OWASP, а доступ к Supabase закрываю через service role + отдельные токены для каждого агента.

# Проверка кода на уязвимости
semgrep --config=auto ./src/
bandit -r ./src/

Для критичных путей (финтех, обработка заявок) ставлю логирование запросов к базе и алерты при аномалиях (например, попытка доступа к чужому session_id).

Продвинутая тема: кросс-агентный обмен памятью

Когда несколько агентов должны совместно обрабатывать заявки (например, агент-парсер и агент-валидатор), я выделяю общую таблицу shared_memory с привязкой к task_id. Это позволяет накапливать знания и прогресс по задаче даже при асинхронных вызовах.

CREATE TABLE shared_memory (
  id SERIAL PRIMARY KEY,
  task_id VARCHAR(64),
  key VARCHAR(64),
  value JSONB,
  updated_at TIMESTAMP DEFAULT now()
);

Ключ: защищать доступ по ролям и логировать все изменения — иначе один баг в агенте может стереть память для всех цепочек.

FAQ

Как быстро добавить кросс-сессионную память в существующий AI-проект?

Минимально — создать таблицу session_state в Postgres и сохранять туда JSON-состояния после каждого ключевого шага. Не тянуть с синхронизацией: лучше перезаписать, чем потерять цепочку.

pgvector / векторные БД — реально нужны для бизнес-памяти?

Только если вы делаете RAG или embedding-поиск. Для типичных бизнес-данных (статусы, флаги) — обычный Postgres быстрее и проще.

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

В моём опыте: Supabase (Postgres) + pgvector. Не советую полагаться на локальные файлы или Redis — слишком много сбоев при сбоях контейнеров и масштабировании.

Как защитить память от утечек?

Контролируйте доступ через service roles, используйте токены, проверяйте права на уровне каждой записи (row-level security). Запускайте bandit и semgrep для анализа кода.

Можно ли дать память агенту без БД?

Только если сценарий совсем простой и агент не должен переживать рестарт или делиться знаниями с другими. В продакшене это почти не встречается.

У вас на проекте потеря памяти агента приводила к багам в проде? Как решаете кросс-агентный обмен знаниями? Пишите кейсы. Я провожу бесплатный 30-мин аудит AI-стека для DACH-компаний — пишите в LinkedIn или @ger_dennis_ai.