Проблема: успех без объяснения
Создание агентных систем (agentic systems) часто сводится к тупику: сервис не падает, таймаутов нет, инструменты вызываются успешно, но финальный ответ модели ошибочен. Стандартные логи показывают статус success, но не отвечают на главный вопрос инженера: почему система приняла именно такое решение?
Традиционная наблюдаемость (observability) для распределенных систем строится на предсказуемых путях выполнения кода. Автономные агенты ломают эту парадигму: путь выбирается во время выполнения (runtime). Один и тот же запрос может привести к поиску в вебе, вызову специализированного агента или запросу человеческого одобрения. Наблюдаемость должна фиксировать не «размышления» модели (что рискованно с точки зрения приватности и безопасности), а фактические действия и контекст.
Решение: Langfuse v4 и модель Observations-First
В ответ на эти вызовы была представлена Langfuse v4. Ключевое архитектурное изменение — переход к модели, где первичными сущностями являются наблюдения (observations), а не просто трассировки. LLM-вызовы, выполнение инструментов и шаги агентов становятся полноценными, запрашиваемыми объектами. Трассировка (trace) группирует эти наблюдения через общий trace_id.
Это позволяет задавать конкретные вопросы к системе, а не просто смотреть хронологию:
- «Покажи все наблюдения с неудачным выполнением инструментов»;
- «Какой шаг агента потребляет больше всего ресурсов?»;
- «Какие наблюдения коррелируют с низкими оценками качества (evaluation scores)?».
Интеграция с LangGraph и OpenTelemetry
Для разработчиков, использующих фреймворк LangGraph, Langfuse предлагает выделенную интеграцию, способную визуализировать граф агента прямо в трассировке. Это критически важно для понимания сложных многошаговых сценариев.
Автор материала подчеркивает, что Langfuse не должен становиться частью ядра приложения. Идеальная архитектура предполагает, что приложение генерирует стандартную телеметрию, а слой наблюдаемости решает, куда её отправлять. Именно здесь вступает в игру OpenTelemetry — стандарт индустрии для сбора метрик, логов и трасс, который позволяет отделить логику агентов от инструментов мониторинга.
Почему это важно: версионирование и экономика
Наблюдаемость для автономного поведения должна связывать идентичность, контекст, исполнение, экономику и результат. Без детального версионирования невозможно понять, почему качество упало. Если вчера агент работал на 92%, а сегодня на 74%, трассировка должна четко показать, какая версия модели, промпта, инструмента или политики была задействована.
Пример структуры данных
Вместо абстрактных «мыслей» модели, эффективная трассировка фиксирует конкретные события. Ниже приведена структура данных, которую позволяет отслеживать современный стек наблюдаемости:
| Параметр | Значение / Описание | Значимость для отладки |
|---|---|---|
| decision | delegate | Понимание логики маршрутизации: агент передал задачу другому модулю. |
| target | financial-agent | Идентификация конкретного под-агента, участвовавшего в процессе. |
| reason_code | FINANCIAL_ANALYSIS_REQUIRED | Бизнес-логика выбора: почему была выбрана именно эта ветка. |
| action | tool_call | Фактическое действие: вызов внешнего инструмента. |
| tool | market_data | Конкретный источник данных, использованный для ответа. |
| status | success | Технический статус выполнения (не путать с качеством ответа). |
| evaluation | rejected | Результат проверки качества: система отметила ошибку, несмотря на успех вызова. |
| next_action | retry | Реакция системы на ошибку: попытка повторного выполнения. |
Такой подход позволяет инженерам видеть не «черный ящик», а причинно-следственную цепочку действий, что является фундаментом для создания надежных автономных AI-систем.
Источник: Towards AI pub ↗