Самовосстанавливающиеся AI-агенты: Когда обсервабилити тушит пожар, а не просто сигнализирует о нем

От обнаружения к действию: Новая эра обсервабилити для AI

Наверняка вы знакомы с ситуацией: ваши AI-агенты начинают сбоить, на дашбордах загораются красные индикаторы, трассировки показывают цепочку ошибок, токены улетают в никуда… и что дальше? Обычно, в этот момент в дело вступает человек. Он анализирует данные, находит причину и вручную исправляет проблему. Обсервабилити, в традиционном понимании, прекрасно справляется с задачей «показать, что агент горит». Но оно редко умеет «потушить этот пожар» самостоятельно.

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

Давайте разберемся, как это работает и почему такой подход меняет правила игры в автоматизации и управлении AI-системами.

Три принципа самовосстановления и их фундамент

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

1. Запись всех исходных данных в формате OpenTelemetry, без предварительного агрегирования или суммирования.
2. Оценка этих данных с помощью трехступенчатой системы вердиктов: PASS (пройдено), BREACH (нарушение) или UNKNOWN (неизвестно). Принцип «fail closed» не допускает ложных «нулевых» значений, которые могут скрывать проблемы.
3. Оповещение о вердикте в SigNoz и, при безопасных условиях, немедленное выполнение корректирующих действий.

В качестве фундамента использованы надежные и воспроизводимые инструменты: SigNoz v0.133, развернутый с помощью Foundry (WSL2 + Docker), и локальная модель Ollama (qwen2.5:3b) без облачных сервисов или API-ключей. Каждое обращение к агенту генерирует детальные спаны agent.invoke, llm.chat и tool.* с использованием семантических конвенций OpenTelemetry GenAI, записывая информацию о токенах, стоимости и задержке в метрики.

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

Трек 01: Самовосстанавливающийся SRE-помощник

Первая проблема, которую решал проект, — это «налог на повторные попытки» (retry tax). Когда первый ответ LLM не доходит до адресата, агент запускает инференс повторно, тратя токены вдвойвем. Это идеальный кейс для автоматического исправления: есть реальная телеметрия (дублирующий спан llm.chat с тегом retry.reason = "response_dropped"), есть метрика для SLO (отношение отброшенных ответов к общему числу), и есть несколько вариантов решения, позволяющих модели принять обоснованное решение.

Весь цикл — от обнаружения до проверки исправления — представляет собой единую распределенную трассировку. Обнаружение и верификация происходят с помощью детерминированных запросов signoz_aggregate_traces. Никакие LLM не участвуют в вынесении вердиктов; модель лишь принимает решение о том, что делать с подтвержденным нарушением. Первым шагом она вызывает инструмент read_incident, который, опираясь на два живых запроса к серверу MCP, получает структурированные данные инцидента: частоту повторных попыток, количество отброшенных и повторно запрошенных ответов, а также корневую причину — все это прямо из трассировок, сгенерированных рабочей нагрузкой.

Имея эти данные, локальная модель самостоятельно приняла решение «отключить инъекцию сбоев» (disable_fault_injection) и выполнила его. Результат: частота повторных попыток снизилась с 40% до 0%. И что важно, каждое число в этом отчете — это результат запроса к SigNoz, а не просто вывод в консоль.

Настоящий алерт как триггер, а не cron-задача

Автоматизированный путь исправления не работает по таймеру. Настоящее правило оповещения SigNoz запускает процесс исцеления. Когда частота повторных попыток превышает установленный SLO, SigNoz переводит правило в состояние «активно» (firing), вебхук Alertmanager перехватывает его, открывает спан heal.trigger и запускает управляемый цикл. Точно так же, когда алерт возвращается в состояние «решено» (resolved), цикл понимает, что работа завершена. Алерт и исцеление являются частью одной распределенной трассировки.

Политика безопасности: Защитные механизмы

Разрешать программному обеспечению действовать в продакшене разумно только при условии жестких ограничений. И это тот аспект, который большинство демонстраций автономных агентов часто упускают. Каждое изменяющее действие агента сначала проходит через «политический шлюз». Автономия работает на четырех уровнях (наблюдение, предложение, одобрение, автоматическое действие), и каждое действие несет в себе риски, обратимость и потенциальный радиус поражения. В режиме «авто» с низким порогом риска обратимые действия с низким риском применяются автоматически, в то время как более рискованные действия, например, switch_model, требуют подтверждения человека. Каждое решение записывается в журнал аудита как метрика heal.policy, а если примененное исправление не устраняет нарушение, цикл восстанавливает ранее сделанный снимок системы.

Второй инцидент наглядно демонстрирует ценность этого шлюза. Неконтролируемый агент, застрявший в цикле, может привести к неограниченным счетам. Сенсор измеряет количество вызовов на запрос из трассировок по отношению к потолку SLO в 6 вызовов. Модель читает информацию о «сбежавшем» агенте из SigNoz и активирует предохранитель set_cost_budget. Самый интересный кадр всего проекта — это запись всего политического решения прямо в спане.

Этот предохранитель представляет собой не просто предупреждение, а структурное отключение. Когда запрос превышает бюджет, агент прекращает вызовы LLM и помечает спан agent.request.severed = true. Расходы на запрос упали с 0.000700 до 0.000122 долларов, то есть примерно на 82%. По оценкам, при 100 000 запросов в день это позволяет экономить около 1734 долларов в месяц.

Еще один важный аспект: успешное исправление записывается в верифицированную память SigNoz. Это означает, что при следующем возникновении того же инцидента система исцеляется из памяти без какого-либо обращения к модели, что делает процесс быстрее и не требует калибровки. В одном из тестовых запусков, когда повторно возникло 33% сбоев с повторными попытками, система исцелилась прямо из памяти (это подтверждено уже четыре раза), без вызова модели, со временем восстановления (MTTR) в 149 секунд.

Трек 02: MCP Contract Lab, три сигнала и прокси без кода

Второй трек посвящен инструментации и дашбордам, и те же принципы были применены к самому протоколу Model Context Protocol (MCP).

mcp2_cert — это активный зонд, который сертифицирует сервер MCP на соответствие контракту. Он проверяет операции initialize, tools/list и tools/call, оценивает каждый результат с помощью того же трехступенчатого вердикта и выдает каждый обмен как спан mcp.* со стабильным отпечатком. В отношении сервера SigNoz MCP он возвращает статус CERTIFIED с отпечатком ca5859fcf24f5e03.

Затем был создан пассивный компаньон: постоянно включенный прокси-сервер инструментации (mcp-proxy). Он прозрачно располагается между любым клиентом и сервером MCP и превращает их JSON RPC трафик в спаны mcp.<method> и метрики mcp.client.* без каких-либо изменений кода с обеих сторон. Чтобы доказать его надежность, полная сертификационная батарея была пропущена через прокси. Результат остался CERTIFIED с идентичным отпечатком ca5859fcf24f5e03, при этом прокси независимо выдавал корректно оцененные спаны для каждого вызова. Таким образом, можно инструментировать интеграцию MCP, которая вам не принадлежит, и ничего не потерять.

Все эти данные выводятся на дашборд с тремя сигналами (трассировки, метрики и логи вместе), построенный с помощью SigNoz v5 Query Builder API. Каждая панель дашборда проходит самопроверку с помощью API query_range перед созданием, поэтому панель, которую нельзя разрешить, никогда не отображается.

Трек 03: Энергия, углеродный след и доступность как телеметрия

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

WattTrace GreenOps измеряет джоули и граммы CO2e на каждый верифицированный ответ. Он оценивает каждый токен в энергию на детерминированной основе, сводит оценку к наименее надежному источнику (чтобы запасная оценка никогда не выдавалась за аппаратные показания) и оценивает ее по принципу «fail closed» относительно бюджета. При сравнении контрольной группы с группой, подверженной ошибкам повторных попыток, те же самые верифицированные ответы стоили 753 Дж против 1101 Дж, что означает регрессию энергопотребления на 46%, большая часть которой — чистые потери на повторные вызовы. Таким образом, «налог на повторные попытки» переосмыслен как регрессия устойчивости, о которой можно получать оповещения.

AccessTrace применяет те же самые принципы «fail closed» к веб-доступности. Реальный безголовый браузер проходит WCAG-путь (загрузка страницы, навигация, основной контент, форма регистрации), запускает axe-core на каждом этапе и выдает этот путь как трассировку: access.suite к access.journey к access.step. Ключевая особенность заключается в том, что спаны access.step локализуют, какая часть пользовательского потока нарушается. На неработающей демонстрационной странице вердикт BREACH с взвешенным долгом 40 (две критические и четыре серьезные проблемы на точном этапе сбоя), а ее исправленный двойник набирает 0. Это 100% сокращение проблем, и два живых алерта SigNoz срабатывают на это нарушение.

Синтез треков: Углеродный след становится сенсором для самоисцеления

Вот где три трека перестают быть тремя отдельными проектами. Вердикт по энергии от WattTrace из Трека 03 становится сенсором для самоисцеляющегося агента из Трека 01, считываемым через протокол MCP из Трека 02. Самовосстанавливающийся агент обнаруживает нарушение SLO по углеродному следу, определяемое как доля энергии, затраченной на отброшенные и повторно запрошенные вызовы, и устраняет его через тот же управляемый цикл.

Интересной частью здесь является калибровка. Здоровая рабочая нагрузка с множеством вызовов потребляет около 867 Дж на ответ, что всего на 4% ниже референсного бюджета в 900 Дж для одиночного вызова. Поэтому установка абсолютного порога на этапе проверки могла бы отменить вполне рабочее исправление из-за обычных колебаний количества токенов. Вместо этого, установка порога на долю потраченной впустую энергии не требует калибровки: здоровая группа не тратит энергию впустую, поэтому проверенное исправление никогда не отменяется. В реальном процессе исцеления углеродного следа, выбросы на ответ упали с 0.3275 гCO2e до 0.1183 гCO2e (с 2649 Дж до 958 Дж), и это исправление было записано в память. Один цикл, три трека, одна трассировка.

Как SigNoz был использован на практике

Для реализации этого проекта SigNoz был задействован по максимуму:

• Трассировки: полные деревья спанов agent.heal, watt.suite, access.suite и mcp.*, каждый шаг коррелирован под одним идентификатором трассировки.
• Метрики: heal.slo.breach, heal.mttr, heal.policy, watttrace.energy.consumed, watttrace.carbon.emitted и другие, записываемые параллельно с трассировками.
• Логи: структурированные логи жизненного цикла исцеления, коррелированные с трассировками, так что цикл виден во всех трех сигналах.
• Query Builder v5: каждый детектор и каждая панель дашборда — это программно созданный запрос SigNoz query_range. Обнаружение, диагностика и верификация — это все запросы SigNoz, поэтому цикл построен на поверхности запросов, а не просто указывает на нее.
• Дашборды: пять импортируемых дашбордов (самоисцеление, надежность по трем сигналам, MCP Contract Lab, WattTrace GreenOps и AccessTrace), каждый из которых проходит самопроверку перед созданием.
• Алерты: десять активных правил по всем трекам, и реальный алерт является триггером для исцеления, а не просто уведомлением.
• Сервер SigNoz MCP: модель считывает свои инциденты через него, а прокси инструментирует его.
• Сервисные аккаунты и API-ключи: для программного доступа, а также casting.yaml и casting.yaml.lock Foundry для воспроизведения всей системы.

Честный взгляд на сложности: Что важно учесть

Хакатон требовал реального опыта, поэтому вот что на самом деле вызывало трудности:

• Малые модели и вызовы инструментов: маленьким моделям нужен строгий контроль для вызова инструментов. Например, llama3.2:3b постоянно генерировала некорректные вызовы, поэтому пришлось перейти на qwen2.5:3b. Даже с ней, промпт должен был четко указывать, что read_incident только читает и за ним должно следовать исправление.
• LLM вне критического пути: держите LLM подальше от горячего пути надежности. Обнаружение и верификация остаются детерминированными, модель только принимает решения, а SigNoz выносит вердикты.
• Эффект наблюдателя: он реален. Модуль исцеления и рабочая нагрузка запускаются как отдельные сервисы, и каждый запрос привязан к одному тегу когорты.
• Задержки CPU-инференса: инференс на CPU действительно медленный, от 10 до 110 секунд на вызов. Это означает, что задержки реальны, и MTTR (среднее время восстановления) действительно имеет значение.
• Принцип «fail closed»: все должно работать по принципу «fail closed». Если выполнение не может быть оценено, оно получает статус UNKNOWN, а не ложный PASS. Нулевое показание энергии — это сломанное измерение, а не «бесплатная» работа.

Попробуйте это сами

Весь проект воспроизводим и доступен на GitHub: github.com/gajanangitte/observable-agent. Вы можете развернуть то же самое окружение SigNoz, используя предоставленные файлы casting.yaml, и запустить каждый инцидент одной командой. 234 автономных юнит-теста охватывают логику оценки офлайн.

Обсервабилити, которое действует — в вопросах надежности, протоколов, углеродного следа и доступности. Оказывается, самым сложным было не действие, а доказательство с помощью телеметрии, что «пожар потушен», бюджеты ограничены, углеродный след сокращен, а вход открыт для всех. Этот подход — мощный шаг к по-настоящему автономным и ответственным системам, и его принципы могут быть адаптированы для любой платформы автоматизации, включая n8n, чтобы создавать более устойчивые и умные рабочие процессы.