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

Я — Denis Shokhirev, архитектор агентных AI-систем из Фрайбурга. Мой стек: Claude, Supabase, n8n, Doppler, self-hosted Postgres. На проде у меня крутятся многокомпонентные агентные системы, включая OpenHuman — его работу можно видеть в реальном времени на live.gerdennisai.com. Вот реальная боль: большинство агентных AI-решений так и остаются демо — когда надо масштабировать, всё начинает «сыпаться» из-за архитектуры памяти и оркестрации. Ни один облачный сервис тут не спасает.

Где реально «сыпется» масштабирование агентов

В последние полгода я четыре раза видел один и тот же сценарий: из-за центральной облачной памяти мультиагентная система не выходит за пределы PoC. Как только подключаются реальные пользователи, latency растёт, а стоимость запросов к облаку Memory API начинает съедать маржу. Если вы строите что-то под GDPR или в чувствительных отраслях — облако вообще вылетает из рассмотрения.

Типовая проблема: централизованная память

В классических фреймворках (LangChain, AutoGen) память агента лежит или в облачном векторном хранилище, или в stateful-API. Как итог — каждый запрос идёт через сеть, блокирует задачу и увеличивает риски утечки данных. В реальности, по моим наблюдениям, в 3 из 4 продакшен-кейсов приходится вручную переписывать слой хранения на локальный Postgres, чтобы пройти аудит безопасности (OWASP, GDPR).

Локальная память: паттерн, который реально работает

Что я внедряю в проде: каждый агент пишет свою память (контекст, логи задач, краткосрочные инсайты) в локальную таблицу Postgres. Для быстрого поиска используется встроенный полнотекстовый индекс и pgvector. Это снимает три головные боли сразу:

• Низкая и предсказуемая latency (1-5ms вместо 100+ через облако)
• Контроль доступа и аудит на уровне базы (Postgres audit triggers, Supabase Policies)
• Чёткая граница периметра — никаких сторонних API

Как это выглядит на практике

import psycopg2
from pgvector.psycopg2 import register_vector

conn = psycopg2.connect(dbname="agentdb", user="postgres", password="***")
register_vector(conn)

def save_agent_memory(agent_id, embedding, content):
    with conn.cursor() as cur:
        cur.execute(
            "INSERT INTO agent_memory (agent_id, embedding, content) VALUES (%s, %s, %s)",
            (agent_id, embedding, content)
        )
    conn.commit()

# Пример поиска по embedding
def search_memory(agent_id, query_embedding):
    with conn.cursor() as cur:
        cur.execute(
            "SELECT content FROM agent_memory WHERE agent_id=%s ORDER BY embedding <-> %s LIMIT 5",
            (agent_id, query_embedding)
        )
        return cur.fetchall()

Оркестрация без облака: n8n, Supabase и Doppler

В OpenHuman я ушёл от централизованных оркестраторов типа Temporal или облачных серверов. Основной workflow: n8n в Docker, Supabase (Postgres + Storage), Doppler для секретов, всё внутри закрытого VPC.

Пример простого workflow в n8n

nodes:
  - id: 1
    type: webhook
    parameters:
      path: /agent/task
  - id: 2
    type: postgres
    parameters:
      query: SELECT * FROM agent_tasks WHERE status='pending'
  - id: 3
    type: httpRequest
    parameters:
      url: http://localhost:8080/agent/execute
      method: POST
connections:
  - from: 1
    to: 2
  - from: 2
    to: 3

OpenHuman: что реально видно в проде

OpenHuman — это не демо, а публично доступная продакшен-система. Там вращается 5-10 агентов с разной специализацией (обработка заявок, сбор данных, валидация). Все они пишут и читают память только через локальный Postgres, никакого облачного API. Система работает стабильно при 500+ запросах в минуту, latency на чтение памяти — 3-7 мс, аудит всех действий через Postgres triggers (я использую supabase audit extension).

Что это даёт в реальных кейсах

• Быстрый roll-back: если агент начал «тупить», его память можно откатить на одно действие через SQL.
• Прозрачный аудит: для проверки на GDPR и ISO 27001 достаточно выгрузки из Postgres audit log.
• Нет «скрытых» сетевых зависимостей — инфраструктура полностью on-premise.

FAQ

Можно ли полностью отказаться от облака?

Для памяти и оркестрации — да. Для генерации LLM-ответов (если использовать Claude/OpenAI) — нет, но сам state хранится локально.

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

Если у вас Postgres уже стоит, добавить pgvector и пару audit-триггеров — вопрос пары дней. Реальный кейс: настраивал это для клиента в финтехе за 12 часов.

Что с безопасностью?

Все доступы регулируются через Supabase Policies и audit triggers. Для DACH рынка этого достаточно, чтобы пройти аудит по BSI Grundschutz и GDPR.

Как мониторить агента?

Всё логируется в локальный Postgres: запросы, действия, память. Можно строить любые дешборды через Grafana или Supabase Realtime.

Чем это лучше облака?

У вас нет зависимости от внешних API, latency в 10-30 раз ниже, проще аудит. Особенно критично для медицины, финтеха и госсектора.

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