Почему ваши AI-агенты ломают прод: как локально собирать и использовать данные о неудачных попытках и ошибках агентов

Я — Denis Shokhirev, Enterprise AI architect из Эрлангена, веду DennisCraft AI Studio и за последние 6 месяцев собрал 14 продакшн AI-агентов для B2B в DACH на стеке Claude, Supabase, n8n, Doppler, self-hosted Postgres. Неделю назад в очередной раз словил ситуацию: агент успешно проходит тесты, но в проде ловит edge-case и ломает бизнес-процесс клиента. Не баг в коде — ошибка в цепочке размышлений, которую никто не логировал.

Зачем фиксировать неудачные попытки: реальные сбои и опасности

Большинство AI-агентов в России и СНГ запускают в песочнице или на кастомных демо. Но как только агент идет в прод, начинается хаос: нестандартный ввод, неполные данные, внешние сбои. На трех последних внедрениях я заметил одинаковое: без централизованного сбора ошибок, ретроспектива невозможна, а регрессия превращается в угадайку. Особенно при RAG-архитектуре или сложных workflow через n8n.

В мире стартапов принято надеяться на "запустим — разберёмся". Но если работать в B2B с реальными клиентами, особенно в логистике и финтехе, цена ошибки — потерянная неделя SLA, потенциальный штраф, разрыв контракта.

Стабильность против "просто работает"

Как собирать ошибки локально: архитектурный паттерн

Я не использую облачные "черные ящики". Локальный сбор ошибок — это отдельный сервис рядом с агентом, который логирует все неудачные попытки, входные параметры, трейс стека, и ключевые промежуточные состояния.

Требования к системе сбора

• Сбор по каждому агенту: id, prompt, входные данные, результат, ошибка
• Хранение в auditable-таблице Postgres (желательно Supabase)
• Маскирование персональных данных (DSGVO/152-ФЗ)
• Доступ через UI или API для анализа

Базовая схема таблицы ошибок

CREATE TABLE agent_failures (
    id SERIAL PRIMARY KEY,
    agent_id TEXT NOT NULL,
    input JSONB NOT NULL,
    error_message TEXT NOT NULL,
    stack_trace TEXT,
    intermediate_state JSONB,
    created_at TIMESTAMP DEFAULT now()
);

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

Реализация сбора ошибок на стеке Claude, Supabase, n8n

n8n как оркестратор

В каждом workflow через n8n я добавляю отдельный node "Log Failure" после критических шагов.

// Пример node в n8n для записи ошибки в Supabase
const { createClient } = require('@supabase/supabase-js');
const supabase = createClient(process.env.SUPABASE_URL, process.env.SUPABASE_KEY);

async function logFailure(agentId, input, errorMsg, stackTrace, intermediate) {
    await supabase
        .from('agent_failures')
        .insert([{
            agent_id: agentId,
            input: input,
            error_message: errorMsg,
            stack_trace: stackTrace,
            intermediate_state: intermediate
        }]);
}

Этот же паттерн легко интегрируется с Claude Code через внешние вызовы — не требуется глубокий рефакторинг.

Маскирование данных (PII)

В логах никогда не храню "сырые" персональные данные. Минимум — хэширование email/телефонов, удаление имен, явная пометка полей с PII в схеме. Пример — через bandit или semgrep добавить pre-commit чек на утечку PII в логах. Для российских клиентов — поддержка 152-ФЗ.

Использование ошибок для регрессии и безопасности

Собранные ошибки — это не просто "логи для галочки". Я использую их для:

• Автоматического составления regression-списка (каждый новый релиз — прогон через 10–20 реальных failure-case)
• Валидации безопасности: поиск SQL-injection паттернов, опасных промптов, утечек токенов через gitleaks и semgrep (см. semgrep)
• Построения дашбордов по динамике ошибок (Supabase + Grafana)

Пример регресс-теста на Python

import requests

def replay_failure(agent_url, failure):
    response = requests.post(agent_url, json=failure['input'])
    assert response.status_code == 200
    # можно добавить проверку на ожидаемый результат

# Получаем последние 10 ошибок
failures = get_failures_from_db(limit=10)
for f in failures:
    replay_failure('https://your-agent/api/invoke', f)

Такой подход реально ловит ошибки, которые не воспроизводятся на synthetic data — только с боевыми edge-case.

FAQ

Нужно ли хранить все ошибки навсегда?

Нет. Обычно достаточно хранить 3–6 месяцев. Дальше — архивировать или анонимизировать. Для финтех-клиентов — следите за внутренними стандартами хранения.

Как интегрировать такой сбор в существующий проект?

Добавьте middleware на уровне API/клиента, который ловит и пишет ошибки в отдельную таблицу. Не трогайте core-логику агента — сбор ошибок должен быть orthogonal.

Чем отличается такой подход от Sentry/New Relic?

Sentry хорош для JS/Python-кода, но не видит агентские ошибки уровня LLM. Здесь нужен свой слой, собирающий не только stack trace, но и промпты, входные данные и промежуточные состояния.

Что делать с false positive ошибками?

Рекомендую добавлять ручную разметку через UI или комментарии в базе. На больших объемах — semi-автоматизация через bandit/semgrep для фильтрации технических ошибок.

Как защитить такую таблицу от утечек?

Минимизировать доступ, обязательно шифровать на уровне диска, регулярный аудит через gitleaks и настройка alert-ов по подозрительным insert-ам.

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