AgentOps

Суть

Собрать агента на демо легко; довести до реального бизнеса — тяжело. Прод ставит вопросы инфры: как понять, что агент приносит пользу, где он деградирует, почему вырос счёт. AgentOps — это рамка непрерывного улучшения: что-то делаем → замеряем → корректируем → снова делаем. Главный сдвиг мышления: агент — это система принятия решений, а не «умный чат», поэтому эксплуатировать его надо как систему, а не «вроде отвечает нормально».

Почему агенты ломаются в проде (таксономия отказов)

Каскадные галлюцинации — агент придумывает несуществующий факт (например, SKU товара) и передаёт его дальше по цепочке API. Система не падает — результат просто становится неверным, а агент «уверен», что всё сделал правильно.
Runaway / бесконечные циклы — нет явных stopping criteria: инструмент возвращает ошибку → бесконечный retry; цель недостижима → агент перебирает стратегии; баг в tool → зацикливание на одном действии (подробнее в Agent CostControl).
Переполнение контекста — в долгих диалогах (10+ шагов) агент «захлёбывается» нерелевантной информацией и теряет исходную цель.
Коррупция памяти — ошибочные данные, записанные в memory, сохраняются между сессиями и портят будущие решения.
Скрытая недетерминированность — вариативность задержек инструментов и сэмплинга LLM: один и тот же запрос обрабатывается разными путями.

Общее у всех: стандартный мониторинг (Prometheus: CPU/RAM/HTTP) их не ловит — нужны AI-специфичные метрики и трейсинг каждого шага (Agent Observability).

Три пиллара AgentOps

Observability — видеть, что происходит внутри: трейсинг шагов, tool calls, latency, ошибки. Отвечает на «почему агент принял это решение / где сломался» (Agent Observability, инструменты — LangSmith vs Langfuse).
Evals — измеримая оценка качества: от мини-метрик и DoD (Agent Evals) до агентных метрик (DeepEval Agentic Metrics) и судьи (LLM as Judge).
Cost control — бюджеты и защита от runaway/Token DoS, маршрутизация дешёвых/дорогих моделей (Agent CostControl, Agent Routing).

Связка пилларов: трейс деградации метрики → алерт → расследование → фикс → новый прогон evals перед деплоем. Девиз: «процесс важнее инструмента» — простые программные проверки лучше, чем сразу городить сложный self-hosted Langfuse.

Пример

Кейс «мониторинг цен Wildberries» (демонстрационный пример): агентный workflow парсит WB и пишет в Google Sheets.

Agentic scraping — Firecrawl обходит защиты и тащит динамические DOM-контейнеры (цена, материал, фото, SKU).
Обработка — модель DeepSeek V4 переводит описания и считает цены по формулам клиента.
Трейсинг в Langfuse — каждый tool call и шаг перевода фиксируется для анализа задержек/ошибок.

Метрики кейса: Health Score 1.0 (все товары обработаны), ~1 мин/SKU против 5 мин у человека, **$0.012/позиция**.

Контрпример без AgentOps — кейс «пятничный деплой»: агент из-за бага ушёл в бесконечный цикл, сделал 14 000 API-вызовов, сжёг 380 млн токенов и $12 400 за выходные; CPU/RAM при этом были в норме (см. Agent CostControl).

Чек-лист перед выводом в продакшен

Эксплуатационная оптика сводит её к пяти пунктам, каждый из которых проверяется до релиза, а не после инцидента:

Наблюдаемость — подключена трассировка OpenTelemetry / OpenInference со сквозным trace_id через всю цепочку сервисов.
Безопасность — интегрирован слой маскирования персональных данных (DLP for LLM), работают входные guardrail-фильтры.
Отказоустойчивость — состояние вынесено в Postgres, настроены пулы соединений и ретраи, стоит circuit breaker.
Финансы — работают семантический кэш и каскадная маршрутизация (Agent CostControl).
CI/CD — реестр промптов версионирован, прогон по golden set автоматизирован, замеры памяти GPU проходят.

Обязательный минимум логирования, без которого отладка многошаговых сессий не работает: уникальные Session_ID и Trace_ID для сквозного поиска, точный системный промпт на каждом узле графа, сырые аргументы вызовов инструментов и ответы API, латентность и расход токенов на каждую микро-транзакцию. Классическое консольное логирование бесполезно, когда сессия длится пятнадцать минут и состоит из полусотни автономных шагов.

Итоговая формулировка: успешный корпоративный AI-сервис — это десять процентов магии языковых моделей и девяносто процентов классической распределённой инженерии.

SLA: идти от цены ошибки, а не от доступных метрик

Типичный порядок действий — посмотреть, что умеет мерить система, и объявить это метриками. Правильный обратный: сначала определить, что критично бизнесу, и уже под это заводить измерение.

Три принципа экономики AI-сервиса:

Идти от цены ошибки. Метрика существует, чтобы ловить дорогие ошибки, а не чтобы заполнять дашборд.
Максимально автоматизировать расчёт. Метрика, которую считают руками раз в квартал, не влияет на решения.
Разделять технические и продуктовые метрики. Латентность и аптайм — техника; точность и доля ответов без правок — продукт. Смешивать нельзя: зелёный аптайм при упавшей точности выглядит как здоровая система.

Пример набора SLA у агента Data Scout: время обработки — до 2,5 минут на таблицу; точность генерируемых описаний — 85%; экономический эффект как метрика верхнего уровня — экономия клиенту до 50 млн руб.

Верхняя метрика здесь принципиально не техническая. Именно она отвечает на вопрос, продолжать ли платить за сервис, и именно её отсутствие делает разговор о ценности агента бесконечным (см. Unit Economics AI).

Минимальный AgentOps на маленьком проекте

Начинать стоит не с платформы, а с трёх вещей, которые дают ответ на вопрос «что случилось» в инциденте:

Трассировка шагов — хотя бы JSONL: request_id → plan → tool_call → tool_result → final_answer (Agent Evals, пункт DoD). Без неё все остальные метрики бесполезны, потому что непонятно, к чему они относятся.
Три счётчика на операцию — tokens_per_task, cost_per_completion, loop_iterations, с алертом по множителю к p95 за прошлую неделю (Agent CostControl, там же метод расчёта baseline).
Один гейт качества перед выкаткой — небольшой набор кейсов с условием «ноль критичных провалов» (Agent Evals).

Всё остальное — платформы, дашборды, judge-оценки на трейсе — добавляется, когда эти три перестают отвечать на вопросы. Обратный порядок обычно кончается красивым дашбордом, по которому всё равно нельзя разобрать инцидент.

Связано с

Agent Observability — первый пиллар: трейсинг и почему классический мониторинг слеп
Agent Failure Modes — каталог режимов отказа с сигнатурами в телеметрии
OpenInference — стандарт, которым закрывается пункт «наблюдаемость» из чек-листа
Agent Evals — второй пиллар: измеримая оценка качества
Agent CostControl — третий пиллар: бюджеты, Token DoS, runaway
LLM as Judge — автоматизация оценки качества судьёй
LangSmith vs Langfuse — инструменты observability