Привет, меня зовут Егор, я работаю продуктовым дизайнером в команде, которая разрабатывает облачные сервисы для создания ИИ-агентов. Мне нужно было спроектировать интерфейс трейсинга (tracing), который помогает быстро найти проблемное место и понять, как агент пришел к такому результату. В статье расскажу, какой путь я прошел и что получилось.
Работа с ИИ-агентом выглядит так: пользователь задает запрос, агент отвечает и по пути обращается к языковой модели, инструментам и внешним сервисам. Когда результат получается неожиданным или агент ошибается, понять причину, почему так вышло, сложно: между запросом и ответом скрывается цепочка действий.
Важно, что у агентных сценариев одна особенность: это уже не один вызов модели — один ответ. Агент может планировать шаги, пересобирать план, вызывать инструменты каскадом, возвращаться к уже пройденным шагам и попадать в смысловые циклы. Из‑за этого путь выполнения легко становится непрозрачным и недетерминированным, и без трейсинга разбор превращается в догадки.
Что такое трейсинг
Трейсинг — это цепочка действий агента по шагам, которая позволяет увидеть, что происходило внутри системы, в каком порядке выполнялись задачи и где возникла проблема. Эта запись отражает полный путь одного запроса через систему — от входа до результата.
Трейс состоит из последовательности шагов (span), где каждый шаг фиксирует отдельную операцию: вызов модели, обращение к инструменту или внешний запрос. Каждый шаг содержит контекст выполнения: входные и выходные данные, длительность и статус — это позволяет не просто видеть результат, а разбирать сам процесс: как агент принимал решения, какие действия выполнял и где возникли отклонения или ошибки.
Кому нужен трейсинг
Трейсинг — это про отслеживание и мониторинг работы агента: чтобы понимать, что пошло не так, и быстро находить причину. В первую очередь он нужен опытным пользователям, которые отлаживают и улучшают систему: ИИ- и ML‑инженерам, бэкенд‑разработчикам и платформенным разработчикам.
Задачи, которые трейсинг помогает решать:
Быстро понять, где произошел сбой. Не «все сломалось», а конкретно на каком шаге, в каком вызове и с каким результатом.
Восстановить ход выполнения запроса. Что агент делал между запросом и ответом: какие шаги делал и в каком порядке.
Разобраться в причинах, даже если явной ошибки нет. У агентов проблемы часто проявляются не как классическое падение, а как некорректное поведение: бессмысленные повторы, неудачные вызовы инструментов, потеря контекста.
Увидеть, где теряется время. В трейсинге хорошо заметны аномально долгие шаги и повторяющиеся участки.
Какие задачи решает пользователь в интерфейсе трейсинга
Когда пользователь открывает трейсинг, он обычно приходит за довольно конкретными действиями:
Понять, на каком этапе возникла проблема. Дальше вопрос обычно звучит так: «Где именно сломалось?».
Увидеть, к чему обращался агент: где была языковая модель, где инструменты, где MCP‑серверы и что туда передавалось или возвращалось.
Понять, почему итоговый ответ получился именно таким, какая цепочка решений и результатов привела к финалу.
Сравнить шаги по длительности, чтобы быстро увидеть узкие места и аномалии.
Конечная цель этого интерфейса простая — помочь опытному пользователю быстро найти причину проблемы и понять, что именно стоит улучшать: промпт, инструмент, обработку ответа, таймауты или логику агента.
Что я понял, посмотрев на решения конкурентов
Я изучил несколько решений на рынке, чтобы лучше понять, как в целом устроены интерфейсы трейсинга: как показываются цепочки шагов, ошибки, время выполнения и какие UX‑паттерны используются.
Langfuse — задает сильный ориентир для интерфейсов в продакшене: понятная иерархия шагов, визуализация графа и возможность воспроизведения выполнения с любого узла. Хорошо читается структура пайплайна и его экономика.
Phoenix — дает инструменты для разбора и анализа выполнения: можно переигрывать отдельные шаги, сравнивать результаты и смотреть, как меняется поведение системы. Интерфейс помогает не просто увидеть, что произошло, а разобраться, почему агент пришел именно к такому результату.
OpenLIT — интересен связкой трейсинга и инфраструктуры: шаги агента сопоставляются с GPU‑метриками, что дает дополнительный слой понимания, где возникают задержки.
Langtrace — демонстрирует более легкий и интеграционный подход: трейсы можно встраивать прямо в пользовательские интерфейсы, делая их частью продукта.
LangWatch — раскрывает отдельный угол зрения: интерфейс строится вокруг оценки качества ответов и автоматических проверок, добавляя слой аналитики поверх самих трейсов.
В целом, большинство решений сходятся в базовых паттернах: иерархия шагов (traces/spans), возможность провалиться в детали и дополнительные слои анализа — от графов до метрик и оценки качества. При этом общее ощущение получилось довольно четким: единого канонического UX в трейсинге пока нет.
Одни продукты ближе к быстрому отладчику — позволяют быстро зайти и понять, где именно сломался сценарий. Другие работают как диагностическая система — дают больше контекста, глубже объясняют причины, но требуют большего погружения и времени на разбор.
Этот вывод оказался для меня ключевым: универсального паттерна здесь не существует. Значит, интерфейс нужно проектировать не как копию существующих решений, а как ответ на конкретные пользовательские сценарии и задачи.
Как собирались требования и почему это было непросто
Чтобы спроектировать трейсинг, сначала пришлось разобраться, как система реально работает внутри. Без этого невозможно понять, что именно нужно показывать в интерфейсе.
На этапе сбора требований я общался с инженерами (ML, ИИ, бэкенд, платформа) и разбирал их реальные сценарии работы:
с чего начинается разбор, когда что-то сломалось,
что важно увидеть сразу,
в какой момент они уходят глубже и какие детали смотрят.
Такие интервью как раз и нужны, чтобы вытащить реальные сценарии и боли, а не придумывать их — это базовый способ собрать требования через опыт пользователей.
Главный вывод: трейсинг никто не читает последовательно, в нем ищут конкретную проблему. Отсюда ключевое требование к интерфейсу: он должен помогать быстро сузить поиск — от общей картины к конкретному шагу.
Архитектура раздела трейсинга и логика навигации
Архитектура у меня получилась иерархическая и достаточно прямолинейная именно потому, что трейсинг быстро разрастается в объеме данных и без структуры в нем невозможно ориентироваться.
Список сессий. Точка входа — таблица со списком сессий. Здесь пользователь находит нужный запуск и сразу видит признаки проблем: ошибки, статусы, длительность.
Сессия. Проваливаясь в конкретную сессию, пользователь видит диалог с агентом в привычном формате чата — так проще восстановить контекст: что спросили и что агент отвечал. Рядом отображается список трейсов с короткой сводкой по каждому: что это был за этап, сколько занял и есть ли ошибка.
Трейс. Если нужно разобраться глубже, пользователь кликает на нужный трейс и открывает детальный просмотр — цепочку спанов: шаги агента, обращения к языковой модели, вызовы инструментов, взаимодействия с MCP‑серверами, результаты и время выполнения.
Такой маршрут помогает не утонуть в деталях сразу: сначала контекст и быстрый обзор, а дальше — детализация по запросу.
Два типа пользователей и акцент на ошибках
При проектировании я ориентировался на то, что у интерфейса есть две группы пользователей.
Первая — это инженеры. Им нужен подробный разбор: цепочка шагов, входы и выходы, ошибки, время выполнения и все технические детали.
Вторая — пользователи, которым важно быстро понять, что произошло в целом. Для них не критично сразу погружаться в детали, важнее увидеть общий контекст и понять, где примерно проблема.
Отсюда родилось одно из ключевых решений: показывать сессию в виде диалога. Это не было пользовательским требованием — это способ упростить вход в сложную систему и быстрее восстановить контекст: что произошло и в какой момент все пошло не так. Дальше пользователь уже сам решает, насколько глубоко ему нужно идти.
Поскольку основной сценарий для технических пользователей — найти сбой, я сделал акцент на ошибках сразу на нескольких уровнях:
ошибка видна на уровне конкретного шага (span);
сам трейс помечается как проблемный;
сессия тоже показывает, что внутри есть ошибка.
Это позволяет двигаться сверху вниз: сначала заметить проблему в списке сессий, затем найти нужный trace и быстро дойти до конкретного шага, где все сломалось.
Что эта задача изменила в моем подходе
Этот опыт еще раз показал мне, что в подобных задачах дизайн — это во многом работа со структурой данных и пользовательским поиском: как провести человека от общего сигнала «что-то не так» к конкретной причине, не перегружая его на первых экранах, но сохраняя глубину для тех, кому она действительно нужна.
Трейсинг для ИИ‑агентов — молодая область, и паттерны здесь еще складываются. Поэтому для меня ключевым было опираться не на «как принято», а на реальные сценарии: как люди ищут проблемы и что им нужно увидеть в первую очередь.
Работа над tracing стала для меня важным опытом. Вот ключевые выводы, которые я для себя вынес:
UX для ИИ часто ближе к инженерным инструментам, чем к классическим потребительским интерфейсам.
Задача дизайна иногда — не упростить, а грамотно структурировать сложность.
Интервью с экспертами могут быть эффективнее масштабных исследований, особенно когда паттернов еще нет.
В молодой сфере дизайнер учится вместе с рынком.
Хорошие интерфейсы сложных систем почти всегда строятся слоями.
Если вы тоже проектируете observability для агентов или отлаживаете сложные ИИ-системы — делитесь своим опытом в комментариях. Как вы решаете проблему черного ящика? Какие паттерны уже работают у вас?