AgentOps: как эксплуатировать AI-агентов в проде без сюрпризов

Агенты уже в проде, а эксплуатировать их некому. Падение агента никто не замечает, пока пользователь не пожалуется. Логи размазаны, SLO нет, runbook — «позвать того, кто внедрял». Так прод превращается в демо, которое иногда работает.

AgentOps — это SRE-подход к агентам: наблюдаемость, SLO, деградация и incident response как для любого сервиса.

Почему агентам нужен AgentOps

Агент — неcron-скрипт, а сервис с недетерминированным поведением. Он ходит в инструменты в цикле, его контекст растёт, он может зациклиться или уйти в долгий retrieval. Без эксплуатации вы не узнаете, что он деградировал, пока не получите инцидент с данными.

AgentOps отвечает на три вопроса продa: работает ли агент сейчас, как быстро он деградирует и что делать, когда он упал.

SLO для агентов

SLO для агента — не «модель отвечает», а пользовательский результат:

Успешность задачи — доля задач, где агент дошёл до ожидаемого результата (по golden-набору);
Латентность — p95 времени задачи, а не одного LLM-вызова;
Стоимость задачи — токены и число tool-вызовов на задачу;
Безопасность — доля задач с попыткой выйти за scope или слить PII (должна быть 0).

Без SLO вы не отличите «стало медленнее» от «показалось» и не поймёте, когда резать фичу.

Трассировка и журнал как база

База AgentOps — журнал каждого tool-вызова с identity, scope, ресурсом и временем, связанный в трейс задачи. На нём строятся и метрики, и разбор инцидента.

Что обязательно в записи:

trace_id задачи + span каждого вызова;
identity (человек → агент → tool);
scope и ресурс (RFC 8707 audience);
классификация данных и решение DLP;
latency и ошибка/ретрай.

Без такого журнала AgentOps — гадание по разрозненным логам LLM-провайдера.

Runbook и graceful degradation

У агента должен быть план деградации, а не «попробовать ещё раз»:

Таймауты и лимиты на retrieval и tool-вызовы — чтобы не раздувать контекст;
Fallback — если агент не уверен, отдать на human-in-the-loop, а не гадать;
Circuit breaker — при серии ошибок отключить агента для этого scope, а не спамить downstream;
Dry-run для пишущих операций — показать diff до выполнения.

Runbook — это не документ, а код: что делает система, когда SLO горит.

Incident response для агентов

Инцидент с агентом — это инцидент с данными и доступом. Playbook:

Зафиксировать trace_id и identity;
По журналу восстановить цепочку tool-вызовов и классификацию;
Отозвать scope/токены агента (lifecycle) — в одном месте;
Поставить блок на DLP-правило, которое не сработало;
Добавить кейс в golden-набор — чтобы регрессия ловилась в CI.

Без шага 5 следующий агент упадёт так же. Подробнее про тестирование — в статье «Как тестировать AI-агентов».

Где Codenik: источник данных для AgentOps

Codenik — источник identity-bound журнала для AgentOps: каждый вызов инструмента с проверенным audience, scope и DLP-решением, связанный в трейс. На этом журнале строятся SLO, алерты и разбор инцидентов — без сборки логов руками по каждому MCP-серверу.

Так AgentOps получает наблюдаемость как у обычного сервиса, а не как у чёрного ящика.

Короткий вывод

Эксплуатируйте агента как сервис: заведите SLO на задачу, пишите трейс каждого tool-вызова с identity и scope, держите runbook с деградацией и playbook с отзывом и добавлением кейса в CI.

Без AgentOps прод с агентами — это демо, которое иногда работает. С ним — управляемый сервис.