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

Как работает ИИ-агент

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

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

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

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

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

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

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

Основные задачи, которые решает трейсинг:

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

Какие задачи решает пользователь

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

• Понять, на каком этапе возникла проблема. Главный вопрос: «Где именно сломалось?».
• Увидеть, к чему обращался агент: где была языковая модель, где инструменты, MCP-серверы, и что туда передавалось.
• Понять, почему итоговый ответ получился именно таким — какая цепочка решений и результатов привела к финалу.
• Сравнить шаги по длительности, чтобы быстро выявить узкие места и аномалии.

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

Анализ решений конкурентов

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

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

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

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

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

LangWatch — добавляет слой аналитики: оценка качества ответов и автоматические проверки поверх трейсов.

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

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

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

Сбор требований: сложности и выводы

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

Я проводил интервью с инженерами — ML, ИИ, бэкенд, платформы — и изучал их реальные сценарии:

• с чего начинается разбор при сбое,
• что важно увидеть сразу,
• когда и какие детали они проверяют.

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

Архитектура интерфейса и навигация

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

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

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

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

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

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

Я выделил две группы пользователей.

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

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

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

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

• ошибка видна на уровне шага (span);
• весь трейс помечается как проблемный;
• сессия тоже отображает наличие ошибки.

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

Что изменилось в моём подходе

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

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

Работа над трейсингом стала для меня важным опытом. Ключевые выводы:

• UX для ИИ часто ближе к инженерным инструментам, чем к потребительским интерфейсам.
• Задача дизайна — не всегда упрощать, а грамотно структурировать сложность.
• Интервью с экспертами могут быть эффективнее масштабных исследований, особенно когда паттернов ещё нет.
• В молодой сфере дизайнер учится вместе с рынком.
• Хорошие интерфейсы сложных систем почти всегда строятся слоями.

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

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

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

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

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

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

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

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

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

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

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

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

• Понять, на каком этапе возникла проблема. Дальше вопрос обычно звучит так: «Где именно сломалось?».
• Увидеть, к чему обращался агент: где была языковая модель, где инструменты, где MCP‑серверы и что туда передавалось или возвращалось.
• Понять, почему итоговый ответ получился именно таким, какая цепочка решений и результатов привела к финалу.
• Сравнить шаги по длительности, чтобы быстро увидеть узкие места и аномалии.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• ошибка видна на уровне конкретного шага (span);
• сам трейс помечается как проблемный;
• сессия тоже показывает, что внутри есть ошибка.

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

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

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

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

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

• UX для ИИ часто ближе к инженерным инструментам, чем к классическим потребительским интерфейсам.
• Задача дизайна иногда — не упростить, а грамотно структурировать сложность.
• Интервью с экспертами могут быть эффективнее масштабных исследований, особенно когда паттернов еще нет.
• В молодой сфере дизайнер учится вместе с рынком.
• Хорошие интерфейсы сложных систем почти всегда строятся слоями.

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