Trajectories в LangSmith - это хронологическое, диалоговое представление сессии агента. Функция решает конкретную проблему: полный трейс содержит всё нужное для отладки, но именно из-за полноты в нём трудно разглядеть общую картину.
Trajectory агрегирует сообщения от людей, AI и инструментов по основному агенту и любым под-агентам и показывает их в порядке первого появления. Каждое сообщение встречается один раз, по порядку, поэтому сессию можно читать как путь, который прошёл агент.
Рабочий сценарий выглядит так. Вы открываете thread как Trajectory, находите место, где поведение отклонилось от ожидаемого, а затем переходите к полному трейсу за деталями исполнения. Дальше траектории оцениваются онлайн-эвалуаторами, отправляются в очереди аннотаций или датасеты, а примеры из них экспортируются в workflows supervised fine-tuning.
Что такое Trajectories в LangSmith и зачем они нужны
В анонсе LangChain Trajectory описан как проекция над трейсами внутри thread: вложенная структура запусков удаляется, а сообщения и действия, объясняющие поведение агента, остаются. Основной агент и под-агенты попадают в один поток, поэтому сессия читается сверху вниз без разворачивания дерева вызовов.
Из этого следуют две практические задачи. При отладке траектории показывают упорядоченный путь агента за сессию, и отклонение находится до того, как вы углубитесь в трейс. При оценке появляется объект, который можно прочитать целиком и оценить как единое целое, а не как набор несвязанных runs.
Чем Trajectory отличается от Trace и Thread
Термины в LangSmith образуют иерархию. Каждая единица работы агента записывается как run. Runs одной операции образуют trace. Traces многоходовой сессии связываются в thread. Trajectory не отдельный тип данных в этой цепочке: это проекция над трейсами внутри thread.
Trace даёт полное дерево исполнения: вложенные runs, тайминги, ретраи, входы, выходы и метаданные. Когда нужно понять, как именно что-то исполнялось, трейс остаётся источником истины. Trajectory отвечает на другой вопрос: что агент сделал по ходу сессии, в каком порядке и на каком шаге свернул не туда.
| Аспект | Trace | Trajectory |
|---|---|---|
| Что показывает | Полное дерево исполнения операции | Сообщения и действия в порядке появления |
| Вложенные запуски | Сохраняются | Убираются |
| Тайминги, ретраи, входы и выходы, метаданные | Доступны | В траектории не выводятся |
| Для чего использовать | Детали исполнения | Понимание пути агента, отладка, оценка |
Практический вывод: Trajectory и Trace дополняют друг друга, а не конкурируют. Разбор удобнее начинать с траектории, а детали смотреть в трейсе.
Почему обычный трейс бывает слишком детальным
Отладка агента часто начинается с простого вопроса: что агент на самом деле сделал? Для коротких одноходовых workflows ответ находится быстро. Для долго работающих агентов всё усложняется: одна сессия может охватывать много пользовательских ходов, вызовов инструментов, ретраев и передач задач под-агентам.
Полный трейс остаётся правильным местом для инспекции деталей исполнения, но он бывает слишком подробным, когда цель - понять путь агента. Ответ обычно где-то в трейсе, но может быть погребён внутри вложенных деталей исполнения. Trajectories предлагают начать с упорядоченного пути сессии.
Как Trajectories ускоряют отладку AI-агентов
Разбор отклонения сводится к поиску шага, на котором агент повёл себя не так, как ожидалось. Проверять приходится типовые причины: агент не понял пользователя, переиспользовал устаревший контекст, вызвал не тот инструмент, получил плохой результат от под-агента или проигнорировал вывод инструмента в финальном ответе. В полном трейсе каждая из этих причин живёт на своём уровне вложенности, и переключение между уровнями съедает время.
Пошаговый разбор: от Trajectory к полному трейсу
- Откройте thread как Trajectory и прочитайте сообщения в порядке их появления.
- Найдите шаг, где поведение отклонилось от ожидаемого: лишний вызов, пропущенный инструмент, неверная передача задачи под-агенту.
- Отметьте этот участок и перейдите к полному трейсу, чтобы посмотреть, как исполнялся конкретный run.
- Сверьте входы, выходы и метаданные проблемного шага. Здесь же видны тайминги и ретраи, которых в Trajectory нет.
- Если отклонение воспроизводится, отправьте сессию в очередь аннотаций или датасет, чтобы вернуться к ней на следующей итерации.
Экономия возникает на самом дорогом участке: пока неясно, где именно ошибка, просмотр десятков вложенных runs превращается в перебор.
Работа с под-агентами и вложенными вызовами
Мультиагентные схемы - главный источник вложенности. Trajectory агрегирует сообщения по основному агенту и любым под-агентам и показывает их в порядке первого появления, поэтому передача задачи под-агенту видна как отдельное событие в общем потоке. Спускаться по дереву runs вручную не нужно: видно, в какой момент управление ушло в сторону и что вернул под-агент.
Ограничение тоже заметно сразу. В траектории видна последовательность хендоффов, но не видно, сколько времени занял каждый шаг и сколько было ретраев. За этим придётся идти в трейс. Пример архитектуры с суперграфом, суб-воркфлоу и human-in-the-loop разобран в материале про федеративных агентов Included Health на LangGraph и Deep Agents.
Оценка агентов с помощью Trajectories
Trajectories меняют не только отладку, но и работу с качеством. В LangSmith threads просматриваются как траектории, траектории оцениваются онлайн-эвалуаторами и направляются в очереди аннотаций или датасеты. Оценка привязывается к сессии, которую можно прочитать целиком, а не к россыпи отдельных runs.
Онлайн-эвалуаторы и очереди аннотаций
Онлайн-эвалуаторы дают автоматическую оценку траекторий на потоке, очереди аннотаций закрывают случаи, где автоматики не хватает. Смысл в читаемом формате: специалисты предметной области (SME) проверяют поведение агента, не разбирая вложенные трейсы. Эксперт тратит время на суждение, а не на навигацию по дереву вызовов, и порог входа в оценку падает.
С какими сложностями сталкивается такая схема, видно на реальной практике. В кейсе Similarweb рубрики LLM-as-judge для длинных отчётов и проверки faithfulness пришлось калибровать, иначе плохо настроенный судья маскировал настоящие улучшения агента. Разбор оценки AI-агентов для длинных отчётов полезен, если вы собираетесь строить судей поверх траекторий.
Сохранение сессий в датасеты и экспорт для supervised fine-tuning
Trajectories поддерживают непрерывное улучшение на данных продакшн-поведения: полезные сессии сохраняются в датасеты, примеры экспортируются для workflows supervised fine-tuning. Логика простая: удачная сессия из продакшена становится обучающим или тестовым примером, неудачная - кандидатом в аннотацию.
Основной риск в отборе. Датасет из случайных сессий принесёт мало пользы, а SFT на мусорных траекториях способен ухудшить результат. В медицинском AI ту же проблему решают превращением экспертной проверки в инфраструктуру: размеченные датасеты, калиброванные судьи и автоматические релизные гейты. Кейсы Abridge и Included Health показывают, как это выглядит, когда время эксперта - самый дефицитный ресурс.
Совместимость: какие трейсы поддерживают Trajectories
Trajectories работают из коробки для трейсов, отправленных из LangChain, LangGraph и Deep Agents, из агентских SDK вроде OpenAI и Claude, а также из кодинг-агентов вроде Codex, Claude Code и Cursor. Об этом сказано в анонсе. Отдельная настройка под каждый источник не требуется, но трейсы должны попадать в LangSmith: без них проекцию строить не из чего.
Для кодинг-агентов читаемая сессия полезна особенно: одна задача тянет за собой длинную цепочку правок и запусков. Как строят контроль качества вокруг таких агентов, разобрано в материале про верификацию, evals и CI-проверки у Cursor.
Ограничения и условия использования Trajectories
Первое ограничение концептуальное: Trajectory - проекция над трейсами в thread, а не замена полного трейса. Вложенная структура запусков из неё удалена, поэтому тайминги, ретраи, входы и выходы, метаданные вложенного исполнения придётся смотреть в трейсе. Полный трейс, в свою очередь, остаётся слишком детальным, когда нужно понять именно путь агента.
Второе ограничение касается доступности. В анонсе указано, что Trajectories доступны на всех тарифах в США. Сведений о других регионах публикация не приводит, поэтому при работе вне США стоит проверить доступность в своём аккаунте до того, как закладывать функцию в процессы. Данных о дате запуска за пределами указанной даты публикации тоже нет.
Третье: функция опирается на трейсы LangSmith. Если наблюдаемость у вас устроена иначе, сначала придётся наладить отправку трейсов из поддерживаемых источников, и только потом траектории станут доступны в интерфейсе. Для голосовых агентов это отдельная задача: там нужна интеграция с речевыми фреймворками, чтобы сессия вообще превратилась в thread.
Как встроить Trajectories в рабочий процесс
- Убедитесь, что трейсы приходят в LangSmith из поддерживаемого источника: LangChain, LangGraph, Deep Agents, агентский SDK или кодинг-агент.
- Соберите несколько реальных сессий и откройте threads как траектории, чтобы искать точки отклонений на живых данных, а не на синтетике.
- Настройте онлайн-эвалуаторы для автоматической оценки траекторий на потоке, а критерии калибруйте на размеченных вручную примерах.
- Заведите очередь аннотаций для сессий, где автоматическая оценка не даёт уверенного ответа.
- Сохраняйте показательные и удачные сессии в датасеты, а экспорт примеров в supervised fine-tuning запускайте, когда накопится достаточный объём.
Порядок шагов можно менять. Оценка онлайн-эвалуаторами запускается почти сразу, цикл дообучения разумнее включать после того, как появится стабильный набор траекторий и понятные критерии качества.
Отдельного механизма исправления ошибок агента у Trajectories нет. Функция ускоряет поиск проблемы и сбор данных для оценки и обучения, а сама правка промптов, инструментов или логики под-агентов остаётся за вами.