Как внедрить собственный AI-агент-маркетплейс для Codex, Claude, Copilot и других: что реально работает в 2026

Я — Денис Шохирев, агентный AI-архитектор из Фрайбурга, веду DennisCraft AI Studio и уже третий год внедряю мультиагентные системы в B2B для DACH-клиентов на стеке Claude, Supabase, n8n, Doppler, Postgres. Недавно в одном из проектов логистики пришлось за ночь изолировать «протекающего» агента Copilot, который генерировал SQL-запросы с классическим CWE-89 паттерном — и это на проде, а не в демо (см. live.gerdennisai.com). В 2026-м реальность такова: маркетплейс AI-агентов — если вы строите для бизнеса, а не «играете в песочнице» — это не вопрос красивого UI, а проверки, оркестрации и отказоустойчивости.

Что такое AI-агент-маркетплейс на практике

Под маркетплейсом я имею в виду платформу, где несколько AI-агентов (например, Claude Code, Copilot, Codex) доступны как сервисы, между которыми можно динамически переключаться или оркестрировать задачи. Для B2B это не игрушка — клиенты требуют SLA, контролируемую интеграцию и внятный аудит.

Типовой стек и архитектура

Модульная схема

В продакшене используется event-driven подход: агенты подписаны на очереди задач, а оркестратор (n8n) распределяет задачи и собирает логи. Все вызовы логируются в Postgres, доступ через Supabase-API. Secrets и токены хранятся только в Doppler — ни одной переменной в env-файлах на сервере.

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

В 2024 году команда Stanford CodeML показала, что 38% LLM-генерируемого Python содержит паттерны CWE-89 (SQL-инъекции), источник: arxiv.org/abs/2401.09958. На своих проектах я ловил похожие баги через semgrep и bandit уже после первого деплоя.

Реальный пайплайн проверки

import subprocess

def run_semgrep(file_path):
    result = subprocess.run(
        ["semgrep", "--config", "p/ci", file_path],
        capture_output=True, text=True
    )
    return result.stdout

def run_bandit(file_path):
    result = subprocess.run(
        ["bandit", "-r", file_path],
        capture_output=True, text=True
    )
    return result.stdout

def main():
    code_file = "agent_task.py"
    print(run_semgrep(code_file))
    print(run_bandit(code_file))

Вся генерация кода агентами проходит через этот пайплайн до выполнения. Если bandit ловит SQL-инъекцию или semgrep находит опасный паттерн, задача блокируется и уходит на ручную ревью.

Оркестрация и fallback: как строить отказоустойчивые цепочки

n8n как шина задач

n8n стоит в центре архитектуры: все задачи (например, «сгенерировать SQL», «проанализировать контракт») идут через workflow, где этапы — это вызовы разных LLM-агентов. Ошибка на любом шаге — автоматический fallback на другого агента или уведомление через Slack.

# n8n workflow (фрагмент)
- node: Claude_Code
  action: process_contract
  onError:
    - node: Copilot
      action: retry
    - node: Notify
      channel: slack
      message: "Ошибка на этапе Claude_Code"

Архитектурно важно: хранить все логи, входные/выходные данные и метаданные задач в Postgres через Supabase — чтобы при аудите или инциденте восстановить цепочку событий.

Аудит, логгирование и комплаенс: что спрашивают клиенты

В DACH и даже в СНГ-контрактах сейчас требуют: хранить аудит-трейлы 6-12 месяцев, разделять доступы к токенам, не хранить секреты в открытом виде. Supabase с row-level security и connection auditing позволяет реализовать это на проде.

Пример row-level security

-- Ограничение доступа к логам по пользователю
CREATE POLICY user_logs_policy
ON logs
FOR SELECT
USING (user_id = current_setting('app.current_user')::uuid);

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

FAQ

Где лучше объединять агентов: в одном API или через оркестрацию?

В проде эффективнее держать агентов как отдельные сервисы и связывать через оркестратор (n8n, Airflow). Это проще масштабировать и отлаживать.

Какой способ fallback самый быстрый?

Параллельный вызов 2-3 агентов и выбор первого успешного ответа снижает задержки, но увеличивает нагрузку на API. Важно балансировать.

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

Через общие пайплайны проверки (semgrep, bandit) с едиными критериями. Для каждого агента — отдельный конфиг.

Какие риски при хранении токенов?

Основной риск — утечка через логи или ошибочную настройку прав. Doppler и row-level security в Supabase минимизируют эти риски.

Как автоматизировать аудит?

Логи в Supabase + экспорт в отдельную таблицу для аудита раз в месяц. Можно автоматически отправлять алерты при подозрительных запросах через n8n.

В вашем пайплайне какой этап чаще всего ловит ошибки в проде — статический анализ, runtime sandbox или ручная проверка? Мне реально интересно. Я провожу бесплатный 30-мин аудит стека для основателей, кто строит AI в регулируемых рынках. Пишите в LinkedIn или на @ger_dennis_ai.