构建智能代理工作流时，一个常见难题是：如何把托管的基础模型与你自有的、为成本或领域定制的模型混合使用，而不必为此重写整套代理框架。AWS 机器学习博客近日发布的一篇技术指南，给出了一条可行的路径——把 Amazon SageMaker AI 上的 OpenAI 兼容端点与 Amazon Bedrock AgentCore 运行时结合起来，让不同类型的专用代理各自调用最适合的模型，在同一个生产级架构中同时获得成本优化、数据驻留和模型灵活性。
指南以一个多代理金融工作流为例，把三条模型托管路径汇聚到同一个 Amazon Bedrock AgentCore 容器中：
- 编排代理（Bedrock 上的 Claude Haiku 4.5）：负责识别用户意图，并通过 Global 跨区域推理路由任务；
- 预算代理（Bedrock 上的 Claude Sonnet 4.6）：处理 50/30/20 的预算拆分，输出结构化 Pydantic 结果；
- 金融分析代理（SageMaker AI 上的 Qwen 3.5 9B）：通过工具调用完成股票分析与投资组合构建。
用户请求首先进入运行在 Amazon Bedrock AgentCore 运行时中的编排代理。编排代理使用 Strands Agents 的“把代理当作工具”（agents as tools）模式，把任务路由到预算代理或金融分析代理。预算代理通过 Amazon Bedrock 调用 Claude Sonnet 4.6；金融分析代理则通过 SageMaker AI 的实时端点、以 OpenAI 兼容 API 调用 Qwen 3.5 9B。结果再经编排代理返回给用户。
在具体实现上，指南分为三步。第一步是在 SageMaker AI 上部署 Qwen 3.5 9B，使用 vLLM 深度学习容器镜像 vllm:0.22.1-gpu-py312-cu130，实例类型为 ml.g6e.2xlarge。第二步是构建多代理系统：SageMaker AI 的 OpenAI 兼容 API 需要 bearer token，而 token 会过期，因此对长运行会话要用 httpx.Auth 子类实现自动刷新；代理之间采用 Strands Agents 的 agents as tools 模式，并且每次调用都创建新的代理实例，以避免并发调用错误。第三步是借助 bedrock-agentcore-starter-toolkit 把整套工作流部署到 Amazon Bedrock AgentCore 运行时。
指南把相当篇幅放在了可观测性上。Amazon Bedrock AgentCore 运行时会自动用 OpenTelemetry 对代理进行埋点，但这一埋点并非对所有模型提供方一视同仁：Bedrock 的模型调用会自动获得完整的生成式 AI span 和 token 计数，而通过 Strands OpenAIModel 访问的 SageMaker OpenAI 兼容端点却不会自动获得 token 遥测。结果是，金融分析代理调用 Qwen 3.5 9B 所消耗的 token 在追踪中完全不可见，直接影响成本监控、回归检测与延迟排查。
根因在于 Strands 的 OTEL 集成只会为工具调用和代理生命周期事件发出 span，而不会为 OpenAIModel 提供方发出带 token 属性的 gen_ai.chat span。指南给出的修复方式是：围绕 SageMaker 代理调用手动发出 gen_ai.chat span，并从 AgentResult.metrics.accumulated_usage 读取 token 用量——Strands 在提供方返回 usage 数据时，会把用量存在 inputTokens、outputTokens 和 totalTokens 字段下。
另一个容易被忽略的细节是 vLLM 的流式输出：vLLM 默认不会返回 usage 块，因此需要显式把 stream_options 中的 include_usage 设为 true。否则 Strands 只收到文本分片而没有最终的 usage 对象，accumulated_usage 会一直为零，自定义 span 上报的 token 数也会是 0。
指南还总结了若干运营经验：Bedrock 调用（如 Claude 或 Amazon Nova）无需额外处理；SageMaker OpenAI 端点需要手动补 span；vLLM 需要开启 stream_options 才能拿到 token 用量；AWS X-Ray 默认 1% 的采样率会丢弃大部分追踪，开发阶段建议设为 100%；并开启 Amazon CloudWatch Transaction Search、设置 AGENT_OBSERVABILITY_ENABLED=true、以 opentelemetry-instrument 作为容器命令。该模式还可进一步扩展，例如把 Amazon S3 上的微调模型替换进来，在同一 SageMaker 端点上对基础版与微调版做 A/B 测试，或把简单查询路由给 Haiku、把多步推理任务保留给 SageMaker GPU 端点。
总体来看，这套方案的价值在于它把模型选择从“要么全托管、要么全自建”的二选一中解放出来：编排与预算类轻量任务走 Bedrock 托管模型，领域性强或需要成本优化的推理任务走 SageMaker 自托管模型，再由 AgentCore 运行时统一托管会话、扩展与可观测性。对已经使用 Strands Agents 或 LangGraph 这类框架的团队来说，迁移成本相对可控，真正的工程量集中在补齐跨模型提供方的遥测缺口上。