Глава 12. SLO для агентных систем¶

1. Начнем с вопроса: как понять, что агент поддержки действительно здоров¶

Продолжим тот же сценарий поддержки.

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

Но после первых разборов возникает следующий вопрос:

Как понять не задним числом, а каждый день, здорова ли система на самом деле?

Вот здесь и появляются SLO.

Обычный uptime отвечает только на вопрос: “Компонент был доступен или нет?”

Для агента поддержки этого мало. Даже если все сервисы формально работают, система уже может быть нездорова:

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

SLO нужны именно для этого: переводить разговор о “здоровье” из ощущения в измеримые цели.

В этой главе это означает прежде всего язык бюджетов. SLO — это еще не процесс реагирования. Они задают, какой уровень деградации, небезопасного поведения, нагрузки на операторов или эрозии качества verifier система может потреблять до того, как другой слой должен будет реагировать.

Роль SLO в этой книге тоже вполне конкретна. Трассы захватывают сырую историю. Оценки производят суждения. Наблюдаемость сохраняет доказательства на масштабе системы. Assurance отвечает на findings. SLO задают бюджет здоровья и бюджет риска, которые платформа имеет право тратить в рабочем режиме.

2. SLO должны описывать поведение запуска, а не здоровье отдельных деталей¶

Очень частая ошибка выглядит так:

• модель отвечает быстро;
• векторное хранилище доступно;
• API тикетной системы жив;
• адаптер почти не падает.

Все это полезно, но ни одна из этих метрик сама по себе не отвечает на главный вопрос:

Получает ли пользователь правильный, безопасный и своевременный результат?

Для агента поддержки важен не uptime отдельной библиотеки, а исход всего запуска:

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

Поэтому SLO для агентных систем лучше строить вокруг поведения на уровне запуска.

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

3. Для этого агента поддержки реально важны пять групп SLO¶

На практике для агентной системы эксплуатационного уровня почти всегда достаточно начать с небольшого набора:

• SLO успешности;
• SLO задержки;
• SLO безопасности;
• SLO стоимости;
• SLO эскалаций.

Этого уже хватает, чтобы видеть не только “система жива”, но и:

• полезна ли она;
• не стала ли она слишком медленной;
• не размывается ли граница безопасности;
• не дорожает ли типовой сценарий;
• не перегружает ли она людей.

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

4. SLO успешности должно быть ближе к задаче, чем к HTTP 200¶

Самая опасная ловушка здесь простая: считать успешным любой запуск, который не упал.

Но для агента поддержки запуск может быть формально “успешным” и при этом плохим:

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

Поэтому SLO успешности стоит привязывать к вещам вроде:

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

У агента поддержки успех должен описывать не “не было исключения”, а “задача реально решена”.

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

5. SLO задержки должно раскладывать задержку по этапам¶

Если ты видишь только общий p95 по запуску, ты знаешь, что система стала медленнее, но не понимаешь почему.

Для того же агента поддержки задержка может уехать в разные места:

• извлечение стало дольше возвращать историю запроса;
• модель начала думать больше из-за раздутого prompt;
• адаптер инструмента долго ждет внешнюю тикетную систему;
• путь подтверждения зависает на человеке;
• очередь фоновых задач начала давить на свежие запуски.

Поэтому полезно смотреть не только на задержку end-to-end, но и на этапы:

• p95 / p99 запуска;
• задержку извлечения;
• задержку span модели;
• задержку выполнения инструмента;
• ожидание подтверждения;
• время ожидания в очереди.

Тогда SLO задержки перестает быть красивой цифрой и становится инструментом диагностики.

Но это все еще бюджетный инструмент, а не контур реагирования. SLO задержки говорит команде, сколько замедления можно терпеть до того, как потребуется действие. Более поздняя глава про заверение уже отвечает за сдерживание, владение и реагирование, когда этот допуск нарушен.

5.1. Бюджет задержки начинается не со скорости модели, а с терпения пользователя¶

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

Если пользователи начинают уходить через 8-10 секунд, то агент с 25-секундным средним временем ответа спроектирован плохо, даже если его метрики качества выглядят высоко.

Именно поэтому полезно думать не только в терминах "ускорить все", а в терминах маршрутизируемого пайплайна:

• быстрый путь для частых и простых случаев;
• более медленный путь рассуждения только для неоднозначных, высокорисковых или необычно сложных запусков.

Практически это часто означает:

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

Тогда SLO задержки перестает быть чисто платформенной метрикой и начинает работать как часть соответствия продукту.

6. SLO безопасности должно жить рядом с надежностью, а не отдельно от нее¶

В агентной системе безопасность нельзя держать как отдельное “приложение по безопасности”, которое живет само по себе. Для эксплуатации это часть системного здоровья.

Для агента поддержки полезно измерять как минимум:

• долю запусков без policy violations;
• долю запусков без cross-tenant retrieval;
• долю операций записи без неизвестного побочного эффекта;
• покрытие подтверждениями для высокорисковых действий;
• долю запусков без инцидентов с чувствительным исходящим трафиком.

Это особенно важно после инцидентов вроде дубля тикета или небезопасной записи памяти: если безопасность не попадает в SLO, команда очень быстро снова начинает оптимизировать систему только по скорости и удобству.

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

flowchart LR
    A["Здоровье агента поддержки"] --> B["Успешность"]
    A --> C["Задержка"]
    A --> D["Безопасность"]
    A --> E["Стоимость"]
    A --> F["Эскалация"]

7. SLO стоимости помогает поймать тихую деградацию раньше инцидента¶

У агентных систем есть неприятная особенность: они могут оставаться “рабочими”, пока экономика уже тихо разрушается.

В этом сценарии поддержки это часто выглядит так:

• извлечение тянет в prompt слишком много контекста;
• модель чаще ходит в инструменты без пользы;
• планировщик делает лишние шаги;
• повторы раздувают запуск;
• сводки памяти начинают занимать лишний бюджет.

Поэтому SLO стоимости полезно считать хотя бы по:

• стоимости на успешный запуск;
• токенам на запуск;
• вызовам инструментов на запуск;
• доле использования дорогой модели.

Если этого нет, команда заметит деградацию слишком поздно: когда агент еще “помогает”, но уже стоит заметно дороже.

7.1. Многоагентное качество должно иметь отдельный бюджет¶

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

Значит, SLO для такого режима не должны ограничиваться “ответ стал лучше”. Нужны отдельные бюджеты:

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

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

7.2. Стоимость агента становится многомерной¶

Переход GitHub Copilot к usage-based billing хорошо показывает операционный сдвиг: agentic usage уже считается не только “сколько запросов к модели было сделано”, а через несколько счетчиков одновременно.² Для Copilot code review GitHub отдельно указывает, что с 1 июня 2026 года review расходует и AI Credits, и GitHub Actions minutes.³

Для архитектуры агента это важный урок. Cost SLO должен видеть не только model tokens, но и:

• input, output и cached tokens;
• tool calls и retry amplification;
• runner minutes, sandbox time или workflow duration;
• parallel branch count и idle wait в long-running tasks;
• review loops, которые повторно прогоняют тот же артефакт;
• storage, trace export и eval replay там, где они заметны в счете.

Иначе продуктовая метрика покажет “один пользовательский запрос”, а инфраструктура увидит несколько моделей, десятки tool calls, минуты runner runtime и повторные проверки. Production agent должен иметь budget gate до fanout и после recovery branch: не только “можно ли сделать это безопасно”, но и “не превращает ли этот путь полезный исход в экономически неуправляемый”.

Cloudflare AI Gateway spend limits показывают, что такой budget gate может жить не только в billing dashboard, но и прямо на runtime path.⁴ Если лимит исчерпан, gateway возвращает 429, а агентная платформа должна трактовать это как нормальный runtime outcome: budget_exhausted, а не как таинственный provider failure. В budget-aware gateway SLO должны покрывать retry/backoff, fallback policy, provider/model choice, per-agent spend limits и trace attribution, чтобы оператор видел, какая capability, tenant, run или automation потратила бюджет. Тогда cost SLO становится control plane, а не отчетом задним числом.

Для автономных агентов здесь важна еще одна граница: бюджет должен быть привязан к идентичности агента, а не только к API key или provider account. Если coding agent, support agent и incident agent идут через один AI gateway, SLO должен различать agent_identity, provider_route, fallback_reason, rate_limit_decision и режим деградации. Иначе fallback на более дешевую или более доступную модель может незаметно изменить качество, safety posture или задержку, а cost dashboard покажет только, что расход снизился. Хороший контракт выглядит так: identity-bound spend limit -> provider routing decision -> fallback/degraded mode -> run-level SLO impact -> trace attribution.

7.3. Sandbox is part of the agent contract¶

LangChain хорошо формулирует практичный sandbox checklist: песочница для агента — это не просто место, где “можно запускать код”, а часть SLO и risk budget.⁵ Если агент умеет писать и исполнять программы, SLO безопасности и стоимости должны видеть сам профиль исполнения:

• isolated filesystem: в рабочую область попадает только нужный набор файлов, mounts и данных;
• limited network access: egress описан как allowlist или brokered proxy, а не как общий интернет;
• resource limits: CPU, memory, wall-clock и process lifetime имеют бюджет до запуска;
• controlled reusability: reuse/snapshot разрешены только там, где риск persistent compromise принят явно;
• kernel-level isolation: execution boundary не полагается только на контейнерную дисциплину host kernel.

Такой список полезен именно как SLO-объект. Если sandbox time растет, resource limits регулярно срабатывают, egress deny становится частым outcome или reuse profile меняется без review, это не “низкоуровневый шум”, а сигнал, что агентный путь стал менее управляемым. В mature release gate sandbox profile должен входить в ту же бюджетную карту, что tokens, approval load и duplicate-write risk.

8. Escalation SLO защищает не систему, а людей вокруг нее¶

Человек в контуре не является бесплатной страховкой.

Если агент поддержки:

• слишком часто запрашивает подтверждение;
• слишком часто уходит в ручную сверку;
• слишком часто перекидывает решение человеку;

он может выглядеть безопасным, но в реальности просто перекладывает хаос на операторов.

Поэтому полезно отслеживать:

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

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

9. Практические правила для дизайна SLO¶

Если нужен короткий набор правил, который реально помогает, он обычно такой:

1. Начинай с исхода на уровне запуска, а не с метрик отдельных компонентов.
2. Success должен описывать решенную задачу, а не просто отсутствие исключения.
3. Safety, стоимость и эскалации должны считаться частью здоровья системы, а не отдельными приложениями к надежности.
4. Latency полезно раскладывать по этапам, иначе она плохо диагностируется.
5. SLO имеют смысл только тогда, когда влияют на решения о раскатке и изменениях.
6. Если контроль релиза зависит от вывода verifier, качество verifier тоже должно входить в модель здоровья.

10. Пример политики SLO для агента поддержки¶

Ниже не “канонические” числа, а пример дисциплины:

slo:
  slo_id: slo-support-ticket-known-effect-v1
  owner: support-operations
  window: rolling_28d
  sli:
    name: known_external_effect_rate
    numerator: runs_with_verified_expected_ticket_effect
    denominator: eligible_ticket_write_runs
    exclusions:
      - synthetic_load_tests
      - operator_cancelled_before_dispatch
    data_source: telemetry.run_complete+ticketing.reconciliation
  target: ">= 99.0%"
  action_on_breach:
    burn_rate_alert: 2h_and_24h
    rollout_action: freeze_expansion
    owner: support-operations
  safety_invariants:
    - name: confirmed_cross_tenant_write
      allowed_count: 0
      action: rollback_and_incident
    - name: blind_retry_after_side_effect_unknown
      allowed_count: 0
      action: freeze_and_reconcile

Главное здесь не точный процент, а воспроизводимый расчет и действие. Полная карточка находится в docs/companion/examples/slo-card-support-ticket.yaml. Нарушение SLO расходует бюджет надежности, а нарушение safety_invariants является жестким блокером и не компенсируется хорошим средним показателем.

Именно эта договоренность превращает метрики в рабочее ограничение. Без нее система может измеряться, но еще не управляется через явные бюджеты здоровья и риска.

И это же чистая граница с assurance. SLO говорят, сколько боли, дрейфа, стоимости, небезопасного поведения или нагрузки на людей платформа может терпеть. Assurance решает, что делать, когда эти бюджеты уже перестали соблюдаться.

Теперь эта договоренность может включать и слой verifier, особенно если раскатка, assurance или классификация после инцидента зависят от его суждений.

11. Простой кодовый пример классификации здоровья¶

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

from dataclasses import dataclass


@dataclass
class RunHealth:
    successful: bool
    latency_ms: int
    policy_violated: bool
    cost_usd: float
    external_effect_known: bool
    required_controls_passed: bool


def classify_run_health(run: RunHealth) -> str:
    if run.policy_violated:
        return "safety_failure"
    if not run.required_controls_passed:
        return "control_failure"
    if not run.external_effect_known:
        return "unknown_external_effect"
    if not run.successful:
        return "task_failure"
    if run.latency_ms > 12_000:
        return "slow_success"
    if run.cost_usd > 0.12:
        return "expensive_success"
    return "healthy"

Это простая модель, но она полезна именно тем, что не прячет операционное качество за формальным “успехом”.

12. Что чаще всего ломается в культуре SLO¶

Проблемы здесь очень повторяемы:

• success считают через HTTP-статус;
• latency видят только по вызову модели;
• safety живет отдельно от надежности;
• стоимость вообще не попадает в модель здоровья;
• человеческая эскалация не считается частью здоровья системы;
• качество verifier предполагается, а не измеряется;
• SLO существуют только на дашборде и не влияют на раскатку.

Если так происходит, SLO становятся декорацией. Команда смотрит на цифры, но не управляет платформой через них.

В этот момент у платформы уже могут быть дашборды, но реального слоя здоровья и бюджетов у нее все еще нет.

13. Быстрый тест зрелости для дисциплины SLO¶

Команде не стоит думать, что у нее уже здоровое управление сервисом, только потому, что она смотрит на uptime, p95 задержки и несколько dashboard-алертов.

Более сильная планка такая:

• здоровье определяется на уровне запуска, а не только на уровне компонентов;
• безопасность, стоимость и эскалации считаются полноправными измерениями здоровья системы;
• успех означает решенную задачу, а не просто отсутствие исключения;
• SLO влияют на решения о раскатке, откате и изменениях;
• люди защищены от тихого переноса нагрузки на них.

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

13.1. Практикум: собрать SLO-карту для одного агентного пути¶

После главы про трассы удобно сделать очень практический переход: взять один реальный путь запуска и превратить его в SLO-карту. Не в общий dashboard, а именно в карту обещаний, нарушений и действий.

Для агента поддержки начни с одной истории:

user_story:
  name: support_ticket_creation
  user_expectation: "получить корректный тикет или понятную безопасную остановку"
  risky_side_effect: create_ticket
  required_controls:
    - policy_precheck
    - tool_policy_decision
    - approval_requested_for_high_risk_write
    - idempotency_key
    - verification_result_for_unknown_side_effect

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

• создан дубль тикета;
• пользователь получил формальный успех при side_effect_unknown;
• подтверждение зависло без владельца;
• система ушла в ручную сверку чаще, чем команда может обслужить;
• новый релиз ухудшил стоимость или задержку без явной пользы.

После этого SLO-карта может выглядеть так:

slo_map:
  path: support_ticket_creation
  success:
    objective: "тикет создан ровно один раз или запуск безопасно остановлен"
    indicator: task_success_without_duplicate_ticket_rate
    target: ">= 99.5%"
    burn_action: "block rollout expansion"
  safety:
    objective: "неизвестный побочный эффект не маскируется под успех"
    indicator: unknown_side_effect_masked_as_success_rate
    target: "0"
    burn_action: "freeze write capability and require reconciliation"
  latency:
    objective: "пользователь видит решение или статус ожидания до потери доверия"
    indicator: end_to_end_p95_ms
    target: "<= 12000"
    burn_action: "route complex cases to slower path explicitly"
  approval:
    objective: "человеческая проверка не становится невидимой очередью"
    indicator: approval_wait_p95_minutes
    target: "<= 30"
    burn_action: "page owner or degrade to no-write mode"
  cost:
    objective: "стоимость растет только вместе с качеством"
    indicator: cost_per_successful_run_delta_pct
    target: "<= 8"
    burn_action: "hold model/prompt rollout"

Хорошая карта SLO сразу отвечает на три вопроса:

1. Что считаем здоровьем? Не “сервис жив”, а “путь дает безопасный и полезный исход”.
2. Какой бюджет можно тратить? Сколько задержки, стоимости, ручной нагрузки или неопределенности допустимо.
3. Что происходит при сжигании бюджета? Кто останавливает расширение релиза, переводит возможность в no-write mode или требует сверку.

Самая частая ошибка — оставить burn_action пустым. Тогда SLO становится декоративной метрикой. В агентной системе SLO должен быть связан с действием: остановить rollout, сузить аудиторию, включить обязательное подтверждение, заморозить пишущую capability, открыть инцидент или добавить eval-регрессию.

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

14. Что делать сразу после этой главы¶

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

1. Есть ли у тебя определение успеха на уровне запуска?
2. Видишь ли ты задержку по этапам, а не только общую?
3. Есть ли SLO безопасности, а не только uptime?
4. Считаешь ли ты стоимость на полезный исход?
5. Видно ли, сколько реальной нагрузки уходит на людей?
6. Влияют ли SLO на решения о раскатке?

Если на несколько вопросов подряд ответ “нет”, значит наблюдаемость у тебя уже появилась, но здоровье системы все еще не управляется через цели качества.

15. Что читать дальше¶

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

16. Полезные справочные страницы¶

• Схема трасс и каталог событий
• Схема записи инцидента

• Схема проверки изменений и шлюза раскатки

• Глава 11. Трассы, спаны и структурированные события

• Глава 13. Офлайн-оценки, онлайн-оценки и регрессионные шлюзы
• Глава 14. Платформенная команда и продуктовые команды
• Часть V. Надежность и наблюдаемость
• Источники