Команда Microsoft Foundry добавила трассировку на базе OpenTelemetry в свой фреймворк агентов, предоставив разработчикам возможность видеть сквозное выполнение задач между разнородными агентами на базе LLM.

Почему мультиагентным системам недостаточно одних лог-файлов

Типичная тренировка по реагированию на инциденты с помощью ИИ использует агента-командира, который координирует работу нескольких специализированных агентов: один анализирует логи, другой обнаруживает аномалии в метриках, третий сопоставляет симптомы с инструкциями (runbooks), а роутер выбирает лучшую языковую модель для каждой подзадачи. Каждый специалист может вызывать разные модели — например, вариант «gpt-5-mini» — и использовать собственные инструменты. Когда что-то идет не так, инженеры смотрят на разрозненные логи, которые показывают, что делал каждый компонент, но не дают представления о том, как эти части взаимодействуют друг с другом.

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

Как OpenTelemetry связывает рабочий процесс воедино

OpenTelemetry определяет две основные концепции: traces (трассы) и spans (спаны). Trace — это уникальный идентификатор, который сопровождает запрос от момента поступления до финального ответа. Span фиксирует одну операцию — например, вызов языковой модели или использование инструмента — внутри этой трассы.

Когда агент получает запрос, он извлекает входящий Trace ID из метаданных запроса и создает дочерний span, который наследует тот же ID. Дочерний span записывает время начала, длительность, атрибуты (название модели, использованный инструмент) и любые ошибки. Процесс повторяется для каждого последующего агента, выстраивая дерево, которое отражает логический поток всей задачи.

OpenTelemetry также поддерживает Baggage — легковесный механизм для передачи пользовательских пар «ключ-значение». Прикрепляя «drill-id» или другой бизнес-контекст к baggage в начале трассы, каждый последующий span автоматически наследует этот идентификатор. Затем процессор спанов (span processor) преобразует baggage в обычные атрибуты, что позволяет легко запрашивать все спаны, относящиеся к конкретной тренировке по инцидентам.

Как выглядит новый интерфейс трассировки

С внедренной инструментацией Azure Monitor (или любой другой OpenTelemetry-совместимый бэкенд) выстраивает визуальную иерархию:

  • Имя / ID агента — показывает, какой компонент выполнил операцию.
  • Использование инструментов — фиксирует, какой внешний сервис или функция были вызваны.
  • Версия модели — записывает конкретную используемую LLM, что полезно для отслеживания регрессий после обновления модели.
  • Потребление токенов — фиксирует количество отправленных и полученных от модели токенов, помогая командам контролировать расходы.
  • Задержка / длительность — подсвечивает места возникновения узких мест, будь то инференс модели или ввод-вывод инструментов.

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

Значимость для операций, ориентированных на ИИ

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

Что ожидать дальше

Проекты, построенные на LangChain, OpenAI SDK или других уровнях оркестрации, могут принять те же семантические соглашения для GenAI, прокладывая путь к трассировке, которая проходит через различных облачных провайдеров и локальные (on-premise) развертывания.

Организациям достаточно включить OpenTelemetry SDK в своих агентах и отправлять данные в Azure Monitor или open-source коллектор.

Итог

OpenTelemetry дает мультиагентным ИИ-системам недостающее связующее звено, которое превращает разрозненные логи в связное повествование. Распространяя единый Trace ID между разнородными LLM, роутерами и вызовами инструментов, разработчики могут находить сбои, контролировать расходы и оптимизировать производительность, не изобретая инфраструктуру трассировки заново.