AgentOps

Дисциплина эксплуатации ИИ-агентов в проде: тот же HADI-цикл (Hypothesis → Action → Data → Insight), но применённый к агентам. Держится на трёх пилларах — observability → evals → cost control. Без неё агент — это black box, который молча падает, галлюцинирует и жжёт бюджет, а классический мониторинг (CPU/RAM/HTTP) этого не видит.

Суть

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

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

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

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

Три пиллара AgentOps

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

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

Пример

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

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

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

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

Связано с

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

Открытые вопросы

  • с чего начинать AgentOps на маленьком проекте — минимальный набор метрик и алертов
  • как считать baseline для AI-специфичных метрик на старте