Почему демо лжёт
Демо — это идеальные условия. Стабильный контекст, предсказуемый ввод, внимательный наблюдатель, который готов интерпретировать размытые результаты в лучшую сторону. Продакшен — это хаос: неполные данные, запросы, выходящие за распределение тренировочных примеров, сбои внешних API, пользователи, которые делают ровно противоположное тому, чего ожидала команда.
В нашем случае агент работает с рыночными данными, которые меняются каждые секунды, с транзакциями, которые могут не подтвердиться из-за сетевой перегрузки, и с событиями, для которых в обучающем наборе нет хороших аналогов. Это нормальные условия для любого агента, который не живёт в стерильной среде. Готовьтесь к ним заранее.
Правило: если ваш агент работает только тогда, когда ему подают идеально подготовленные данные — это не агент, это скрипт с LLM. Продакшен-агент должен знать, когда остановиться и запросить подтверждение.
Надёжность и guardrails
Надёжность агента — это не точность его предсказаний. Это предсказуемость поведения при любых входных данных, включая аномальные. Мы выделяем несколько слоёв защиты:
- Input validation: перед тем как данные попадут в LLM, они проходят структурную проверку. Выбросы, пустые поля, аномальные значения — всё это должно обрабатываться детерминированным кодом, а не отдаваться на усмотрение модели.
- Output validation: результат агента проходит проверку бизнес-правилами. Решение за пределами допустимого диапазона блокируется до ревью человека.
- Confidence thresholds: если агент возвращает низкую уверенность или противоречивое рассуждение — действие останавливается, а не выполняется «на авось».
- Rate limiting: на уровне самого агента, не только на уровне API. Агент не должен принимать N критических решений подряд без паузы и проверки.
Границы автономии
Автономный агент — не тот, который делает всё сам. Это тот, который точно знает, когда ему нельзя действовать в одиночку. Мы определяем три класса действий:
Автономные: действия обратимые, цена ошибки низкая, ситуация встречалась в обучающем распределении. Агент решает и логирует.
С подтверждением: действие необратимо или выходит за рамки параметров, которые мы тестировали. Агент предлагает решение, человек подтверждает.
С эскалацией: агент не может принять обоснованное решение — слишком мало контекста, слишком высокая неопределённость. Агент останавливается и объясняет, почему.
Граница между этими классами — самая сложная инженерная задача. Она требует постоянной итерации по результатам продакшен-логов.
Мониторинг и observability
Вы не можете управлять тем, что не видите. Для агентных систем стандартного application monitoring недостаточно. Нужен отдельный слой observability, специфичный для ИИ:
- Трассировка рассуждений: каждый вызов агента логирует не только вход и выход, но и промежуточные шаги — что агент «думал», какие инструменты вызывал, где останавливался.
- Дрейф распределения: мониторинг того, насколько текущие входные данные отличаются от того, с чем агент работал в процессе разработки. Сильный дрейф — это ранний сигнал проблем.
- Failure mode taxonomy: классификация ошибок по типу. Одно дело — агент ошибся в предсказании. Другое — агент нарушил guardrail. Третье — агент завис и не вернул ответ. Каждый тип требует разной реакции.
- Человеческое ревью выборок: не все случаи, но регулярная выборка решений агента просматривается человеком. Это единственный способ поймать систематическое смещение до того, как оно станет дорогостоящим.
Контроль стоимости
В нашем продакшене агенты делают тысячи вызовов в день. При таком объёме стоимость inference — реальная операционная статья. Мы применяем несколько стратегий:
Routing по сложности: простые, структурированные задачи решаются маленькой, дешёвой моделью. Только сложные случаи, требующие рассуждений, поднимаются до флагманской.
Кэширование контекста: переиспользование системного промпта и неизменяемых частей контекста между вызовами снижает объём токенов.
Бюджет по задаче: каждый тип задачи имеет максимальный «токенный бюджет». Агент не может потратить больше — это предотвращает зависание в петлях рассуждений.
Обработка отказов
Что происходит, когда агент не может выполнить задачу? В on-chain контексте «ничего не произошло» — это уже результат, потому что пропущенное действие имеет стоимость. У каждой категории отказа должна быть заданная логика: повтор, эскалация, откат к базовому детерминированному поведению, или явное уведомление.
Самое опасное — «тихий отказ»: агент технически вернул ответ, но ответ семантически пустой или неверный, а система этого не заметила. Защита от тихих отказов требует содержательных eval-проверок на выходе, а не только проверки на наличие ответа.
Что значит «продакшен-grade» на самом деле
Продакшен-grade агент — это не тот, который выдаёт впечатляющие результаты в лучших 80% случаев. Это тот, который безопасно обрабатывает оставшиеся 20%: знает о своих ограничениях, сигнализирует об аномалиях, не совершает необратимых действий в условиях неопределённости. И это — бо́льшая часть реальной инженерной работы.