ИИ-агенты заговорили на языке OpenTelemetry: два сигнала от MCP и Otel

Две новости об одной инженерной задаче

28 июля 2026 года Model Context Protocol выпустил новую спецификацию. В тот же день прошёл Japan Community Day перед KubeCon + CloudNativeCon Japan. Несколько докладов там были посвящены OpenTelemetry и наблюдаемости ИИ-агентов.

Обе новости касаются одной инженерной задачи: как проследить запрос от приложения с агентом через MCP до инструмента или внешнего API. Для такой цепочки нужны сквозной контекст, спаны и общие правила описания телеметрии.

Наблюдать нужно за всей цепочкой, а не только за вызовом модели:

Новость 1. MCP закрепил W3C Trace Context в протоколе

Model Context Protocol описывает взаимодействие приложений с инструментами, источниками данных и внешними сервисами. Один пользовательский запрос может пройти через хост-приложение, SDK, MCP-сервер и несколько зависимых систем. Без общего контекста каждый переход разрывает трейс.

Редакция MCP 2026-07-28 описывает передачу контекста трассировки по стандарту W3C Trace Context. Для этого в поле _meta внутри params используются три ключа:

• traceparent;

• tracestate;

• baggage.

Запрос выглядит так (пример из спецификации):

{  "jsonrpc": "2.0",  "id": 2,  "method": "tools/call",  "params": {    "name": "get_weather",    "arguments": {      "location": "New York"    },    "_meta": {      "traceparent": "00-0af7651916cd43dd8448eb211c80319c-00f067aa0ba902b7-01"    }  }}

Для этих трёх ключей сделано исключение из общего правила DNS-префиксов в _meta. Без исключения реализации могли бы выбрать разные имена, например io.modelcontextprotocol.traceparent. Тогда они не смогли бы продолжать один трейс.

Клиент может сохранить один trace_id при переходе от приложения к MCP-серверу и вызываемому API. Такой трейс собирается в OpenTelemetry-совместимом бэкенде вместе с телеметрией остальных сервисов.

Спецификация закрепляет уже сложившуюся практику. Передача контекста работала в C#- и Python-SDK, Logfire, инструментации OpenInference и Envoy AI Gateway. Теперь имена ключей зафиксированы в протоколе.

Сам протокол не создаёт спаны автоматически. Клиенты, серверы и вызываемые ими компоненты по-прежнему должны извлечь контекст, продолжить трейс и экспортировать данные. Спецификация задаёт для них общий формат передачи контекста.

Логирование уходит из MCP в OpenTelemetry

MCP также начал выводить из протокола встроенный механизм Logging. Для структурированной телеметрии предлагается использовать OpenTelemetry. Вместе с Logging депрецированы Roots и Sampling: эти возможности редко применялись, требовали поддержки и имели альтернативы за пределами протокола.

Logging не удаляют сразу. Переходное окно составляет минимум двенадцать месяцев: возможности останутся во всех редакциях спецификации, выпущенных в течение года, и каждая такая редакция поддерживает их ещё год после собственного релиза. Новым реализациям при этом предлагают отправлять структурированную телеметрию через OpenTelemetry.

Stateless-ядро упрощает прокси и балансировку

В редакции 2026-07-28 базовый протокол стал stateless. Из обязательного ядра удалены initialize, initialized и заголовок Mcp-Session-Id. Версия протокола, идентификация клиента и контекст трассировки теперь передаются в _meta каждого запроса.

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

Контекст трассировки описан в SEP-414, а депрекация Logging, Roots и Sampling в SEP-2577. Обзор редакции опубликован в анонсе MCP 2026-07-28 и материале о release candidate.

Новость 2. ИИ-агенты вошли в дорожную карту OpenTelemetry

На Japan Community Day и KubeCon Japan наблюдаемости ИИ-агентов посвятили несколько докладов:

• Building AI Agent Observability with OpenTelemetry (Japan Community Day, 28 июля);

• Project Lightning Talk: New Frontiers for OpenTelemetry - A Roadmap for the Future (29 июля);

• Keynote: OpenTelemetry Celebrates Graduation and the Next Era of Agentic Observability (30 июля).

После получения статуса graduated в мае 2026 года проект перечислил следующие направления развития:

• семантические соглашения для генеративного ИИ и агентных сценариев;

• наблюдаемость браузерных и мобильных приложений;

• управление схемами телеметрии через Weaver (инструмент для описания, проверки и документирования семантических соглашений и схем телеметрии);

• упрощение установки компонентов с помощью Packaging (набор APT- и RPM-пакетов для Injector, OBI, Collector и автоинструментации);

• развитие Injector (библиотека, которая при запуске процесса подключает агенты автоинструментации и добавляет атрибуты ресурса без правки кода приложения).

Одного trace_id для ИИ-систем недостаточно. Семантические соглашения должны одинаково описывать вызов модели, вызов инструмента, шаг агента, ошибку политики и завершение задачи.

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

Выводы. ИИ-агента придётся наблюдать как распределённую систему

MCP описывает вызов инструментов агентом. OpenTelemetry собирает телеметрию распределённых операций. W3C Trace Context передаёт идентификаторы трейса между этими уровнями.

Получается такая цепочка:

В одном трейсе можно увидеть:

• сколько времени модель принимала решение;

• какой инструмент был выбран;

• сколько занял вызов MCP-сервера;

• где возникла ошибка;

• какой зависимый сервис стал причиной задержки;

• какие инфраструктурные метрики сопровождали инцидент.

Журнал действий агента показывает его собственные шаги. Сквозной трейс связывает эти шаги с MCP-сервером, внешними API и инфраструктурой.

Стандартизация наблюдаемости агентов ещё не закончена, остаются открытые вопросы:

• единая модель спанов для многошаговых агентов;

• стабильные семантические соглашения для MCP-инструментов;

• учёт стоимости и токенов при сложных цепочках;

• трассировка параллельных и асинхронных действий;

• связь технического трейса с бизнес-результатом задачи;

• безопасное управление содержимым промптов и ответов;

• единые правила оценки качества работы агента.

Поддержка Trace Context в спецификации не гарантирует его корректную передачу в каждом SDK и MCP-сервере. Это нужно проверять для конкретной реализации. В статье «Почему MCP-вызов разрывал сквозной трейс GenAI-приложения в OpenTelemetry Demo 3.0 и как мы это исправили» показано, почему такой разрыв может возникать.

ИИ-агента уже приходится эксплуатировать как распределённое приложение: отслеживать сетевые границы, внешние зависимости, задержки, ошибки, повторные вызовы и чувствительные данные. Для этого подходят W3C Trace Context, спаны OpenTelemetry, семантические соглашения и независимый транспорт телеметрии. Стандарт ещё формируется, но открытые спецификации уже позволяют собирать данные в собственном контуре, например в Proto Observability Platform, и не привязывать инструментацию к формату одного вендора.