LangSmith Custom Apps позволяют создавать, публиковать и запускать собственные интерфейсы поверх данных LangSmith прямо внутри платформы, как описано в анонсе в блоге LangChain. По данным того же анонса, LangSmith используют тысячи команд AI-инженеров для отладки, оценки и улучшения агентов; независимого подтверждения этой оценки в открытых источниках нет.
Суть нововведения простая: команда перестаёт заниматься инфраструктурной рутиной. Хостинг, аутентификация, права доступа и шаринг уходят на сторону платформы, а остаётся задача, ради которой всё и затевалось: показать ревьюеру именно те данные, которые ему нужны, в удобном виде.
Что такое LangSmith Custom Apps и какую задачу они решают
Custom Apps — это механизм, который даёт собирать, публиковать и запускать кастомные UI поверх данных LangSmith внутри самого LangSmith. Приложение живёт в рабочем пространстве, а не на отдельном домене, который нужно поднимать, закрывать паролем и раздавать доступы вручную.
Ключевая выгода в экономии инженерного времени. Раньше любая нестандартная визуализация означала либо экспорт данных, либо отдельный фронтенд со своим хостингом и логином. Теперь достаточно опубликовать приложение, и коллеги откроют его там же, где уже смотрят трейсы, эксперименты, аннотации и результаты оценки.
Почему стандартных UI LangSmith не всегда достаточно
В LangSmith есть дефолтные интерфейсы для отладки, оценки и улучшения агентов: готовые дашборды по latency, стоимости и частоте ошибок, а также сравнительное представление, которое подсвечивает регрессии между экспериментами. Для большинства задач этого хватает, но интерфейсы универсальны, а процессы ревью у команд разные.
Разница хорошо видна на двух ролях. Инженеру нужен полный трейс: вызовы инструментов, метаданные, промежуточные шаги. Эксперту предметной области (SME) всё это только мешает, ему достаточно запроса пользователя, ответа модели, релевантного контекста и чёткой рубрики. Один общий экран пытается обслужить оба сценария и в итоге проигрывает каждому из них.
Custom Apps дополняют стандартные UI, а не заменяют их. Типичная боль выглядит так: данные в платформе есть, а показать их коллеге негде. Раньше помогал CSV или одноразовая статичная вью, собранная под конкретную задачу и забытая через неделю. Публикация приложения превращает такую вью в переиспользуемый инструмент для повторяющихся рабочих процессов.
Как создать приложение в LangSmith: два пути
Способа два: описать желаемое в чате или собрать приложение в коде. Заканчиваются оба одинаково, публикацией в рабочем пространстве.
Создание через LangSmith Chat: для быстрого старта
На планах Plus и Enterprise можно написать LangSmith Chat, какие данные нужны и как их визуализировать. Чат превращает описание в работающее приложение. Никакого API, шаблонов и сборки: подходит для прототипа и простых интерфейсов вроде таблицы с оценками или списка трейсов с фильтрами.
Ограничение предсказуемо: гибкость упирается в то, что понимает чат. Сложную логику, нестандартные представления и вычисления на стороне клиента так не собрать, придётся переходить к коду.
Сборка в коде с помощью шаблонов и LangSmith API
Второй путь для разработчика: взять предоставленные шаблоны и писать приложение против LangSmith API, используя кодинг-агент. Здесь полный контроль над логикой, структурой данных и внешним видом. Про подводные камни такого подхода стоит почитать отдельно: код подешевел, а разработка не ускорилась, и проверка результата часто дороже генерации.
После публикации приложение становится общим интерфейсом внутри рабочего пространства. Хостинг, аутентификацию, права доступа и шаринг берёт на себя платформа, поэтому команде не нужно поднимать отдельный сервис и следить за его жизненным циклом, как это происходит с типовыми самодельными фронтендами поверх данных LangSmith.
Пути комбинируются: чат-промпт для быстрой проверки гипотезы, затем доработка в коде, если нужна более сложная логика или свои компоненты. Публикация и шаринг работают одинаково в обоих случаях.
Основные сценарии использования Custom Apps
Практическая польза сосредоточена в трёх направлениях: сбор человеческой обратной связи, сравнение экспериментов и сфокусированный разбор трейсов. Каждое закрывает свою боль, и все три объединяет одно: процесс повторяется от релиза к релизу.
Аннотирование и сбор человеческой обратной связи
Человеческая обратная связь — один из важнейших входов для улучшения AI-систем. Автоматические оценки помогают находить паттерны, но людям всё равно нужно ревьюить выводы, оценивать поведение и объяснять, что значит «хорошо» для конкретного приложения.
Стандартные формы аннотирования заставляют всех смотреть на один и тот же набор полей. Custom Apps позволяют собрать интерфейс под рабочий процесс конкретного ревьюера: инженер получает полный трейс с вызовами инструментов и метаданными, эксперт предметной области — запрос, ответ, релевантный контекст и рубрику. Экономия здесь не в красоте, а во времени: чем меньше лишнего на экране, тем быстрее выносится решение и тем выше шанс, что разметку вообще доведут до конца.
Сравнение экспериментов и разбор трейсов
Стандартное сравнение в LangSmith подсвечивает регрессии между экспериментами: красным отмечаются прогоны, которые ухудшились по любому ключу обратной связи относительно исходного эксперимента, зелёным — те, что улучшились, а вверху каждого столбца метрики видно, сколько прогонов стало лучше или хуже. Исходный эксперимент можно назначить через выпадающее меню в верхней части режима сравнения (Set as source experiment); по умолчанию им становится первый выбранный эксперимент. Кастомное приложение сужает фокус: можно вывести только прогоны определённой версии агента, добавить свои фильтры и метрики, поставить рядом именно те запуски, которые обсуждают на ревью.
Для разбора трейсов логика похожая. Вместо полного трейса со всеми шагами интерфейс показывает релевантные вызовы инструментов и промежуточные результаты, убирая шум. Особенно полезно, когда один и тот же процесс ревью повторяется: под повторяющиеся workflows Custom Apps и рассчитаны в первую очередь.
Ограничения и доступность: что нужно знать перед началом
Планы Plus и Enterprise: лимиты и возможности
Создание приложения через чат-промпт доступно на планах Plus и Enterprise. Публичные источники не подтверждают лимит «одно приложение на организацию на Plus» и «неограниченное число приложений на Enterprise», поэтому ориентироваться на такие цифры не стоит. Подтверждённые лимиты касаются других сущностей: по сторонним обзорам тарифов, Plus включает до 3 рабочих пространств на организацию и 10 000 трейсов на пользователя в месяц, Enterprise — до 10+ рабочих пространств, кастомный SSO и RBAC. Эти данные взяты из сторонних обзоров, а не с официальной страницы тарифов, поэтому перед планированием их стоит сверить с актуальной документацией LangSmith.
Отдельная оговорка: избавление от рутины по хостингу и аутентификации не отменяет поддержки. Приложение живёт на платформе, но логику, представления и рубрики обновляет команда, иначе через пару месяцев интерфейс начнёт показывать метрики, которых уже нет.
Дизайн-система Macaw и кастомизация внешнего вида
Утверждение, что приложения по умолчанию используют дизайн-систему Macaw и что она была открыта (open-sourced), не подтверждается ни одним из доступных источников. В анонсе LangChain сведений о Macaw нет, поэтому считать её стандартной основой оформления Custom Apps нельзя. Если внешний вид и кастомизация критичны, сверьтесь с актуальной документацией LangSmith до того, как планировать работу.
Custom Apps и самостоятельная разработка кастомных фронтендов
Часть команд уже решает задачу своими силами: кодинг-агенты, LangSmith API и внутренние инструменты позволяют собрать фронтенд поверх данных платформы. Проблема в том, что такое приложение живёт как обычный софт: ему нужны хостинг, аутентификация, права доступа, шаринг и постоянная поддержка.
Custom Apps забирают эту рутину и оставляют логику с UX. Плата за удобство: привязка к платформе, лимиты тарифа и меньшая свобода в архитектуре, потому что приложение всё равно работает внутри LangSmith.
Если собственный фронтенд уже написан, отлажен и встроен в процессы, миграция вряд ли окупится. Если вы только собираетесь его писать, посчитайте стоимость поддержки: она живёт дольше, чем кажется, а требования к ревью меняются вместе с агентом. Custom Apps выигрывают там, где интерфейсов нужно много, а отдельной команды поддержки нет.
Практические рекомендации по работе с Custom Apps
- Начните с одного повторяющегося процесса ревью, а не с «дашборда всего». Если процесс не повторяется, кастомный интерфейс не окупится.
- Опишите роли: кто именно ревьюит и что ему нужно видеть. Инженер с полным трейсом и SME с запросом, ответом и рубрикой — это два разных приложения.
- Соберите первый вариант через LangSmith Chat, если у вас план Plus или Enterprise, покажите его реальным ревьюерам и только потом переходите к коду.
- Заранее зафиксируйте набор полей и метрик: что показывать, что скрывать, по какой шкале оценивать.
- Продумайте доступ, потому что после публикации приложение становится общим для рабочего пространства.
- Заложите поддержку: рубрики, метрики и представления устаревают вместе с агентом.
Рабочая последовательность выглядит так: интерфейс аннотирования для SME через чат-промпт, затем доработка в коде с кастомными фильтрами, затем отдельное приложение для сравнения экспериментов, когда объём прогонов вырастет настолько, что стандартного представления перестанет хватать.
Итог: кому и когда стоит использовать LangSmith Custom Apps
Инструмент рассчитан на команды, которые уже ведут агентов в LangSmith и хотят снять с ревьюеров лишнюю работу. Самый сильный сценарий: повторяющийся процесс ревью, где людям нужен конкретный срез данных, а не полный трейс и не весь дашборд.
Начинать с Custom Apps не стоит, если вы ещё не освоили стандартные дашборды и сравнение экспериментов. Сначала посмотрите, чего именно не хватает, и убедитесь, что дело в интерфейсе, а не в отсутствии метрик и рубрик. Если у команды есть свой фронтенд и ресурсы на его поддержку, переход необязателен.
Что сделать дальше: выберите один повторяющийся процесс ревью, опишите роль ревьюера и набор полей, проверьте доступный план (Plus или Enterprise) и соберите прототип. Это займёт меньше времени, чем разворачивание отдельного фронтенда, и сразу покажет, приживётся ли кастомный интерфейс в команде.