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

Я — Денис Шохирев, архитектор AI из Эрлангена. В DennisCraft AI Studio я внедряю AI-агентов для B2B-клиентов по DACH: логистика, финтех, автоматизация. За последние 6 месяцев я выпустил 14 production-агентов — и каждый второй проект сталкивался с неожиданно низкой производительностью на этапе ECC (Execution Context & Control). Не из-за моделей или API, а из-за архитектуры стеков, которые выглядят красиво на демо, но «умирают» под реальной нагрузкой.

Где теряется производительность: что реально тормозит агентов

В большинстве проектов производительность агентов упирается не в скорость работы LLM (того же Claude или GPT-4), а в узкие места ECC: это инициализация контекста, медленный доступ к памяти, и субоптимальные цепочки вызова функций. Например, в одном проекте на Supabase + self-hosted Postgres при массовой обработке задач задержки в очередях достигали 2–3 секунд на каждом шаге. Это не «медленный inference», а неудачное проектирование пайплайна данных.

Типовые ошибки:

Каждый агент пересоздаёт Execution Context для каждого запроса, хотя можно шарить его между задачами.
Используется heavy-weight ORM для доступа к памяти, вместо прямых SQL-запросов через async-пулы.
Не реализован cache layer для часто используемых фрагментов памяти или промежуточных результатов.
Вызовы внешних сервисов (например, n8n workflow) не оптимизированы по пакетной обработке.

Оптимизация памяти: не только скорость, но и стабильность

Память — не только про хранение истории или RAG-фрагментов, но и про скорость доступа и изоляцию данных между агентами. Я видел, как в одном проекте память агента «раздувалась» в Postgres до 700K строк всего за неделю, из-за отсутствия политики TTL и отсутствия индексации по ключевым полям.

Проблема	Видимый эффект	Решение
Рост таблиц памяти (memory table bloat)	Задержки 1–2 сек на SELECT	TTL, индексация по session_id, регулярный VACUUM
Отсутствие cache	Повторные обращения к одним и тем же данным	Redis/LRU cache поверх Postgres/Supabase
Слабая изоляция данных	Конфликты при параллельных запросах	Сессии на уровне ECC, row-level locks

Реальные паттерны оптимизации ECC-стека

Если вы строите production-grade агента под DACH-маркет (DSGVO, ISO 27001), каждый микросервис и каждый агент должен работать под нагрузкой без деградации. Вот что реально работает:

1. Контекст инициализации — не пересоздавать зря


from contextvars import ContextVar

agent_context = ContextVar("agent_context")

async def get_context():
    ctx = agent_context.get(None)
    if ctx is None:
        ctx = await load_context_from_db()
        agent_context.set(ctx)
    return ctx

Контекст на уровне запроса позволяет не пересоздавать сложные объекты для каждого шага агента.

2. Асинхронный пул соединений для памяти


import asyncpg

pool = await asyncpg.create_pool(dsn="postgres://user:pass@db/agents")

async def get_memory(agent_id):
    async with pool.acquire() as conn:
        row = await conn.fetchrow("SELECT * FROM memory WHERE agent_id = $1", agent_id)
        return row

Асинхронный пул снижает время ожидания и уменьшает нагрузку на Postgres.

3. Кэширование промежуточных результатов


import aioredis

redis = await aioredis.create_redis_pool("redis://localhost")

async def get_cached_memory(key):
    value = await redis.get(key)
    if value:
        return value
    value = await heavy_db_lookup(key)
    await redis.set(key, value, expire=600)
    return value

Кэширование — обязательный слой для production, особенно если память агента используется часто.

Контроль памяти: TTL, индексация, дедупликация

В одном из кейсов я наловил ситуацию, когда agent memory росла экспоненциально из-за отсутствия TTL и deduplication. В результате, SELECT-запросы занимали до 3 секунд, а Postgres начал выбрасывать ошибки по превышению лимита соединений.


CREATE INDEX idx_session ON memory(session_id);
DELETE FROM memory WHERE created_at < NOW() - INTERVAL '7 days';
VACUUM FULL memory;

Еженедельный VACUUM и автоматическое удаление старых записей — норма для production-агентов.

Масштабирование ECC: когда пора переходить на отдельные сервисы

Если у вас более 10 одновременных агентов, стоит вынести ECC-компоненты (контекст, память, очередь задач) в отдельные сервисы с ограниченными API. Это позволяет ограничить зону отказа и ускорить отклик: каждый агент работает с минимальным контекстом, а общие операции (например, логгирование) вынесены в отдельный микросервис.

Паттерн	Плюсы	Минусы
Монолитный ECC (один сервис)	Просто деплоить	Скалируется плохо, конфликт данных
Микросервисы ECC	Изоляция, выше скорость	Сложнее поддерживать

FAQ

Почему агенты медленные, даже если LLM быстрый?

Потому что узкие места — в ECC-слое: медленный доступ к памяти, неэффективное управление контекстом, отсутствие кэша.

Как узнать, что проблема именно в ECC, а не в модели?

Профилируйте latency каждого шага агента. Если задержки между LLM-запросами высоки — ищите в ECC.

Что взять для кэширования памяти?

Для небольших нагрузок — Redis, для крупных — Memcached или shard-решения. Главное — TTL и дедупликация.

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

Вводите TTL, регулярный cleanup, индексацию и дедупликацию на уровне БД.

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

Supabase/Postgres + asyncpg + aioredis показывают стабильные результаты для 10–50 production-агентов.

В каком именно месте ваш pipeline теряет больше всего времени: в памяти, контексте или на очередях задач? Я делаю бесплатный 30-мин аудит стека для фаундеров и CTO, кто собирает AI-агентов в DACH. Пишите в LinkedIn или @ger_dennis_ai.