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

Я — Денис Шохирев, архитектор агентных AI-систем из Фрайбурга. В DennisCraft AI Studio я внедряю production-ready AI для B2B клиентов DACH в логистике, финтехе и промышленной автоматизации. Мой стек: Claude, Supabase, n8n, Doppler, self-hosted Postgres. Недавно я снова столкнулся с типичной болью: после запуска агента на реальную задачу через 2 дня возникли дубли, забытые сообщения и автоскрипты, которые не срабатывают вовремя, пока клиенты видят это онлайн на live.gerdennisai.com. На демо всё красиво — в реале всё ломается.

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

В проде основное узкое место не в LLM или prompt’ах, а в памяти и управлении навыками агента. На трёх последних внедрениях я видел одно и то же: как только агенту нужно вести 50+ диалогов или держать в голове 1000+ фактов, появляются:

• Старые сообщения перезаписываются или теряются
• Навыки (скрипты) начинают срабатывать не в том контексте
• Рост latency — агент начинает «тупить» из-за неэффективных запросов к памяти
• Невозможно отслеживать, почему агент принял то или иное решение

Это не абстракция. Например, в одном проекте у меня агент на Supabase/Postgres через n8n обслуживал 90+ параллельных задач, и уже на 30-й сессии возникли гонки за памятью и сбои в автоматическом выборе действий.

Что такое CowAgent: структура, которой не хватает 90% open-source агентов

CowAgent — это не новая библиотека, а устойчивая архитектурная схема, которую я опробовал в реальных прод-стэках. В основе — три слоя:

Главное: каждый слой масштабируется независимо. Память — через горизонтальное шардирование в Postgres; навыки — через очереди в n8n; интерфейс — через отдельные микросервисы.

Как реализовать память агента на Postgres/Supabase

Классическая ошибка — хранить память просто в виде JSON blob или цепочки сообщений. Это не масштабируется. Оптимально — хранить каждое знание/факт как отдельную сущность с метаданными: тип, источник, приоритет, TTL.

CREATE TABLE agent_memory (
  id SERIAL PRIMARY KEY,
  agent_id UUID NOT NULL,
  fact TEXT NOT NULL,
  fact_type VARCHAR(64),
  source VARCHAR(128),
  priority INT DEFAULT 1,
  expires_at TIMESTAMP,
  created_at TIMESTAMP DEFAULT NOW()
);

CREATE INDEX idx_agent_id ON agent_memory(agent_id);

Такой подход позволяет быстро выбирать релевантные факты для LLM через обычный SQL + полнотекстовый поиск.

Автонавыки: как агент учится на лету без ручного кодинга

В проде нельзя вручную хардкодить все правила. Я использую связку n8n + Claude Code: n8n отслеживает сигналы (новые факты, события), а Claude — генерирует и добавляет новые правила (skills) прямо в базу.

import openai
from supabase import create_client

supabase = create_client(SUPABASE_URL, SUPABASE_KEY)

def add_skill(agent_id, skill_desc):
    supabase.table("agent_skills").insert({
        "agent_id": agent_id,
        "description": skill_desc,
        "created_at": "now()"
    }).execute()

def suggest_skill(context):
    prompt = f"На основе: {context}, какой новый навык нужен агенту?"
    response = openai.Completion.create(
        model="gpt-3.5-turbo",
        prompt=prompt
    )
    return response.choices[0].text.strip()

Это позволяет агенту динамически расширять свой репертуар без ручного переписывания кода. Такой паттерн работает стабильно при 100+ навыках.

Мониторинг и аудит решений агента

На уровне продакшна критично видеть не только итоговое действие, но и путь принятия решения. Я пишу для каждого действия trace в отдельную таблицу:

CREATE TABLE agent_action_trace (
  id SERIAL PRIMARY KEY,
  agent_id UUID NOT NULL,
  action VARCHAR(128),
  context JSONB,
  skill_used VARCHAR(128),
  created_at TIMESTAMP DEFAULT NOW()
);

Дальше можно строить простую визуализацию цепочек решений и выявлять узкие места.

FAQ

Почему обычный RAG не решает проблему памяти?

RAG хорош для поиска фактов, но не для структурированной памяти агента — он не хранит приоритеты, TTL, связи между фактами.

Можно ли заменить n8n на Airflow?

Технически да, но для event-driven навыков и реакций n8n проще и быстрее настраивается.

Какие риски при автогенерации навыков?

LLM может сгенерировать невалидное правило. Я внедряю статический анализ через bandit/gitleaks и ручной аудит новых skills.

Как хранить приватные данные в памяти агента?

Использую Doppler для secrets, доступ к приватным данным жестко ограничен через row-level security в Supabase/Postgres.

Сколько агентов реально выдерживает такая схема?

У меня стабильно работает 120+ агентов при 1000+ фактах и 2000+ действий в сутки на одном сервере (8 vCPU, 32GB RAM).

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