Как построить production-ready AI-агента: разбор архитектуры и ошибок

Демо, где LLM вызывает search и запускает shell-скрипт, восхищает ровно до момента, пока вы не попробуете запустить это в проде. Через три часа агент застревает в бесконечном цикле из 35 ретраев, галлюцинирует несуществующий CLI-флаг и выполняет kubectl delete namespace staging — потому что неразобранный 5MB лог вытеснил системные инструкции из контекста.

LLM может сгенерировать правильный одношаговый ответ за 5 секунд. Это не значит, что он способен безопасно управлять инфраструктурой. Production-ready AI-агент — это не модель с доступом к инструментам, а детерминированная, отказоустойчивая, stateful-система вокруг вероятностного движка рассуждений.

Пять способов, которыми наивный агент убивает продакшен

Линейный цикл «User Request → LLM Core → Tool Call → Result» в реальной среде разваливается по пяти сценариям:

1. Галлюцинация параметров. Модель генерирует {"timeout": "ultra_fast"} вместо {"timeout": 300} — и HTTP 400 ломает весь сценарий.
2. Каскадные ретраи. Агент повторяет вызов упавшего инструмента без экспоненциальной задержки и отслеживания изменений состояния. Каждый ретрай усугубляет проблему.
3. Гниение контекста и вытеснение внимания. Сырые стектрейсы и логи раздувают контекст, системные инструкции выпадают из «окна внимания» — агент теряет цель.
4. Непроверенные мутации состояния. Деструктивные DELETE или UPDATE выполняются без pre-flight проверки прав и безопасности.
5. Нулевая наблюдаемость траектории. Если агент — черный ящик, после инцидента невозможно провести post-mortem и понять, почему он сделал то, что сделал.

Математика, которая объясняет, почему длинные сценарии обречены

Успех многошаговой траектории — произведение вероятностей успеха каждого шага. Если на каждом шаге модель ошибается с вероятностью 5% (95% точность), то:

• 3 шага — 85.7% успеха
• 10 шагов — 59.9%
• 25 шагов — 27.7%
• 50 шагов — 7.7%

Экспоненциальный распад надежности — главный аргумент в пользу детерминированных проверок, чекпоинтов и фолбэков. Без них длинные сценарии деградируют в случайный процесс.

Для более точного моделирования агента используется POMDP (частично наблюдаемый марковский процесс принятия решений). Агент не видит истинное состояние среды, поэтому поддерживает байесовское распределение убеждений b(s) и обновляет его через байесовский фильтр после каждого действия и наблюдения. Это позволяет агенту работать с неопределенностью, а не игнорировать ее.

Уравнение Беллмана дает оптимальную стратегию через максимизацию суммы текущего вознаграждения и дисконтированной ценности будущих состояний. На практике это означает: агент должен планировать не только следующий шаг, но и учитывать долгосрочные последствия. Наконец, энтропия Шеннона показывает: чем больше сырых данных попадает в контекст, тем выше неопределенность и тем хуже модель находит «иглу в стоге сена». Поэтому выводы инструментов нужно сжимать в структурированные ключ-значение объекты — это снижает рост памяти с O(N²) до O(N).

Архитектура production-агента: как выглядит безопасная обвязка

Вместо линейного цикла — конвейер с контрольными точками. На входе — API-шлюз и rate limiter. Дальше — runtime-контроллер, который управляет моделью через прокси с кэшем. Состояние хранится в PostgreSQL и Redis-кэше, долговременная память — в векторной базе. Но ключевое — это security-шлюз, который разделяет все действия на уровни риска и пропускает их через человеческое подтверждение (HITL), когда нужно:

Такая градация защищает от косвенных промпт-инъекций, когда злонамеренный текст в логах или на сайте пытается перехватить управление агентом.

ReAct, Plan-and-Execute или Reflexion? Сравнение парадигм

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

Практический чек-лист перед запуском агента в прод

Посмотрите на реальный сценарий: агент получает алерт «P99 latency вырос с 90ms до 3400ms». Он запрашивает метрики, проверяет ресурсы кластера, находит RedisTimeoutError и делает вывод. Каждый шаг логируется, каждое действие проходит через классификатор риска.

Чтобы агент не стал вашим кошмаром, перед деплоем проверьте:

• Есть ли экспоненциальный бэкофф и трекинг мутаций состояния при ретраях?
• Все ли выводы инструментов проходят санитайзер: обрезка, структурирование, удаление чувствительных данных?
• Подтверждает ли человек действия уровня 2 и 3? Или у вас hard-block для опасных операций?
• Ведется ли трассировка каждого шага для post-mortem?
• Может ли агент корректно обработать неоднозначный ответ инструмента, не входя в бесконечный цикл?

Если хотя бы на один пункт ответ «нет» — агент не готов к продакшену. Это не вопрос «дообучить модель» — это вопрос инженерии.