Почему ваши AI-агенты падают в проде: 5 ошибок интеграции Codex, Claude Code и agentic harness

Я — Денис Шохирев, архитектор agentic AI-систем из Фрайбурга. В DennisCraft AI Studio я постоянно вывожу мультиагентные системы на прод для B2B-клиентов в DACH. Мой стек: Claude, Supabase, n8n, Doppler, self-hosted Postgres. Как только первый реальный клиент запускает своего агента на живых данных — начинаются сбои, которые демо-скрипт не ловит.

Ошибка 1: Игнорирование статического анализа LLM-кода

Большинство интеграций Codex или Claude Code фокусируется на красивых промптах, но не на безопасности и стабильности сгенерированного кода. Даже если Claude пишет "безопасный" SQL, в трех последних моих внедрениях агенты генерировали куски, уязвимые к SQL-инъекциям. Стандартные инструменты вроде semgrep и bandit отлично ловят очевидные баги — но их почему-то не добавляют в пайплайн.

Реальный пайплайн для проверки LLM-кода

# Проверка каждого сгенерированного фрагмента перед запуском:
semgrep --config=auto generated_agent_code.py
bandit -r generated_agent_code.py
gitleaks detect --source .

Если не делать эти проверки, агент в проде может уронить базу или утечь секреты при первом же сложном запросе.

Ошибка 2: Недостаточная изоляция и сэндбоксинг

Многие рассчитывают на "разумность" LLM и пускают сгенерированный код напрямую в прод-сервис. Это приводит к сбоям, которых не видно на тестовых данных. Я всегда запускаю агентские пайплайны через отдельный контейнер или chroot-окружение, а для особо опасных операций — через отложенный review и ограниченный API.

Пример изоляции кода на Python

import subprocess

def run_in_sandbox(code: str):
    result = subprocess.run(
        ["docker", "run", "--rm", "-v", "/tmp/agent:/app", "python:3.10", "python", "-c", code],
        capture_output=True, text=True, timeout=30
    )
    return result.stdout

Такой подход снижает риск полного падения сервиса из-за одной ошибки агента.

Ошибка 3: Плохая работа с секретами и переменными окружения

LLM-агенты часто генерируют код, который "забывает" про best practices работы с секретами. На практике, если не использовать Doppler или хотя бы переменные окружения с правильными правами, можно легко получить утечку. В одном проекте агент случайно залогировал API-ключ в общий лог — и это сразу ушло в облако.

Как правильно прокидывать секреты

import os

def get_db_conn():
    conn_str = os.environ.get("DATABASE_URL")
    if not conn_str:
        raise Exception("DB URL not set")
    # Не логировать conn_str!
    return connect(conn_str)

Всегда автоматически проверяю, что агенты не вставляют секреты в логи или промпты.

Ошибка 4: Пренебрежение логированием и трассировкой ошибок

Без качественного логирования вы не увидите, что агент делает в проде. В одном кейсе логика Claude Code-агента писала в файл, который не монтировался в контейнере — логи терялись полностью. Я всегда использую централизованное логирование через Supabase или отдельный ELK-стек, плюс отдельные трассировки для каждой сессии агента.

Пример логирования событий агента

import logging

logger = logging.getLogger("agent")
logger.setLevel(logging.INFO)

def agent_action(event):
    logger.info(f"Agent started event: {event['id']}")
    # ...
    logger.info(f"Agent finished event: {event['id']}")

Это позволяет быстро локализовать сбой и понять, где агент "сломал" бизнес-логику.

Ошибка 5: Неполнота тестирования на реальных данных

Демо-данные редко отражают сложность прод-окружения. На реальных данных агенты часто встречают edge-cases, которые ломают пайплайн. Я всегда гоняю агентов на синтетических данных, максимально похожих на прод, и смотрю на outlier-сценарии. Например, в одном fintech-проекте агент "проглотил" невалидный IBAN и отправил ошибку дальше по цепочке — из-за отсутствия проверки формата.

Пример теста на валидацию данных

def test_iban_validation():
    invalid_iban = "12345"
    try:
        validate_iban(invalid_iban)
    except ValueError:
        assert True
    else:
        assert False, "Невалидный IBAN не был пойман"

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

FAQ

Можно ли доверять Claude Code для задач в проде?

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

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

Детальное логирование с уникальным trace_id на каждую сессию агента. Сравниваю логи с эталонным сценарием и ищу отклонения.

Какие инструменты для статического анализа реально работают с LLM-кодом?

semgrep и bandit ловят 80% типовых ошибок Python-кода, включая уязвимости из промптов. Для поиска секретов — gitleaks.

Как организовать безопасную интеграцию с базой данных?

Через отдельный сервис-аккаунт с минимальными правами и обязательной валидацией всех входных данных до передачи в Postgres.

Что делать с ошибками, которые появляются только в проде?

Ввести алерты на нестандартные логи и быстро воспроизводить баги на копии прод-данных в изолированной среде.

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