Как избежать траты токенов и ускорить работу с Claude Code: внедряем офлайн-память для LLM-агентов

Я — Denis Shokhirev, Enterprise AI architect из Эрлангена. В DennisCraft AI Studio я внедряю AI-агентов для B2B-клиентов DACH, собирая стеки на Claude, Supabase, n8n, Doppler и self-hosted Postgres. За последние полгода я вывел в продакшн 14 LLM-агентов — и почти на каждом проекте сталкивался с реальной болью: токены улетают в никуда, latency растет, а Claude Code жрет бюджет не хуже GPT-4.

Почему офлайн-память критична в продакшне

Когда LLM-агенту на Claude Code нужно помнить детали workflow, он каждый раз получает весь контекст в промпте. Это не просто дорого: на длинных цепочках ответ становится медленным, а окно контекста быстро забивается. В условиях строгих бюджетов и жестких требований к latency — например, в логистике SLA на response time часто не превышает 2-3 секунд — такой подход не работает.

На трех последних запусках агентов я фиксировал перерасход токенов на 18-27% из-за повторяющихся кусков данных в каждом запросе. Если вы работаете с RAG или сложными пайплайнами, сумма вырастает кратно.

Структура офлайн-памяти: что реально работает

Хранилище: Postgres против Supabase

Я тестировал оба варианта. Supabase быстро стартует, но для SLA-критичных задач лучше self-hosted Postgres — latency ниже, контроль выше. Для кеширования промежуточных состояний (state, task history, embeddings) завожу отдельные таблицы:

CREATE TABLE agent_memory (
  agent_id        UUID,
  session_id      UUID,
  step_number     INT,
  input_payload   JSONB,
  output_payload  JSONB,
  created_at      TIMESTAMP DEFAULT NOW()
);

Для быстрого поиска — индексы по agent_id и session_id.

Слой доступа: через n8n или напрямую

Если пайплайн на n8n, можно подключать Postgres node напрямую. Но для сложных read/write операций лучше выделить отдельный backend на FastAPI или Node.js с эндпоинтами для чтения/записи памяти.

# Пример FastAPI endpoint для записи памяти
from fastapi import FastAPI, Request
import asyncpg

app = FastAPI()
pool = None

@app.on_event("startup")
async def startup():
    global pool
    pool = await asyncpg.create_pool(dsn="postgresql://user:pass@localhost/db")

@app.post("/memory")
async def save_memory(request: Request):
    data = await request.json()
    async with pool.acquire() as conn:
        await conn.execute(
            "INSERT INTO agent_memory (agent_id, session_id, step_number, input_payload, output_payload) VALUES ($1, $2, $3, $4, $5)",
            data["agent_id"], data["session_id"], data["step_number"], data["input_payload"], data["output_payload"]
        )
    return {"status": "ok"}

Тестируйте на реальных данных — latency на 1000+ insert/retrieve операций не должен превышать 50-70 мс.

Интеграция с Claude Code: как минимизировать токены

Выделение релевантного контекста

Вместо передачи всей истории в prompt, забираю только релевантные шаги с помощью SQL-запросов или простых фильтров embeddings. Для поиска похожих состояний можно использовать pgvector:

SELECT * FROM agent_memory
ORDER BY embedding <#> '[0.12, 0.33, ...]' LIMIT 3;

В результате в prompt уходит только 2-3 последних шага + наиболее похожие по смыслу — экономия токенов измеряется десятками процентов.

Автоматизация с помощью n8n

n8n позволяет строить цепочки: получение input → выборка памяти по session_id → формирование prompt → вызов Claude Code. Такой пайплайн работает стабильно даже при пиковых нагрузках. Для SLA-сценариев добавляю step: если latency выше 1 секунды, prompt автоматически урезается до минимального контекста.

Безопасность памяти: что нельзя пропустить

LLM-агенты генерируют и записывают данные, которые могут быть чувствительными (PII, финансы, внутренние логи). Я всегда включаю автоматическую проверку на утечки с помощью bandit и gitleaks (по паттернам OWASP Top 10). Например, на одном проекте из 5000 записей bandit поймал 4 случая unsafe eval в сгенерированном коде.

gitleaks detect --source . --report-path=leaks.json
bandit -r ./src -f json -o bandit_report.json

Минимум — шифруйте поля input_payload/output_payload. Для DACH рынка часто требуется compliance по DSGVO: не храните неанонимизированные данные.

FAQ

Какую БД брать для офлайн-памяти?

Для продакшна — self-hosted Postgres. Supabase годится для прототипов или MVP, но latency выше, а контроль хуже.

Как экономить токены при длинной истории?

В prompt отправляйте только релевантные шаги, используйте embeddings для поиска похожих состояний. Не дублируйте всю историю.

Какой стек лучше интегрировать с Claude Code?

n8n для orchestration, Postgres для памяти, FastAPI/Node.js для API-слоя, bandit/gitleaks для безопасности. Проверено на 10+ продакшн-агентах.

Как тестировать latency пайплайна?

Генерируйте 1000+ операций, фиксируйте среднее время read/write до и после оптимизаций. Сравнивайте Supabase и self-hosted Postgres.

Какой минимум для compliance в DACH?

Шифруйте payload, не храните PII без анонимизации, документируйте все обработчики памяти для аудита.

На каком этапе у вас чаще всего всплывают проблемы с памятью LLM-агентов — latency, утечки, перерасход токенов? Готов посмотреть ваш пайплайн и дать обратную связь. Я делаю бесплатный аудит AI-стека для DACH-команд, строящих решения под регулирование. Пишите в LinkedIn или в @ger_dennis_ai.