7 признаков, что ваш AI-агент не масштабируется: чек-лист для CTO и архитекторов

Я — Денис Шохирев, архитектор агентных AI-систем из Фрайбурга. В DennisCraft AI Studio я вывожу в продакшн автономные multi-agent решения для клиентов в логистике, финтехе и индустриальной автоматизации по всей DACH. Мой стек: Claude, Supabase, n8n, Doppler, self-hosted Postgres. На прошлой неделе я поймал баг в бою: агент сливал весь rate limit на второстепенные задачи — типичная история, если архитектура не выдерживает нагрузку в реальном мире.

1. Нет централизованной трассировки задач и коммуникаций

В демо агенты могут работать вслепую, но в продакшне без единой трассировки задач, очередей и обмена сообщениями вы не отловите race conditions, потерянные сообщения, дублирование задач. В моих real-life проектах это первый звоночек: если вы не используете Supabase, PostgreSQL или хотя бы Redis Streams для логирования и очередей — масштабирования не будет.

import supabase
from datetime import datetime

def log_task(agent_id, task, status):
    supabase.table('agent_tasks').insert({
        'agent_id': agent_id,
        'task': task,
        'status': status,
        'timestamp': datetime.utcnow().isoformat()
    }).execute()

2. Отсутствует изоляция агентов и контекстов

Если агенты работают в общем адресном пространстве, любой сбой или утечка памяти может уронить систему целиком. Признак: нет явной separation по workspace, отдельные namespace в Supabase/Postgres не настроены. В бою это проявляется как «один агент завис — все остальные встали».

3. Нет защиты от prompt injection и SQL-инъекций

В 2024 Stanford CodeML исследовании обнаружено, что 38% LLM-сгенерированного Python-кода содержит CWE-89 паттерны SQL-инъекций (источник). В моих деплойментах я ловил подобное через bandit и semgrep. Если у вас нет автоматической проверки LLM-кода на лету — масштабировать опасно.

semgrep --config=auto src/
bandit -r src/

4. Отсутствует контроль rate limit и очередей

Когда агент начинает спамить API или LLM endpoint, быстро упираетесь в лимиты. В n8n я всегда использую queue node с глобальным throttling. Если у вас нет централизованного rate limiter (например, через Doppler + n8n), на нагрузке агенты будут отваливаться или блокировать друг друга.

// n8n queue node пример
{
  "nodes": [
    {
      "parameters": {
        "options": {
          "concurrency": 5,
          "interval": 1000
        }
      },
      "name": "Queue",
      "type": "n8n-nodes-base.queue"
    }
  ]
}

5. Нет автоматизированного тестирования и отката задач

В демо можно вручную проверять pipeline, но в продакшне rollback обязан быть частью архитектуры. Если вы не используете тестовые пайплайны в n8n и transaction management в Postgres — агенты будут оставлять систему в inconsistent состоянии.

6. Непрозрачная авторизация и права доступа

В regulated рынках DACH доступ и аудит — не опция, а требование. Если у агентов нет ограниченных scope access через Supabase policies и audit log, вы не пройдете compliance. Я всегда настраиваю row-level security и отдельные роли для агентов.

-- Пример row-level security в Postgres
CREATE POLICY agent_policy
  ON agent_tasks
  FOR SELECT
  USING (agent_id = current_setting('agent.id'));

7. Нет мониторинга и алертов на production-инциденты

В демо можно смотреть логи вручную, но если у вас нет real-time алертов через n8n или Supabase, инциденты будут оставаться незамеченными. Я интегрирую алерты по SLA: например, если задача висит дольше 5 минут — агент отправляет алерт в Slack или Telegram.

FAQ

Какой стек мониторинга лучше всего подходит для multi-agent AI?

Я использую связку Supabase для логгирования, n8n для алертов и Postgres для хранения исторических данных. Для real-time удобно подключать Grafana.

Можно ли обойтись без централизованной очереди?

В малых демо — да, но в продакшне без очереди (Supabase, Redis, RabbitMQ) рано или поздно столкнётесь с потерей задач или дедлоками.

Как реализовать изоляцию агентов на уровне данных?

Используйте отдельные namespace или row-level security в Postgres/Supabase, чтобы сбой одного агента не затрагивал остальные.

Какие инструменты для статического анализа кода агентов реально работают с LLM-генерацией?

semgrep и bandit для Python, gitleaks для secrets. Их можно автоматизировать в CI/CD pipeline.

Есть ли готовые паттерны для rollback задач агента?

В n8n используйте transaction nodes и обработку ошибок, в Postgres — транзакции и savepoint.

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