Короткий ответ: наблюдаемость AI-агентов — это практика фиксации каждого вызова модели, исполнения инструмента и шага рассуждения, которые делает агент, в виде структурированных иерархических трасс, которые можно воспроизвести. Цель — чтобы при ошибке агента в продакшене вы могли ответить на единственный важный вопрос: почему он так поступил? Это не то же самое, что обычный мониторинг. Агент может вернуть «успех», будучи уверенно неправым; пройти разный путь на одинаковом входе дважды; молча провалиться так, как не предусмотрели ваши тесты. Наблюдаемость превращает этот чёрный ящик в то, что можно отлаживать, измерять и улучшать. К 2026 году практика консолидировалась вокруг стандарта OpenTelemetry GenAI, и важны те платформы, которые не просто показывают трассы, а оценивают их.

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

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

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

Первое допущение: одинаковый вход даёт одинаковый выход. Агенты так не работают. По отчётам, вариативность путей исполнения на идентичных входах достигает 63% — то есть один и тот же запрос может вызвать разные инструменты, в другом порядке, на двух соседних запусках. Обычные юнит-тесты, проверяющие, что фиксированный вход даёт фиксированный выход, это валидировать не могут.

Второе допущение: каждый запрос идёт по известному пути в коде. У агента путь ветвится по выходу модели во время исполнения, так что «путь в коде» решается на ходу и каждый раз разный. Статического потока, который можно инструментировать, попросту нет.

Третье допущение: ответ 200 означает успех. Для агента 200 может оборачивать гладкий, правдоподобный и совершенно неверный ответ. Запрос прошёл успешно — агент провалился. Ваш error rate остаётся зелёным, пока качество тихо деградирует.

Поэтому агенты, проходящие все смоук-тесты, всё равно падают в продакшене — и поэтому до него доходят немногие. Индустриальные данные прямолинейны: большинство оценок ставят долю инициатив с AI-агентами, которые так и не доходят до продакшена, выше 80%, а Gartner прогнозирует, что к 2027 году будет свёрнуто более 40% agentic-проектов. Сбои редко случаются на модели. Они происходят в слое вокруг неё — том самом, который обычный мониторинг не видит.

Главный вопрос наблюдаемости: «почему агент так поступил?»

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

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

Что фиксировать в трассе агента

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

  1. Трассу рассуждений — промежуточные размышления и план модели на каждом шаге, а не только финальный вывод.
  2. Рассмотренные инструменты против вызванных — какие инструменты были доступны, какие агент реально вызвал и почему выбрал именно их.
  3. Аргументы и ответы инструментов — точные аргументы, переданные каждому инструменту, и точный ответ, включая ошибки и таймауты.
  4. Токены и стоимость по шагам — входные и выходные токены на каждом вызове модели, чтобы стоимость относилась к конкретным шагам, а не только к запуску целиком.
  5. Задержку по каждому переходу — сколько занял каждый вызов модели и инструмента, чтобы найти медленный шаг в цепочке, которая в целом кажется медленной.
  6. Входы, выходы и метаданные — пользовательский ввод, финальный вывод, модель и её версию, а также идентификаторы (сессия, пользователь, имя агента), позволяющие группировать и фильтровать запуски.

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

Проблема накопления ошибок: почему частичной видимости мало

Есть конкретная причина, почему агентам нужна пошаговая видимость, и она математическая. Ошибки накапливаются по шагам. Агент с точностью 85% на каждом отдельном шаге проходит чистый десятишаговый воркфлоу лишь примерно в 20% случаев, потому что 0,85 в десятой степени — это около 0,2. Точность по шагу, которая звучит отлично, даёт воркфлоу, проваливающийся в четырёх случаях из пяти.

Если ваша наблюдаемость останавливается на уровне запуска — «этот запуск прошёл» или «провалился» — вы видите 80% сбоев, но не их причину. Пошаговые трассы позволяют найти один инструмент или один промпт, который падает с 95% до 70% и тянет всю цепочку вниз. Вы чините слабый шаг, а не гадаете про агента целиком. Поэтому «тупой RAG» (плохое управление контекстом) и «хрупкие коннекторы» (сломанные интеграции инструментов) — такие распространённые и часто упоминаемые паттерны сбоев: это отдельные шаги с тихо низкой надёжностью, незаметные, пока вы не трассируете каждый.

OpenTelemetry GenAI: стандарт, изменивший правила

Главное событие в наблюдаемости агентов — не продукт, а спецификация. Семантические соглашения OpenTelemetry GenAI задают общий словарь для AI-телеметрии: стандартный набор атрибутов спанов и метрик , которые любая библиотека инструментирования может выдавать, а любой бэкенд — принимать.

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

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

Трассировка — это базовый минимум, оценка — отличие 2026 года

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

Это значит автоматическую оценку качества трассы на двух уровнях — метрики на уровне шага (вернул ли этот вызов инструмента нужное? был ли релевантным этот retrieval?) и метрики на уровне трассы (достиг ли весь запуск цели пользователя?). Без обоих инструмент наблюдаемости — это в основном просмотрщик трасс: удобно отладить один запуск руками, слабо — измерять качество на тысячах продакшен-запусков. Вы не можете просматривать каждую трассу вручную, поэтому инструмент должен сам подсвечивать проблемные.

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

Замкнуть цикл: наблюдаемость, evals и непрерывное улучшение

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

Работает так: продакшен-трассы показывают, как агент ведёт себя на самом деле и где он падает. Эти реальные сбои становятся кейсами для оценки — размеченным тестовым набором из реальности, а не из воображения. Дальше evals движут точечные изменения промптов, инструментов, контекста и стратегии рассуждения. Каждое изменение релизится и порождает новые трассы, которые вскрывают следующий набор сбоев, становящихся следующими evals. Наблюдаемость и оценка перестают быть отдельными активностями и становятся одним циклом обратной связи.

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

Две вещи, которые команды делают неправильно: учёт затрат и PII

Два практических вопроса решают, переживёт ли наблюдаемость встречу с реальным деплоем, и оба легко сделать неправильно.

Первый — затраты. Агенты могут быть дорогими неочевидным образом: один пользовательский запрос может разворачиваться в десяток вызовов модели и несколько round-trip к инструментам. Если ваши трассы фиксируют токены по шагам, стоимость перестаёт быть загадочным месячным счётом и становится атрибутируемой: видно, что один шаг рассуждения или один многословный инструмент отвечает за большую часть расходов, и его можно урезать. Команды, не трассирующие стоимость по шагам, обычно узнают о проблеме, только когда о ней спрашивает финансовый отдел.

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

Как подходит к этому Moai Team

Мы инструментируем агентов для наблюдаемости с первого прототипа, а не после того, как что-то сломалось в продакшене. Каждый агент, которого мы строим, выдаёт трассы, нативные для OpenTelemetry — вызовы моделей, вызовы инструментов, токены, задержки и рассуждения, — чтобы плохой запуск всегда можно было воспроизвести и объяснить, а не угадывать. Мы рано связываем эти трассы с eval-харнессом, так что продакшен-сбои становятся тест-кейсами, а каждое изменение измеряется, а не остаётся на надежде. И мы оцениваем на уровне шага, потому что именно там прячется проблема накопления ошибок и обычно живёт настоящее исправление. Смысл не в дашборде, который выглядит занятым; смысл в способности за минуты ответить «почему агент так поступил?» и знать, что вчерашнее исправление тихо не сломало что-то ещё. Это и есть разница между агентом, за которым нервно следят, и агентом, которому можно доверить работу.

Часто задаваемые вопросы

Что такое наблюдаемость AI-агентов?

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

Чем наблюдаемость агентов отличается от обычного мониторинга?

Обычный мониторинг исходит из детерминированного ПО: одинаковый вход — одинаковый выход, известный путь в коде, 200 означает успех. Агенты ломают все три допущения — один и тот же вход может идти разными путями (по отчётам, до 63% вариативности), путь решается во время исполнения, а 200 может оборачивать уверенно неверный ответ. Наблюдаемость фиксирует шаги рассуждения и инструментов, которые обычный APM никогда не видит.

Что такое OpenTelemetry GenAI и почему это важно для агентов?

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

Нужна ли наблюдаемость, если у меня уже есть evals?

Да — они делают разную работу и лучше всего работают вместе. Evals говорят, стало ли изменение лучше, до релиза; наблюдаемость говорит, как агент реально ведёт себя в проде на настоящих «грязных» входах. Сильнейшие команды замыкают цикл: продакшен-трассы становятся новыми eval-кейсами, а evals движут следующий раунд исправлений.

Moai Team строит AI-агентов с наблюдаемостью и evals, встроенными с первого дня, — чтобы при сбое в продакшене вы видели ровно, почему он случился, и чинили его, а не гадали. Запланируйте звонок.