Как быстро интегрировать и управлять несколькими AI-агентами без переписывания кода

Я — Денис Шохирев, работаю в Эрлангене (Германия), веду DennisCraft AI Studio. Мой стек — Claude, Supabase, n8n, Doppler, self-hosted Postgres. За последние 6 месяцев я внедрил 14 production AI-агентов для B2B-клиентов из DACH в таких сферах, как логистика, финтех, промышленная автоматизация. Каждый третий запрос от клиента — «добавь нового агента, не ломая старую интеграцию». Вот почему архитектура и управление несколькими агентами — не теория, а ежедневный production-приоритет.

Какую проблему реально приходится решать

На практике интеграция новых AI-агентов в существующие B2B-процессы всегда упирается в три вещи: стабильность (не сломать рабочий сервис), безопасность (никаких дыр через новый код), и скорость (вводить агента за дни, а не недели). Переписывать код под каждого нового агента — не вариант, особенно в проектах с жесткими регуляторными требованиями (например, финтех или логистика).

Шаблонная архитектура: минимальные изменения, максимальная гибкость

1. Абстракция запросов через API Gateway

Первые 3 production-агента я интегрировал напрямую через REST API. После третьей попытки стало ясно — нужно выносить обработку в отдельный слой. Для этого отлично работает n8n как оркестратор, который принимает входящий запрос, определяет нужного агента (по параметру или через маршрутизатор), и прокидывает запрос дальше.

// Типовой маршрут в n8n для переключения агентов
{
  "nodes": [
    {
      "parameters": {
        "functionCode": "return items.map(item => { item.agent = item.json.route === 'finance' ? 'claude_fin' : 'claude_log'; return item; });"
      },
      "name": "Routing",
      "type": "n8n-nodes-base.function",
      "typeVersion": 1
    }
  ]
}

Вся логика выбора агента вынесена в конфиг n8n, никаких изменений в core-коде.

2. Хранилище состояния и логов — Supabase/Postgres

Для отслеживания работы агентов и хранения их состояний (например, какие задачи они выполнили, какие запросы обработали) использую Supabase как managed-интерфейс к Postgres. Это позволяет быстро добавлять новых агентов простым изменением схемы или добавлением новой таблицы, без миграций кода.

-- Пример таблицы для логирования работы агентов
CREATE TABLE agent_logs (
  id SERIAL PRIMARY KEY,
  agent_name TEXT NOT NULL,
  request_payload JSONB,
  response_payload JSONB,
  created_at TIMESTAMP DEFAULT NOW()
);

Такой подход позволяет не только отслеживать работу, но и быстро реагировать на сбои или подозрительную активность.

3. Управление секретами — Doppler

Каждый агент требует отдельные credentials, токены API, ключи шифрования. Не рекомендую хранить их в .env или коде. Doppler централизует все переменные окружения, что позволяет подключать новых агентов без риска утечки ключей.

doppler secrets set CLAUDE_API_KEY=sk-xxxxxx
doppler secrets set LOGISTICS_AGENT_TOKEN=tok-yyyyy

n8n легко интегрируется с Doppler, вытягивая нужные параметры для каждого агента.

Безопасность: что реально работает в production

На собственном опыте: 4 из 14 production-агентов за последние полгода ловили попытки SQL-инъекций в сгенерированных LLM-кодах (особенно при генерации сложных SQL-запросов по пользовательскому тексту). Для минимизации рисков использую:

• semgrep — для статического анализа на паттерны SQL-инъекций и утечек секретов;
• bandit — для анализа Python-кода на типовые CWE;
• gitleaks — для проверки репозиториев на случайную утечку ключей.

semgrep --config=owasp-top-ten .
bandit -r ./src
gitleaks detect --source .

Регулярное сканирование — обязательная часть пайплайна перед выкатыванием нового агента.

Масштабирование: добавляем новых агентов за 1–2 дня

1. Добавление нового агента без переписывания core

Вся интеграция нового агента сводится к добавлению маршрута в n8n, созданию записи в Supabase, и настройке секретов в Doppler. Код основного приложения трогать не нужно. Это реально ускоряет time-to-market: последнего агента для индустриального клиента я внедрил за 36 часов от запроса до production, без единого pull request в основной репозиторий.

2. Валидация и тесты

Для контроля стабильности использую автоматические тесты через Postgres (например, проверка корректности логов и статусов задач), а также ручное ревью всех новых workflow в n8n.

FAQ

Как убедиться, что новый агент не сломает старый сервис?

Все интеграции идут через оркестратор (n8n) и отдельные таблицы состояния в Supabase. Это позволяет изолировать сбои и быстро откатить отдельного агента без влияния на core-функционал.

Насколько сложно внедрять такой подход в legacy-проекты?

Проверено на проектах с 5+ годами legacy: вынести интеграцию в n8n и хранение в отдельные таблицы проще, чем пытаться "вшить" нового агента в старый monolith. Главное — не трогать core-бизнес-логику.

Какие риски безопасности наиболее критичны при добавлении агентов?

Самый частый — SQL-инъекции и утечки секретов. Решаю это через регулярный статический анализ и централизованное хранение секретов.

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

В логах Supabase указываю версию агента и дату релиза. n8n позволяет быстро переключить маршрут на новую версию без изменений в основном сервисе.

Можно ли автоматизировать тестирование агентов?

Да, через тестовые workflow в n8n и проверки состояния задач в Postgres. Это ускоряет QA и снижает риск "тихих" сбоев.

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