Глава 26. Наблюдаемость для ИИ-систем, покрытие реестра и телеметрия для обнаружения проблем¶

1. Почему наблюдаемость для агентов нельзя сводить к задержке и ошибкам¶

В обычном сервисе наблюдаемость часто начинается с простого набора:

• задержка;
• доля ошибок;
• пропускная способность;
• использование ресурсов.

Для агентных систем этого недостаточно.

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

Система может:

• не падать;
• отвечать быстро;
• отдавать HTTP 200;
• и при этом вести себя опасно, некачественно или неуправляемо.

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

2. Наблюдаемость здесь нужна не только для отладки¶

У агентной платформы наблюдаемость играет как минимум пять ролей:

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

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

В рабочей среде тебе нужно уметь отвечать и на другие вопросы:

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

3. Какие сигналы здесь действительно нужны¶

Для агентных систем полезный контракт телеметрии обычно включает:

• идентичность запроса;
• run_id, trace_id, session_id;
• идентичность актора и агента;
• происхождение данных извлечения;
• вызовы инструментов;
• права инструментов и принципалы;
• решения политик;
• подтверждения;
• состояние и возраст paused runs;
• сигналы backlog по approval;
• состояние сессий возможностей, причины истечения и статус повторной инициализации;
• выбранная схема оркестрации и линия происхождения делегированных рабочих агентов;
• состояние и возраст фоновых запусков;
• краткие итоги ответа;
• статус маскирования данных;
• выходы проверяющего вроде process_score, outcome_score и failure_attribution;
• активный контракт проверяющего и версию контракта проверяющего;
• набор артефактов, версию, волну поэтапного выпуска и версию контракта.

Чтобы этот список не превращался в свалку полей, его полезно держать как пять групп сигналов:

1. Идентичность и область действия: кто действует, от чьего имени и в какой области клиента и запроса.
2. Доказательства контроля: какие решения политик, подтверждения, квоты и сессии возможностей ограничивали запуск.
3. Состояние исполнения: какая схема оркестрации выбрана, где запуск приостановлен, фоновый или делегированный и как он возобновлялся.
4. Доказательства качества: какие выходы проверяющего, оценочные вердикты и атрибуция отказа связаны с результатом.
5. Контекст выпуска и артефактов: какой набор, версия контракта и волна поэтапного выпуска поддерживали этот запуск.

То есть трассы должны рассказывать не только «что упало», но и:

• кто действовал;
• через какой слой управления;
• с какими правами;
• по каким правилам;
• в рамках какого набора артефактов;
• и с каким внешним действием.

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

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

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

4. Покрытие реестра — это тоже наблюдаемость¶

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

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

Для парка агентов это означает, что ты должен знать:

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

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

5. Поведенческие базовые линии важнее простого объема¶

В агентных системах сигнал «у нас стало больше запросов» сам по себе мало что значит.

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

• неожиданное увеличение рискованных вызовов инструментов;
• рост отказов в подтверждении;
• стареющий approval backlog или stuck paused runs;
• изменение характера записей в память;
• смену обычного профиля извлечения;
• всплеск необычных направлений сетевого выхода;
• всплески capability-session expiry или необычный рост re-init rate;
• несовпадения между approval и resume после interruption;
• неожиданные сдвиги в выборе orchestration patterns или пересечениях worker boundaries;
• рост длины сессии или числа переходов между инструментами.

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

Но она не должна в них растворяться. Наблюдаемость — это доказательная основа, которая позволяет заверению, поэтапному выпуску и функциям реестра опираться на одну и ту же прослеживаемую запись, а не на конкурирующие панели, снимки экрана или воспоминания участников.

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

6. Что значит телеметрия, готовая к обнаружению проблем¶

Такая телеметрия — это не просто «мы что-то пишем в журналы».

Это значит, что телеметрия уже годится для:

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

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

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

Если трассу нельзя связать с approval_id, tool_principal, policy_bundle, contract_version, rollout_wave и доказательствами проверяющего о том, как именно запуск был оценен, то она может быть полезна для отладки, но все еще слаба как доказательный слой.

Рекомендации Microsoft по наблюдаемости делают вопрос покрытия более конкретным: командам стоит измерять долю ИИ-систем, которые вообще отправляют журналы и трассы, долю выпусков, прошедших стандартный набор оценок, и долю сценариев злоупотреблений и безопасности, покрытых телеметрией.¹ Так наблюдаемость перестает быть фразой “у нас есть панели” и становится измеримым производственным обязательством: покрытием инвентаря, покрытием оценок выпуска и покрытием сценариев обнаружения.

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

7. Почему управление без наблюдаемости почти всегда хрупкое¶

Контур управления нередко оформляют как:

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

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

Сильный контур управления требует:

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

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

7.1. Управленческая телеметрия замыкает контур принудительного контроля¶

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

Минимальный контракт замкнутого контура здесь выглядит так:

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

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

• governance_action_id: стабильный идентификатор управленческого действия;
• source_signal: сигнал телеметрии или сценарий обнаружения, который запустил действие;
• decision_owner: роль или команда, отвечающая за решение;
• action_state: open, accepted, waived, contained, closed;
• evidence_refs: ссылки на трассу, вывод проверяющего, решение политики и шлюз раскатки;
• review_deadline: когда действие должно быть пересмотрено или закрыто.

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

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

Именно такая рамка отделяет эту главу и от главы про заверение, и от главы про реестр. Заверение отвечает за сдерживание и реагирование. Реестр отвечает за подотчетность всего парка агентов. Наблюдаемость — это общий слой, который делает обе функции пригодными для аудита.

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

7.2. Наложение контура на NIST AI RMF¶

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

• Govern: decision_owner, review_deadline и покрытие реестра показывают, кто владеет сигналом и какая управленческая очередь должна его закрыть.
• Map: source_signal, покрытие инвентаря и телеметрия путей обхода показывают, какой агент, возможность, клиентский контур или поверхность поэтапного выпуска реально находится в риске.
• Measure: evidence_refs, выходы проверяющего, доли покрытия, сигналы дрейфа и сценарии обнаружения превращают риск в наблюдаемые доказательства.
• Manage: policy_decision_feedback, containment_decision, rollout_gate_input и incident_response_trigger показывают, какое действие контроля последовало из доказательств.

Наложение намеренно остается операционным. Вопрос не в том, упоминает ли панель Govern, Map, Measure и Manage. Вопрос в том, может ли проверяющий провести сигнал телеметрии через владельца, поверхность риска, измерительное доказательство и итоговое действие контроля.

8. Куда исследовательская повестка двигает наблюдаемость дальше¶

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

Из этого для книги полезны две мысли.

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

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

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

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

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

flowchart LR
    A["Покрытие реестра"] --> D["Наблюдаемость агентных ИИ-систем"]
    B["Телеметрия рантайма"] --> D
    C["Доказательства политики и подтверждений"] --> D
    D --> E["Реконструкция инцидента"]
    D --> F["Поведенческие baseline"]
    D --> G["Обнаружение злоупотреблений"]
    D --> H["Доказательства выпуска"]

9. Минимальная политика покрытия наблюдаемостью¶

observability:
  require:
    request_identity: true
    trace_ids: true
    session_ids: true
    policy_decisions: true
    tool_principals: true
    approval_linkage: true
    paused_run_visibility: true
    capability_session_visibility: true
    background_run_visibility: true
    orchestration_pattern_visibility: true
    worker_boundary_visibility: true
    verifier_evidence_linkage: true
    verifier_contract_visibility: true
    contract_version_linkage: true
    artifact_bundle_linkage: true
  kpis:
    min_agent_inventory_coverage_pct: 95
    min_trace_coverage_pct: 95
    min_high_risk_action_trace_pct: 100
  block_if:
    - untracked_high_risk_agent_exists
    - approval_events_not_linked
    - paused_runs_not_visible
    - capability_session_events_not_visible
    - orchestration_pattern_events_not_visible
    - worker_boundary_crossings_not_visible
    - verifier_evidence_not_linked
    - verifier_contract_missing
    - contract_version_missing
    - bundle_version_missing

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

10. Пример простой проверки покрытия¶

from dataclasses import dataclass


@dataclass
class ObservabilityCoverage:
    inventory_coverage_pct: int
    trace_coverage_pct: int
    high_risk_trace_coverage_pct: int
    paused_run_visibility: bool
    capability_session_visibility: bool
    orchestration_pattern_visibility: bool
    verifier_evidence_linked: bool


def observability_ready(state: ObservabilityCoverage) -> bool:
    return (
        state.inventory_coverage_pct >= 95
        and state.trace_coverage_pct >= 95
        and state.high_risk_trace_coverage_pct == 100
        and state.paused_run_visibility
        and state.capability_session_visibility
        and state.orchestration_pattern_visibility
        and state.verifier_evidence_linked
    )

Здесь идея не в цифрах как таковых. Идея в том, что готовность наблюдаемости тоже должна становиться явным шлюзом.

11. Самые частые режимы отказа¶

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

12. Быстрый тест зрелости наблюдаемости для ИИ-систем¶

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

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

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

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

13. Практический чеклист¶

• Знаешь ли ты, сколько агентов реально живет в рабочей среде?
• Какой процент из них вообще шлет структурированную телеметрию?
• Можно ли связать высокорисковое действие с trace_id, approval_id, tool_principal, contract_version, bundle_id, активной схемой оркестрации и доказательствами проверяющего?
• Есть ли поведенческие базовые линии, а не только сырые дашборды?
• Видишь ли ты возраст приостановленных запусков, очередь подтверждений и стареющие фоновые запуски до жалоб пользователей?
• Видишь ли ты ненаблюдаемые агенты как отдельный класс риска?
• Можешь ли ты использовать наблюдаемость как доказательную базу для выпуска, а не только как средство отладки?

Если несколько ответов подряд «нет», то наблюдаемость у тебя уже есть, но она пока не стала частью контура управления.

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

14. Модель доказательности этой главы¶

Эту главу стоит читать как слой готовности доказательств, а не как проверочный список логирования:

• Устойчивые утверждения: агентной системой нельзя управлять, если высокорисковые действия, подтверждения, субъекты, артефакты и доказательства проверяющего нельзя связать постфактум.
• Вендорская практика: современные материалы по наблюдаемости и инвентарю инфраструктуры всё чаще рассматривают покрытие телеметрией и покрытие активов как производственные контроли, а не только средства отладки.
• Практика среды исполнения: структурированные события, проверки покрытия инвентаря, поведенческие базовые линии и поля, готовые к обнаружению, делают трассы пригодными для проверки выпуска и реагирования на инциденты.
• Авторская интерпретация: наблюдаемость агентных ИИ-систем — мост между оценками, заверением, реестром и управлением жизненным циклом.
• Быстро меняющаяся область: продукты трассировки, детекторы и конвейеры телеметрии будут меняться; потребность в атрибутируемых и проверяемых доказательствах — нет.

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

• Схема трасс и каталог событий
• Схема наборов для оценки и правил проверки
• Схема набора политик и контракта подтверждения
• Схема approval
• Схема артефактов жизненного цикла
• Схема проверки изменений и шлюза раскатки
• Схема памяти и извлечения

• Исследовательский фронтир: память, наблюдаемость и надежность многоагентных систем

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

• Глава 13. Офлайн-оценки, онлайн-оценки и регрессионные шлюзы
• Глава 21. Контур заверения: соревновательное тестирование, обнаружение и реагирование
• Глава 25. Поведенческие оценки, контрольные оценки и автоматизированное соревновательное тестирование
• Глава 27. Инвентаризация агентов, реестр и борьба с разрастанием