AWS опубликовала техническое руководство по отправке телеметрии от ИИ-агентов, работающих вне её облака, в Amazon Bedrock AgentCore Observability. Подход охватывает on-premises-среды, машины разработчиков, Google Cloud Platform и Microsoft Azure, давая командам возможность использовать дашборды AWS, не перемещая сами рабочие нагрузки агентов в AWS.

Эта рекомендация важна, потому что AgentCore Observability не отслеживает нативно агентов, развёрнутых вне среды выполнения AWS AgentCore. Описанный AWS обходной путь сочетает AWS Distro for OpenTelemetry (ADOT), Amazon CloudWatch и учётные данные AWS Identity and Access Management (IAM) для сбора трассировок, метрик и логов из внешних сред.

Расширение AgentCore за пределы сред выполнения, размещённых в AWS

Amazon Bedrock AgentCore AWS позиционирует как платформу для создания, подключения и оптимизации агентов, построенных на разных фреймворках и моделях. Возможность наблюдаемости предназначена для отображения таких деталей, как выполнение агента, вызовы инструментов, активность модели и использование токенов.

Согласно AWS Machine Learning Blog, нативная поддержка сосредоточена на агентах, работающих в среде выполнения AgentCore в AWS Cloud. Агенты, развёрнутые на Amazon Elastic Kubernetes Service, Amazon Elastic Container Service или AWS Lambda, могут использовать нативные паттерны интеграции AWS, тогда как рабочие нагрузки вне AWS требуют дополнительной настройки.

Недавно задокументированная конфигурация не переносит эти рабочие нагрузки. Вместо этого ADOT работает рядом с приложением агента и выполняет инструментирование поддерживаемых фреймворков и вызовов моделей. Полученная телеметрия экспортируется в endpoint Amazon CloudWatch OpenTelemetry Protocol, где она может питать дашборды AgentCore Observability.

В примерах AWS упоминаются агенты, созданные с помощью Strands Agents, LangGraph и CrewAI. Это делает руководство актуальным для команд, стандартизирующих разные агентские фреймворки, а не рассматривающих наблюдаемость как функцию, привязанную к одному стеку приложений.

Как работает мультиоблачный конвейер телеметрии

Конфигурация состоит из трёх основных частей. Во-первых, ADOT обеспечивает автоматическое инструментирование приложения. AWS говорит, что дистрибутив OpenTelemetry может патчить boto3 для вызовов Amazon Bedrock и инструментировать фреймворк Strands, чтобы выдавались spans, связанные с рассуждением, и данные семантической конвенции для генеративного ИИ.

Во-вторых, внешней среде нужны IAM-учётные данные с правом отправлять телеметрию в сервисы AWS. В перечень разрешений в руководстве входят доступ к метрикам CloudWatch, создание и ingestion логов, а также операции трассировки AWS X-Ray. Настройка также требует исходящего HTTPS-соединения с endpoint-ами AWS.

В-третьих, переменные окружения задают параметры маршрутизации и аутентификации OpenTelemetry. Телеметрия аутентифицируется с помощью AWS Signature Version 4, или SigV4, прежде чем отправляться в endpoint CloudWatch. Затем CloudWatch предоставляет слой ingestion и хранения, а AgentCore Observability — дашборды, адаптированные под активность агентов.

AWS также указывает CloudWatch Transaction Search как обязательное предварительное условие, которое нужно включить один раз на аккаунт. В примере в руководстве используется доступ к модели Amazon Bedrock и Claude Haiku, хотя основной процесс касается экспорта телеметрии из внешних агентов, а не внедрения новой модели.

Доказательства, заявления и оставшиеся ограничения

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

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

Есть и важное ограничение объявления. Подход создаёт кроссплатформенный путь мониторинга; он не делает AgentCore Observability полностью локальным или нейтральным к облаку сервисом. Внешние агенты по-прежнему отправляют телеметрию в сервисы AWS, а командам нужно управлять связанными IAM-разрешениями, сетевым доступом, конфигурацией CloudWatch и политиками обработки данных.

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

Что это значит для разработчиков ИИ и корпоративных команд

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

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

Однако для корпоративных покупателей централизация создаёт компромиссы. IAM-ключи доступа и телеметрия, содержащая входные или выходные данные модели, должны быть защищены, ограничены по области и управляемы. Командам придётся решить, какие поля безопасно экспортировать, как долго хранить записи и подходят ли CloudWatch и AgentCore Observability под их требования комплаенса.

Настройка также создаёт определённую зависимость от AWS, даже если вычисления остаются в другом месте. Создатели, использующие инфраструктуру GCP, Azure или on-premises, могут сохранить гибкость развёртывания, но описанные AWS контур управления мониторингом, модель аутентификации и путь хранения остаются привязаны к сервисам AWS. Это может быть привлекательно для организаций, ориентированных на AWS, и менее убедительно для компаний, стремящихся к вендор-нейтральному стеку OpenTelemetry.

На что смотреть дальше

Самым ближайшим сигналом будет то, расширит ли AWS нативную поддержку AgentCore Observability за пределы среды выполнения AgentCore или продолжит полагаться на интеграцию на базе ADOT для внешних рабочих нагрузок. Документация по дополнительному инструментированию фреймворков и поставщикам моделей покажет, насколько широко этот паттерн работает за пределами примеров в публикации.

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

Наконец, рынок будет наблюдать, ответят ли другие облачные провайдеры сопоставимым кросс-средовым мониторингом агентов. По мере того как ИИ-агенты распределяются по частной инфраструктуре и нескольким облакам, наблюдаемость может стать решающим фактором при выборе того, где команды будут запускать свои рабочие нагрузки.

Взгляд Creati.ai

AWS не объявляет, что внешние агенты теперь нативно работают внутри AgentCore Observability. Компания документирует мост, использующий ADOT и CloudWatch, чтобы расширить видимость сервиса на рабочие нагрузки, развёрнутые в других местах. Это значимое операционное улучшение, но его полезность зависит от того, примут ли команды AWS как контур управления телеметрией.

Для разработчиков главный вывод архитектурный: мониторинг агентов должен следовать за рабочим процессом через модели, инструменты и среды развёртывания. Подход AWS снижает усилия по интеграции для организаций, уже инвестировавших в её сервисы, тогда как требуемые учётные данные и маршрутизация данных делают вопросы безопасности, переносимости и стоимости центральными для любого продакшен-развёртывания.