Agent SLO

Пять групп

Измерять всё сразу не нужно. Нужен компактный набор, влияющий на пользовательский результат и операционную стабильность.

Успешность — про задачу, а не про отсутствие исключения

Самая опасная ловушка: считать успешным любой запуск, который не упал. Запуск бывает формально успешным и при этом плохим — ответ вернулся, но не помог; статус выдан без обоснования; вместо безопасного уточнения агент сразу создал тикет; тикет создан дважды; система завершила текстом там, где ожидалось действие.

Поэтому цель формулируется ближе к задаче: статус найден и сообщён; действие выполнено ровно один раз и с правильным контекстом; запрос безопасно остановлен или передан человеку там, где это ожидается.

Прямое следствие для дублей: side_effect_unknown, закончившийся слепым повтором, должен считаться ошибкой исхода, а не успешным созданием (Idempotency For Agents).

Задержка раскладывается по этапам

Общий p95 по запуску говорит, что стало медленнее, но не говорит почему. Полезная разбивка: задержка извлечения, задержка спана модели, задержка выполнения инструмента, ожидание подтверждения, время в очереди.

Причины уезжают в разные места и лечатся разным: раздутая подсказка — уплотнением контекста (Context Compaction), медленный адаптер — таймаутами, зависшее подтверждение — путём эскалации (Approval Path).

Важная оговорка про роль: SLO задержки — бюджетный инструмент, а не контур реагирования. Он говорит, сколько замедления можно терпеть до того, как потребуется действие; кто именно действует и как — предмет отдельной дисциплины (Incident Management AI).

Безопасность живёт рядом с надёжностью, а не отдельно

Если безопасность не попадает в SLO, команда очень быстро снова начинает оптимизировать систему только по скорости и удобству. Минимальный набор: доля запусков без нарушений политики, доля запусков без чтения за границу арендатора, доля операций записи без неизвестного побочного эффекта, покрытие подтверждениями высокорисковых действий, доля запусков без утечки в исходящем трафике.

Отдельное измерение, которое легко пропустить, — качество самих проверяющих. Система не вполне здорова, если поведение рантайма выглядит приемлемым лишь потому, что проверяющий стал шумным или слишком доверчивым (LLM as Judge).

Стоимость ловит тихую деградацию раньше инцидента

Агентная система может оставаться рабочей, пока экономика уже разрушается: извлечение тянет в подсказку лишний контекст, модель чаще ходит в инструменты без пользы, планировщик делает лишние шаги, повторы раздувают запуск. Ни одно из этого не даёт ошибки в логах (Cost Anomaly Alerting, Unit Economics AI).

Эскалации защищают людей, а не систему

Самая недооценённая группа. Человек в контуре — не бесплатная страховка: агент, который слишком часто запрашивает подтверждение, уходит в ручную сверку или перекидывает решение человеку, выглядит безопасным, но просто перекладывает хаос на операторов.

Что отслеживать: долю эскалаций, долю подтверждений для высокорисковых потоков, медианное время до решения человеком, долю запусков без ручного вмешательства.

Практический смысл прямой: слишком высокая доля эскалаций делает автоматизацию декоративной — система формально работает, а работу по-прежнему делают люди (Human in the Loop).

Связано с

• Agent Observability — сигналы, из которых считаются эти цели
• AI Observability Stack — панели и пороги на уровне стека
• Agent Evals — оценка качества как вход в SLO успешности
• Idempotency For Agents — почему дубль это ошибка исхода
• Human in the Loop — цена эскалации, выраженная числом
• Cost Anomaly Alerting — стоимость как сигнал деградации
• Incident Management AI — что происходит при нарушении бюджета
• NFR For AI — те же величины на этапе проектирования