AWS 于 8 月 13 日在官方机器学习博客发布技术指南，介绍如何为运行在 AWS 之外的 AI 智能代理配置可观测性：借助 AWS Distro for OpenTelemetry（ADOT），把部署在本地数据中心、开发者电脑、Google Cloud 与 Microsoft Azure 等环境中的代理遥测数据，统一接入 Amazon Bedrock AgentCore Observability 仪表板，全程无需将代理工作负载迁移到 AWS。
Amazon Bedrock AgentCore 是 AWS 于 2025 年 7 月在纽约峰会上推出的企业级智能代理平台，包含运行时、内存、身份、网关、浏览器、代码解释器与可观测性等模块化服务。其中 AgentCore Observability 依托 Amazon CloudWatch，提供代理执行过程的逐步可视化、元数据标记与故障排查能力。不过，其原生支持此前主要面向部署在 AWS 云内 AgentCore Runtime 上的代理；运行在 Amazon EKS、ECS、Lambda 以及 AWS 之外环境中的代理，需要额外配置才能把遥测数据送入同一套仪表板。
新指南针对的正是这一缺口。整个方案由三个部分构成：
- ADOT 自动插桩：ADOT 随代理应用一同运行，自动为支持的框架与模型调用插桩。示例中
aws-opentelemetry-distro会为 Amazon Bedrock 调用修补 boto3，并为 Strands 框架生成推理相关 span 与生成式 AI 语义约定数据。 - IAM 凭证：外部环境持有具备相应权限的 IAM 凭证，遥测数据在发送前通过 AWS Signature Version 4（SigV4）签名认证。
- OpenTelemetry 环境变量：定义遥测的路由与认证参数，将数据导向 CloudWatch 的 OpenTelemetry Protocol（OTLP）端点，再由 AgentCore Observability 仪表板消费。
数据链路为：ADOT 采集追踪、指标与日志 → SigV4 认证 → CloudWatch OTLP 端点 → CloudWatch 控制台的 AgentCore Observability 视图（GenAI Observability → Bedrock AgentCore）。其中 CloudWatch 负责遥测的接收与存储，AgentCore Observability 提供面向代理活动的仪表板，控制台中可分别查看代理、会话与追踪三个视图。
指南覆盖 Strands Agents、LangGraph、CrewAI 等框架，并给出了一套 Python 示例（示例模型为 Claude Haiku）。前置条件包括：已配置 Amazon Bedrock 模型访问的 AWS 账户、每个账户需启用一次的 CloudWatch Transaction Search、非 AWS 环境中 Python 3.10 及以上版本、对 AWS 端点的出站 HTTPS 访问，以及包含 bedrock:InvokeModel、logs:CreateLogGroup、logs:CreateLogStream、logs:PutLogEvents、xray:PutTraceSegments、xray:PutTelemetryRecords、xray:GetSamplingRules、xray:GetSamplingTargets、cloudwatch:PutMetricData 等权限的 IAM 用户凭证。
关键环境变量配置如下：
export AGENT_OBSERVABILITY_ENABLED=true
export OTEL_PYTHON_DISTRO=aws_distro
export OTEL_PYTHON_CONFIGURATOR=aws_configurator
export OTEL_RESOURCE_ATTRIBUTES="service.name=my-external-agent,aws.log.group.names=/aws/bedrock-agentcore/runtimes/my-external-agent"
export OTEL_EXPORTER_OTLP_LOGS_HEADERS="x-aws-log-group=/aws/bedrock-agentcore/runtimes/my-external-agent,x-aws-log-stream=runtime-logs,x-aws-metric-namespace=bedrock-agentcore"
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
export OTEL_TRACES_EXPORTER=otlp其中 AGENT_OBSERVABILITY_ENABLED=true 激活 ADOT 中面向生成式 AI 的遥测处理；aws.log.group.names 让 CloudWatch 把遥测索引到 AgentCore Observability 仪表板之下，缺少该属性时追踪只会进入通用 CloudWatch Logs；x-aws-metric-namespace=bedrock-agentcore 则把嵌入式指标格式的指标路由到正确的 CloudWatch 命名空间。随后用 opentelemetry-instrument 启动代理进程即可完成采集。
为验证方案在第三方云环境中的可行性，AWS 在 Google Cloud Shell（运行于 GCP 基础设施的浏览器终端）上复现了同一套配置。指南称，gcp-hosted-agent 在两到三分钟内即出现在 AgentCore Observability 仪表板中，其会话、追踪、span 指标、token 用量与延迟等遥测内容，和 AgentCore Runtime 托管代理完全一致；控制台中可见 invoke_agent、chat、execute_event_loop_cycle、chat.us.anthropic.claude-haiku 等 span。
统一的可观测性让团队能够在同一处查看代理的推理链、工具调用、模型输出、token 用量、延迟与审计记录。AWS 表示，这有助于识别幻觉、有害或偏离主题的响应，并为 token 消耗提供成本监控的基础。对开发者而言，开发阶段的本地代理、生产环境中的私有数据中心代理以及其他云上的代理，都可以共用同一套监控面，减少为每个部署位置单独搭建仪表板的负担。
需要指出的是，这一方案建立的是跨平台监控通路，并未让 AgentCore Observability 变成完全本地或云中立的能力：外部代理的遥测数据仍会进入 AWS 服务，团队需要自行管理 IAM 权限、网络访问、CloudWatch 配置与数据处理策略。对于数据驻留、安全架构或采购策略限制向第三方云传输提示词、输出与追踪细节的组织，这份指南提供的是技术路线，而非对这些治理要求的直接满足。