Когда ИИ-агент выдаёт неожиданный результат, найти причину сложнее, чем в обычном приложении. Между запросом пользователя и финальным ответом агент успевает обратиться к языковой модели, вызвать несколько инструментов, переосмыслить план и, возможно, попасть в смысловой цикл. Без записи этого пути разбор превращается в догадки.
Трейсинг — это механизм, который фиксирует полный маршрут одного запроса через систему. Запись состоит из последовательности шагов, называемых span: каждый шаг описывает одну операцию — вызов языковой модели, обращение к внешнему инструменту или запрос к MCP-серверу. Для каждого шага сохраняются входные и выходные данные, длительность и статус. Это позволяет не просто увидеть, что агент ответил, а восстановить логику принятых решений.
Продуктовый дизайнер Егор, работающий над облачным сервисом для создания ИИ-агентов, изучил пять существующих решений, прежде чем приступить к проектированию собственного интерфейса. Langfuse предлагает понятную иерархию шагов и визуализацию графа выполнения. Phoenix делает акцент на воспроизведении отдельных шагов и сравнении результатов. OpenLIT связывает трейсы с GPU-метриками, что помогает находить задержки на уровне инфраструктуры. Langtrace позволяет встраивать трейсы прямо в пользовательские интерфейсы. LangWatch строит интерфейс вокруг оценки качества ответов и автоматических проверок.
Автор изучил пять продуктов: Langfuse, Phoenix, OpenLIT, Langtrace и LangWatch — и обнаружил, что единого UX-паттерна в трейсинге нет.
Общий вывод из этого анализа оказался неожиданным: единого канонического UX в трейсинге не сложилось. Одни продукты работают как быстрый отладчик — зашёл, нашёл сломанный шаг, вышел. Другие ближе к диагностической системе — дают больше контекста, но требуют времени на погружение. Это означало, что копировать существующие решения бессмысленно: интерфейс нужно строить под конкретные сценарии пользователей.
Чтобы понять эти сценарии, Егор провёл интервью с ML-, ИИ- и бэкенд-инженерами. Главное наблюдение: трейсинг никто не читает последовательно. Пользователь приходит с конкретным вопросом — «где именно сломалось?» — и хочет как можно быстрее добраться до нужного шага. Отсюда ключевое требование: интерфейс должен помогать сужать поиск, а не заставлять листать всё подряд.
Архитектура получилась трёхуровневой. Точка входа — таблица сессий с видимыми признаками проблем: статусами, ошибками и длительностью. Провалившись в сессию, пользователь видит диалог с агентом в формате чата рядом со списком трейсов. Формат чата — не пользовательское требование, а дизайн-решение: он помогает быстро восстановить контекст до того, как погружаться в технические детали. Третий уровень — детальный просмотр трейса: цепочка спанов с входами, выходами и временем выполнения каждого шага.
При проектировании учитывались два типа пользователей. Инженерам нужен полный технический разбор: все шаги, все данные, все ошибки. Менее технические пользователи хотят понять общую картину — где примерно возникла проблема — без немедленного погружения в детали. Иерархическая навигация закрывает обе потребности: каждый останавливается на том уровне, который ему нужен.
