Две новости об одной инженерной задаче
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, и не привязывать инструментацию к формату одного вендора.
