Как я проектировал интерфейс трейсинга для ИИ‑агентов

Привет, меня зовут Егор, я работаю продуктовым дизайнером в команде, которая разрабатывает облачные сервисы для создания ИИ-агентов. Мне нужно было спроектировать интерфейс трейсинга (tracing), который помогает быстро найти проблемное место и понять, как агент пришел к такому результату. В статье расскажу, какой путь я прошел и что получилось.

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

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

Что такое трейсинг

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

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

Кому нужен трейсинг

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

Задачи, которые трейсинг помогает решать:

• Быстро понять, где произошел сбой. Не «все сломалось», а конкретно на каком шаге, в каком вызове и с каким результатом.

• Восстановить ход выполнения запроса. Что агент делал между запросом и ответом: какие шаги делал и в каком порядке.

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

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

Какие задачи решает пользователь в интерфейсе трейсинга

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

• Понять, на каком этапе возникла проблема. Дальше вопрос обычно звучит так: «Где именно сломалось?».

• Увидеть, к чему обращался агент: где была языковая модель, где инструменты, где MCP‑серверы и что туда передавалось или возвращалось.

• Понять, почему итоговый ответ получился именно таким, какая цепочка решений и результатов привела к финалу.

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

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

Что я понял, посмотрев на решения конкурентов

Я изучил несколько решений на рынке, чтобы лучше понять, как в целом устроены интерфейсы трейсинга: как показываются цепочки шагов, ошибки, время выполнения и какие UX‑паттерны используются.

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

Phoenix — дает инструменты для разбора и анализа выполнения: можно переигрывать отдельные шаги, сравнивать результаты и смотреть, как меняется поведение системы. Интерфейс помогает не просто увидеть, что произошло, а разобраться, почему агент пришел именно к такому результату.

OpenLIT — интересен связкой трейсинга и инфраструктуры: шаги агента сопоставляются с GPU‑метриками, что дает дополнительный слой понимания, где возникают задержки.

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

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

В целом, большинство решений сходятся в базовых паттернах: иерархия шагов (traces/spans), возможность провалиться в детали и дополнительные слои анализа — от графов до метрик и оценки качества. При этом общее ощущение получилось довольно четким: единого канонического UX в трейсинге пока нет.

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

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

Как собирались требования и почему это было непросто

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

На этапе сбора требований я общался с инженерами (ML, ИИ, бэкенд, платформа) и разбирал их реальные сценарии работы:

• с чего начинается разбор, когда что-то сломалось,

• что важно увидеть сразу,

• в какой момент они уходят глубже и какие детали смотрят.

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

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

Архитектура раздела трейсинга и логика навигации

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

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

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

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

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

Два типа пользователей и акцент на ошибках

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

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

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

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

Поскольку основной сценарий для технических пользователей — найти сбой, я сделал акцент на ошибках сразу на нескольких уровнях:

• ошибка видна на уровне конкретного шага (span);

• сам трейс помечается как проблемный;

• сессия тоже показывает, что внутри есть ошибка.

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

Что эта задача изменила в моем подходе

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

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

Работа над tracing стала для меня важным опытом. Вот ключевые выводы, которые я для себя вынес:

• UX для ИИ часто ближе к инженерным инструментам, чем к классическим потребительским интерфейсам.

• Задача дизайна иногда — не упростить, а грамотно структурировать сложность.

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

• В молодой сфере дизайнер учится вместе с рынком.

• Хорошие интерфейсы сложных систем почти всегда строятся слоями.

Если вы тоже проектируете observability для агентов или отлаживаете сложные ИИ-системы — делитесь своим опытом в комментариях. Как вы решаете проблему черного ящика? Какие паттерны уже работают у вас?