Как безопасно масштабировать команды AI-агентов: изоляция, безопасность и отказоустойчивость в GoClaw
Я — Denis Shokhirev, архитектор enterprise AI из Эрлангена. За последние 6 месяцев я внедрил 14 прокатанных AI-агентов для клиентов DACH, используя стек Claude, Supabase, n8n, Doppler и self-hosted Postgres. Проблема: при масштабировании команд AI-агентов баги одного агента быстро превращаются в риски для всей системы — если изоляция и контроль не поставлены на поток. Изоляция агентов: технические паттерны Самая частая ошибка — запускать несколько агентов в одном процессе или контейнере. Если
Я — 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 и стандартные линтеры.
| Инструмент | Языки | Что ловит |
|---|---|---|
| semgrep | Python, TS и др. | SQLi, XSS, SSRF |
| bandit | Python | Безопасные импорты, exec, секреты |
| gitleaks | Git-репы | Утечки токенов, секретов |
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.
Turn your process into an AI system
Fixed price. Production quality. DACH B2B focus.