Автор блога призвал мониторить сервисы ИИ-агентами, как «суперфаны» Claude в Anthropic

Поводом стал короткий абзац в недавнем блоге Anthropic (сам автор подчёркивает, что он был не главной мыслью той записи). Команда Anthropic активно использует Claude Tag и завела Slack-каналы, где Claude поручено быть одержимо сосредоточенным на здоровье одного компонента системы. Таких агентов называют «суперфанами»: есть суперфан scion-daemon, суперфан scion-cache, суперфан очереди слияния Antique и так далее. У них есть доступ к телеметрии и логам, и они ведут себя как опытный инженер, которому нечем заняться, кроме как обновлять графики и искать что-нибудь странное. Традиционные оповещения для всех систем тоже остались, но, по словам Anthropic, суперфаны замечают тонкие и новые проблемы, рядом с которыми такие оповещения кажутся одномерными.

Автор блога считает это очевидным путём развития эксплуатации ПО. Его довод: современные системы всё больше «выращиваются», а не «проектируются», объём кода растёт, а доля кода, который реально видел глазами человек-оператор, падает. Мониторинг и раньше был трудным: есть целая индустрия SaaS-сервисов наблюдаемости (Sentry, Datadog, Splunk, Honeycomb), это дорого и требует навыков, которые нарабатываются годами на реальных системах. Автор удивлён, что об агентах в мониторинге так мало пишут практики, хотя стартапов «ИИ-SRE» (SRE, инженерия надёжности сервисов) хватает. По его мнению, для заметного улучшения не нужен ни полноценный «ИИ-SRE», ни готовый SaaS: на моделях класса Opus 5.5 / Astra при некоторой аккуратности вполне можно собрать работающую агентную систему мониторинга.

Как пример автор берёт мониторинг точек изменения (выкладки бинарников и конфигов). Он цитирует банальную строку из книги Google по SRE: около 70% сбоев происходит из-за изменений в работающей системе. Этой задачей он занимается в том или ином виде с 2023 года, и добиться отдачи было тяжело. Известные методы требуют дисциплины от людей (аккуратная разметка метрик и оповещений, точные сигналы) и серьёзных организационных вложений. Если ориентироваться на мотивированные команды с хорошей эксплуатацией, их выкладки и так в основном безопасны, а продаётся лишь снижение рутины. Если подключать все сервисы по общим метрикам здоровья, они шумят, и это даёт низкую точность и усталость от оповещений. До LLM к тому же приходилось выбирать между точностью и задержкой: структурные логи точные, но медленные, метрики быстрые, но грубые, оповещения ещё грубее.

Агенты, по словам автора, во многом «просто» решают эту проблему: они охотно гоняют множество запросов, пишут запросы под каждое изменение на лету и перечитывают логи без устали, так что и точность, и полнота получаются дёшево. В базовом варианте агенту достаточно дать доступ к кодовой базе и к стеку наблюдаемости. Автор набросал прототип: один агент предлагает план мониторинга по коду сервиса, каркас исполняет этот план, второй агент разбирает сработавшие мониторы, а при необходимости вопрос уходит людям. Даже в раннем виде прототип находил регрессии в системах, которых автор совсем не понимает, с точностью и задержкой, невозможными год назад. Важный вывод из его итераций: чистый цикл агента, не лучшая форма. Лучше, когда агент пишет спецификацию мониторинга, а запускает её детерминированная система: сигналы чище, расход токенов заметно ниже. «Секретный соус» здесь, эвристики шумоподавления, промпты, из которых агент пишет хорошие спецификации, и размеченный набор для проверки, достаточно большой, чтобы валидировать дальнейшие правки.

Преимущества агентов автор перечисляет так: следят за всем круглосуточно и не нуждаются в смене по часовым поясам; могут параллельно расследовать несколько версий сбоя (сам он уже запускает пачку агентов на разные гипотезы при разборе инцидента, пока вручную); быстрее читают код, метрики и логи. Здесь он оговаривается: человек с глубоким знанием системы может по-прежнему быстрее найти нужный сигнал и угадать первопричину, а агент обгонит его по скорости лишь в той мере, в какой неявное знание удастся записать и отдать агенту. Для систем, где оператор опытен слабо, время до понимания у агента будет короче. Отдельно автор отмечает, что это становится критичным для инцидентов безопасности: наступательные кибератаки ведут командами и роями агентов, а защитники строят похожие возможности (он называет Daybreak Blue у OpenAI, Project Glasswing у Anthropic и Fairwind у Google).

Практические применения: проявлять больше дотошности (просматривать все Git-коммиты сервиса и ставить краткосрочные быстрые оповещения на изменения, по словам автора, это стоит пару центов за миллион токенов и станет отраслевым стандартом); постоянно улучшать производительность (в одном случае несколько сессий расследования Astra/Opus нашли 50% экономии кучи и снижение задержки на 30% в распространённой библиотеке горячего пути, которую люди уже оптимизировали); действовать, а не только наблюдать (с подходящей обвязкой и ограждениями агенты смогут предпринимать первичные меры: от изменения размера инстансов до отката конфигурации или бинарника и даже поиска причин ошибок и выкладки исправлений, хотя риск растёт с объёмом переданного контроля). Стоимость, по мнению автора, больше не ограничение: модели класса Luna/Haiku (GPT-6-Luna и Claude Haiku 5.5) уже хорошо «смотрят на графики», и крупная технологическая компания, вероятно, сможет мониторить весь парк порядка $100 в день. Итог автора: агентный мониторинг стоит вкладываться, и вскоре будет безрассудно не иметь агентов, следящих за системами.

Ключевые факты

Anthropic рассказала о «суперфанах»: агенты Claude в Slack-каналах следят за здоровьем одного компонента (scion-daemon, scion-cache, очередь слияния Antique) и, по заявлению компании, замечают тонкие проблемы, которые пропускают обычные оповещения.
Автор блога считает агентный мониторинг очевидным будущим эксплуатации и утверждает, что вскоре будет безрассудно не использовать агентов для наблюдения за системами.
Его прототип (агент строит план мониторинга по коду, детерминированный каркас исполняет, второй агент разбирает срабатывания) находил регрессии в незнакомых ему системах; метрик точности и полноты автор не приводит.
Вывод из итераций: чистый цикл агента хуже схемы, где агент пишет спецификацию, а запускает её детерминированная система: сигналы чище, токенов уходит заметно меньше.
Стоимость автор оценивает осторожно: крупная технологическая компания, вероятно, сможет мониторить весь парк порядка $100 в день; полномочия по устранению инцидентов агентам, по его мнению, будут передавать постепенно.

Почему это важно

Автор описывает сдвиг в эксплуатации ПО: кода пишется всё больше, а доля того, что человек-оператор реально прочитал, падает. На этом фоне мониторинг, который и так требовал редких навыков, предлагается отдать агентам, способным круглосуточно просматривать все метрики и логи, а не только то, что превышает «порог человеческого внимания». Поводом стало заявление Anthropic о том, что агенты-«суперфаны» находят то, что не ловят традиционные оповещения. Автор подчёркивает: об этом пока мало пишут практики, хотя стартапов «ИИ-SRE» уже немало.

Кому это важно

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

Как это применить

По описанию автора, для базовой версии достаточно подключить к агенту кодовую базу (чтобы понимать, как используются конфиги) и стек наблюдаемости (чтобы видеть живое состояние продакшена). Его схема: агент пишет план или спецификацию мониторинга по коду сервиса, детерминированная система её исполняет, отдельный агент разбирает сработавшие мониторы и при необходимости эскалирует людям. Он советует вкладываться в эвристики шумоподавления, промпты для хороших спецификаций и размеченный набор для проверки изменений, а предложенные агентами оптимизации производительности пускать через A/B-тесты. Для дешёвого массового наблюдения автор предлагает модели класса Luna/Haiku (GPT-6-Luna и Claude Haiku 5.5). Даже небольшая доработка обвязки под мониторинг, по его опыту, подбирает много лёгких выигрышей.

Можно ли доверять

Это авторское эссе-мнение, а не проверенный результат. Данные о «суперфанах» взяты из блога Anthropic в цитате автора, независимой проверки нет, а сам блог Anthropic в тексте не назван и не датирован ссылкой. Выводы о прототипе основаны на личном опыте автора: метрик точности и полноты, сравнения с эталоном или данных о промышленной эксплуатации нет. Цифра $100 в день названа как осторожная оценка («вероятно», «порядка») без расчёта, а 50% экономии кучи и 30% снижения задержки относятся к одному случаю с неназванной библиотекой.

Риски и подводные камни

Автор сам признаёт, что человек с глубоким знанием системы может быстрее найти сигнал и первопричину, а агент догонит его только по мере того, как неявные знания удастся записать. Передача агентам действий по устранению (откаты, изменение ресурсов, правки кода и выкладка на лету) увеличивает риск пропорционально отданному контролю; такие возможности автор описывает как будущее, а не как внедрённое. Чистый цикл агента, по его опыту, даёт шумные сигналы и расходует много токенов, поэтому нужна детерминированная обвязка. Шум общих метрик здоровья, из-за которого раньше страдала точность, без шумоподавляющих эвристик может вернуться и с агентами.

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

— блог Anthropic о «суперфанах» Claude (цитата в записи автора блога)