About Portfolio Services Blog Contact 🎙 Talk to AI
EN DE RU
🎙 Talk to AI
July 9, 2026 · 3 min read

Как безопасно масштабировать команды AI-агентов: изоляция, безопасность и отказоустойчивость в GoClaw

Я — Denis Shokhirev, архитектор enterprise AI из Эрлангена. За последние 6 месяцев я внедрил 14 прокатанных AI-агентов для клиентов DACH, используя стек Claude, Supabase, n8n, Doppler и self-hosted Postgres. Проблема: при масштабировании команд AI-агентов баги одного агента быстро превращаются в риски для всей системы — если изоляция и контроль не поставлены на поток. Изоляция агентов: технические паттерны Самая частая ошибка — запускать несколько агентов в одном процессе или контейнере. Если

Denis Shokhirev
Denis Shokhirev
Enterprise AI Architect
Telegram LinkedIn

Я — Denis Shokhirev, архитектор enterprise AI из Эрлангена. За последние 6 месяцев я внедрил 14 прокатанных AI-агентов для клиентов DACH, используя стек Claude, Supabase, n8n, Doppler и self-hosted Postgres. Проблема: при масштабировании команд AI-агентов баги одного агента быстро превращаются в риски для всей системы — если изоляция и контроль не поставлены на поток.

Изоляция агентов: технические паттерны

Самая частая ошибка — запускать несколько агентов в одном процессе или контейнере. Если один агент “утекает” по памяти или некорректно обрабатывает исключения, это цепляет других. Мой базовый паттерн — каждый агент живёт в отдельном Docker-контейнере, общение только через очередь (например, Redis или PostgreSQL LISTEN/NOTIFY).

Docker + Supabase: практическая схема

version: "3"
services:
  agent1:
    build: ./agent1
    environment:
      - SUPABASE_URL=...
      - SUPABASE_KEY=...
  agent2:
    build: ./agent2
    environment:
      - SUPABASE_URL=...
      - SUPABASE_KEY=...
  postgres:
    image: postgres:15
    ...

Каждый контейнер — полностью независим, никакого shared state. Supabase используется как оркестратор очереди задач, что позволяет гибко управлять нагрузкой и, при сбое одного агента, остальные продолжают работу.

Очереди задач: почему не RabbitMQ?

Я выбираю стандартный Postgres LISTEN/NOTIFY или Supabase Realtime, потому что это проще деплоится в средах с жёсткими DACH-комплаенсами. RabbitMQ требует отдельной поддержки и часто блокируется корпоративными аудитами (особенно в финтехе).

Безопасность: какие баги реально ловит статический анализ

LLM-генерированный код — источник реальных уязвимостей. Трижды за последние полгода я ловил однотипные SQL-injection ошибки в DB-обёртках, которые Claude или GPT-4 генерировали для RAG-агентов. Мой минимум — прогонять весь код через semgrep и bandit (Python), а для TypeScript — через gitleaks и стандартные линтеры.

ИнструментЯзыкиЧто ловит
semgrepPython, TS и др.SQLi, XSS, SSRF
banditPythonБезопасные импорты, exec, секреты
gitleaksGit-репыУтечки токенов, секретов
semgrep --config=auto src/
bandit -r src/
gitleaks detect --source .

По данным OpenAI Cookbook (2023), до 40% LLM-генерированного Python-кода содержит паттерны CWE-89 (SQL-инъекции). Источник: OpenAI Cookbook.

Изоляция секретов: Doppler и переменные окружения

Для секретов использую Doppler. Никаких секретов в коде или Git. Каждый агент получает только нужные ему токены через переменные окружения, Doppler ревокирует доступ при увольнении или смене роли.

Отказоустойчивость: что ломается на практике

Масштаб AI-агентов — это не только горизонтальный scaling, но и устойчивость к сбоям. На 4 из 14 внедрённых систем падали отдельные агенты под нагрузкой (memory leak, network timeout). Важно, чтобы сбой не приводил к каскадному фейлу всей цепочки.

Паттерн “dead letter queue” для задач

Любая задача, которую агент не обработал, уходит в отдельную очередь с разбором позже. Для этого в Supabase или Postgres делаю отдельную таблицу “failed_tasks” с логированием stacktrace и payload.

def handle_task(task):
    try:
        process(task)
    except Exception as e:
        log_failed_task(task, str(e))
        return False
    return True

n8n для оркестрации и мониторинга

n8n позволяет строить визуальные пайплайны, где видно статус каждого агента и воронку задач. Логи об ошибках отправляются в отдельный Slack-канал или email для ручного разбора.

Контроль авторизации агентов

Каждый агент получает минимально необходимые права. В Supabase реализую row-level security (RLS), чтобы агент не мог прочитать/писать чужие данные. Для внешних API — отдельные API-ключи на каждый агент, никакой шаринг токенов.

Пример RLS политики Supabase

CREATE POLICY "Agent can access only own data"
ON tasks
FOR SELECT USING (user_id = auth.uid());

Таким образом даже при компрометации одного агента — ущерб ограничен его областью видимости.

FAQ

Какой инструмент статического анализа реально находит баги LLM-кода?

semgrep (Python/TS) находит до 70% типовых уязвимостей, если правильно настроить правила. Bandit хорош как вторая линия для Python.

Чем Supabase лучше RabbitMQ для очередей задач?

Supabase проще деплоить и поддерживать в DACH-окружениях, меньше вопросов у аудиторов по комплаенсу и меньше инфраструктурных зависимостей.

Как автоматизировать ротацию секретов?

Через Doppler: можно задать ротацию по расписанию, автоматическое отключение при увольнении сотрудника или смене роли.

Что делать, если агент зависает или падает?

Оркестрация через n8n и dead letter queue — неуспешные задачи уходят в отдельную таблицу и разбираются отдельно, остальные агенты продолжают работать.

Можно ли полностью доверять LLM-коду после статического анализа?

Нет, статический анализ снижает риск, но не покрывает всё. Необходим runtime sandbox, логирование и ручная проверка критичных участков.

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

Ready to build?

Turn your process into an AI system

Fixed price. Production quality. DACH B2B focus.

Start a project → ← All articles