Саммари доклада с Infraconf 2026

Как обещал, публикую краткое содержание своего доклада "Особенности observability LLM-приложений и агентов" с конференции Infraconf 2026.

Для начала я провел черту - что вообще мы называем AI-агентом? Этот термин сейчас сильно перегружен. Лично для себя я определяю это так: true agent - это приложение, в котором LLM отдана главная управляющая роль. В агенте именно модель решает: что делать дальше, как это делать и когда пора закончить.

Отсюда легко вывести то, что агентом не является:
• One-prompt приложения. Если LLM дергается для утилитарной задачи вроде суммаризации текста или определения интента — это просто интеграция, а не агент.
• Жёсткие workflow. Когда разработчик заранее продумал и захардкодил весь граф выполнения процесса — это, возможно, самая стабильная автоматизация на рынке, но в строгом смысле тоже не агент.

Полноценному агенту помимо "мозга" (самой модели) нужны "руки" (tools вроде сторонних API или CLI), релевантные данные (типа RAG) и оркестратор, который управляет контекстом. И как только мы начинаем строить и мониторить такие системы (а как без мониторинга в продакеше то?), классические подходы к мониторингу получают неожиданные особенности.

1. Большие тексты стали главным источником правды
В классических приложениях поведение объясняется кодом: открыл метод и шаг за шагом читаешь логику. В агентах код не детерминирован, им управляет модель на основе данных в контексте. Системные промпты, история диалога, сырые ответы tools - это большие тексты, которые влияют на его работу сильнее всего. И если ты не видишь их, то восстановить логику и понять, почему агент свернул не туда, невозможно.

2. Трейсы вместо логов
На первых порах кажется, что тут нужно знаписать все в логи и будет норм. Но если дампить туда все промпты и ответы модели, логи превращаются в нечитаемое месиво из JSON-ов, размазанное по разным бэкендам. Трейсы сейчас де-факто стали основным сигналом для дебага агентов: они круто визуализируются, держат весь контекст в атрибутах спанов и не теряют смысл при распределенной архитектуре.

3. Метрики стали сложнее
Базовые вещи вроде Time to First Token, tokens per second или количества ошибок никуда не делись. Но проблема в том, что агент ломается тихо и уверенно: по инфраструктурным метрикам все может быть идеально зеленым, а агент будет без тени сомнения генерировать полнейшую дичь. Ошибки стали семантическими. Ну и еще нюанс: метрики обязательно нужно дробить по типам задач (корзинкам), иначе "среднее по больнице" просто потеряет смысл - для одних задач агент делает 5 шагов, а я для других 25. Смешивать метрики таких задач нельзя.

4. Evals для оценки качества
Пожелаем удачи тем, что пишет детерминированные тесты для недетерминированной логики. Чтобы понимать, насколько адекватные решения принимает агент, нужны evaluations (evals). По сути, это автоматизированная оценка контента и качества работы по заранее заготовленным датасетам. Тут же в полный рост встает подход LLM-as-a-judge, когда логику и ответы одного агента проверяет другая модель по специальным промптам.

В следующей посте напишу про практические рекомендации, которые я предлагал в докладе