Собрать демонстрационного AI-агента сегодня занимает один вечер: берётся популярная библиотека, настраивается вызов нескольких внешних функций (tools) и пишется подробный системный промпт. На контролируемом демо агент успешно бронирует переговорку, формирует счет и отправляет уведомление. Но при переносе в промышленную эксплуатацию с тысячами пользователей система начинает деградировать: агент зависает в циклических вызовах, путает параметры методов и генерирует непредвиденные сайд-эффекты.
Переход от «вайб-кодинга» к production-инженерии требует понимания вероятностной природы агентов и внедрения строгих механизмов контроля.
Математика каскадных ошибок
В основе любого агента лежит цикл ReAct (Reasoning + Acting): модель получает ввод, решает, какой инструмент вызвать, получает результат выполнения инструмента и формирует следующий шаг.
Проблема заключается в мультипликативности ошибок. Если каждый отдельный шаг (выбор инструмента и валидация аргументов) модель выполняет с надежностью 95%, то надежность цепочки из 10 последовательных шагов составляет:
То есть в 40% случаев сложный составной сценарий завершится сбоем. На практике в длинных цепочках надежность падает еще быстрее из-за замусоривания контекста: каждый ответ инструмента добавляет шум, сбивая фокус внимания модели.
Архитектурные ограничения вместо свободы действий
В демонстрационных скриптах агенту часто дают полный доступ к списку функций и право самостоятельно определять порядок их выполнения. Для продакшна такой подход неприемлем. Надежная архитектура опирается на три принципа:
- Конечные автоматы (State Machines): агент не должен иметь свободного выбора действий на каждом шаге. Переходы между состояниями системы задаются жестким кодом. Модель принимает решения только внутри четко ограниченного узла графа (например, извлекает параметры или выбирает одну из трех допустимых веток).
- Идемпотентность и изоляция сайд-эффектов: функции, изменяющие состояние баз данных или отправляющие внешние запросы (списание денег, отправка писем), не должны вызываться агентом напрямую в цикле рассуждений. Агент формирует черновик операции (intent/payload), который затем валидируется детерминированным слоем бизнес-логики и подтверждается пользователем.
- Ограничение глубины стека (Circuit Breaker): если за 3–4 шага агент не продвинулся к целевому состоянию или повторно вызывает один и тот же инструмент с идентичными аргументами, контур должен прерывать выполнение и переключаться на fallback-сценарий или оператора.
Как уйти от ручного промпт-тюнинга к eval-пайплайнам
В классической разработке стабильность кода обеспечивается юнит- и интеграционными тестами в CI/CD. В разработке на базе LLM тесты часто подменяются ручной проверкой («поправил промпт, проверил на трех своих примерах — вроде работает лучше»).
Любое изменение промпта или обновление весов модели на стороне провайдера приводит к регрессиям: исправление одного пограничного случая ломает два других. Единственный способ контролировать надежность — построение автоматизированного пайплайна оценки (evals):
- Золотой датасет (Ground Truth): формируется выборка из 200–500 реальных запросов пользователей, включающая сложные пограничные случаи, опечатки, попытки взлома (prompt injection) и неполные вводные данные.
- Детерминированные метрики: проверка схемы выходных данных (JSON Schema / Zod), валидность вызовов инструментов, отсутствие недопустимых параметров.
- LLM-as-a-Judge с калибровкой: для оценки качества текстовых ответов используется отдельная модель-оценщик с жесткими рубриками и примерами разметки, результаты которой периодически сверяются с оценками живых инженеров.
- Тестирование в CI: ни одно изменение промпта, модели или параметров температуры не попадает в main-ветку без прогона через полный тестовый датасет с проверкой порога точности (pass rate).
Что это дает бизнесу
Отказ от бесконтрольного агентного цикла в пользу гибридных пайплайнов (жесткий граф состояний + точечный вызов LLM) позволяет снизить долю сбоев с десятков процентов до долей процента. Бизнес получает предсказуемую систему с понятными метриками качества, контролируемым бюджетом на вызовы и гарантией того, что автоматизация не совершит необратимых действий в производственных базах данных.