OpenAI Dots: ваш AI-агент работает 24/7 даже когда вы офлайн — как внедрить и какие риски для бизнеса

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

Почему «24/7-агенты» — не просто боты в Slack

Большинство демо-решений работают только при ручном запуске или в песочнице. В проде всё сложнее: агент взаимодействует с API клиентов, пишет в Postgres, инициирует процессы в n8n, и делает это автономно. Прямой пример: публичный агент работает на live.gerdennisai.com — можно наблюдать в реальном времени.

• Агент не ждёт пользователя — он мониторит события и реагирует сам.
• Системы должны быть устойчивы к сбоям, ошибкам данных, недоступности облака.
• Вопрос не в красивом демо, а в SLA и репутационных рисках.

Архитектура: как работает OpenAI Dots в реальном проде

1. Event-driven pipeline

Базовая схема: события (новый заказ, аномалия, входящее письмо) попадают в очередь (например, Supabase Realtime или через Webhook в n8n), агент поднимает задачу, инициирует цепочку действий. Всё логируется в self-hosted Postgres — только так можно гарантировать трассируемость для аудита.

import supabase_py
from n8n_python import N8NClient

supabase = supabase_py.create_client(url, key)
n8n = N8NClient(api_url, token)

# Получаем новые события
events = supabase.table('events').select('*').execute()
for event in events.data:
    if event['type'] == 'order_created':
        n8n.trigger_workflow('process-order', payload=event)

2. Автоматизация через n8n и Claude

Поток: n8n получает сигнал, вызывает Claude API, результат пишется обратно в Postgres или отправляется через API. Doppler управляет секретами, чтобы исключить «утечку» токенов в логи или исходный код.

• n8n — оркестрация интеграций и последовательности шагов.
• Claude API — обработка текста, принятие решений на основе промтов.
• Supabase/Postgres — хранение состояния, логирование, восстановление после сбоя.

3. Мониторинг и rollback

n8n и Supabase позволяют реализовать паттерн «идемпотентности»: если агент ошибся, процесс можно повторить без дублирования эффектов. Для rollback — храним все промежуточные результаты и промты в отдельной таблице.

CREATE TABLE agent_events (
  id SERIAL PRIMARY KEY,
  event_type TEXT,
  payload JSONB,
  status TEXT,
  created_at TIMESTAMP DEFAULT now()
);

-- Для аудита и восстановления
CREATE TABLE agent_prompts (
  id SERIAL PRIMARY KEY,
  event_id INT REFERENCES agent_events(id),
  prompt TEXT,
  response TEXT,
  created_at TIMESTAMP DEFAULT now()
);

Риски в проде: что реально ломается

Security и аудит: что реально внедрять

Static analysis и runtime sandbox

Только статический анализ не спасёт: даже semgrep и bandit (https://bandit.readthedocs.io/en/latest/) пропускают сложные паттерны prompt injection. Я всегда добавляю runtime sandbox на уровне n8n: каждое действие агента логируется, подозрительные кейсы отправляются в отдельную очередь на ручную проверку.

Аудит промтов и действий

Все промты и ответы сохраняю в отдельной таблице (см. выше). Это обязательное требование в проектах для банков и логистики: если возник инцидент — можно восстановить цепочку событий.

Валидация входящих данных

Контролирую все входящие данные через pydantic или аналогичную схему в TypeScript. Никаких "raw" payloads из Webhook в агента.

from pydantic import BaseModel

class OrderEvent(BaseModel):
    order_id: int
    status: str
    customer_email: str

# Валидация до передачи в агента
event = OrderEvent.parse_obj(raw_data)

FAQ

Какой SLA реально выдерживают такие агенты?

В моих проектах SLA 99.7% на уровне интеграций (n8n + Supabase), но это требует постоянного мониторинга и ручного контроля edge-кейсов.

Можно ли полностью исключить утечку данных через LLM?

Нет. Даже с Doppler и фильтрами в n8n всегда есть риск leakage через сложные промты. Только аудит и ручная проверка дают гарантию.

Какие LLM сейчас реально работают в DACH-банках и промышленности?

Claude (Anthropic), GPT-4 (Azure OpenAI), локальные модели через self-hosted API. Везде — через API gateway и с контролем логов.

Как автоматизировать откат неудачных действий агента?

Храню все операции в Postgres — через уникальный event_id можно откатить только ту цепочку, которая вызвала ошибку.

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

Иметь fallback-логики в n8n (например, уведомление человека), и heartbeat-мониторинг через отдельную таблицу в базе.

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