用 SageMaker AI 与 Bedrock AgentCore 构建多智能体工作流

多智能体系统的核心挑战之一，是让不同来源的模型在同一框架内协同工作。AWS 在这篇技术文章中展示的架构，通过单一 Amazon Bedrock AgentCore 容器连接三条模型托管路径：Bedrock 上的 Claude Haiku 4.5 担任编排智能体，负责识别用户意图并将任务分发给下游专职智能体；Claude Sonnet 4.6 负责处理 50/30/20 预算分配并输出结构化 Pydantic 结果；部署在 SageMaker 实时端点上的 Qwen 3.5 9B 则专注于股票分析与投资组合构建，并支持工具调用。

在模型部署层面，Qwen 3.5 9B 通过 vLLM 深度学习容器（镜像版本 vllm:0.22.1-gpu-py312-cu130）部署在 ml.g6e.2xlarge 实例上，该实例配备单块 L40S GPU（48GB 显存）。部署时通过环境变量指定模型 ID、张量并行度和最大上下文长度，随后创建 SageMaker 端点配置并启动端点。整个部署流程通过 SageMaker Python SDK 完成，无需手动管理容器镜像拉取或服务启动脚本，大幅降低了自定义模型上线的运维成本。

SageMaker AI 的 OpenAI 兼容 API 需要 Bearer Token 进行鉴权，且 Token 存在过期问题，这对长时间运行的智能体会话构成挑战。文章给出的解决方案是继承 httpx.Auth 类，实现 SageMakerAuth，在每次请求的 auth_flow 方法中动态调用 generate_token 生成新 Token 并注入请求头。这一机制与 AsyncOpenAI 客户端无缝集成，使 Strands Agents 框架可以像调用标准 OpenAI 端点一样调用 SageMaker 上的 Qwen 模型，无需修改上层智能体逻辑。

多智能体协作采用 Strands Agents 的「智能体即工具」模式，即将专职智能体封装为可被编排智能体调用的工具函数。值得注意的是，文章建议每次调用时创建全新的智能体实例，而非复用同一实例，以避免跨请求的状态污染。编排智能体持有预算智能体工具和金融分析智能体工具，根据用户意图自动选择路由，整个调度过程对用户透明，最终结果统一由编排层汇总返回。

可观测性是生产环境不可忽视的环节。Amazon Bedrock AgentCore 运行时会自动为智能体注入 OpenTelemetry 埋点，Bedrock 原生模型调用可获得完整的生成式 AI Span，包含 Token 用量统计。然而，通过 Strands OpenAIModel 调用的 SageMaker 端点默认不在此埋点范围内，导致 Qwen 模型的 Token 消耗和延迟数据在监控系统中不可见。文章详细介绍了如何通过自定义回调和 OpenTelemetry 手动补全这一观测缺口，确保跨模型提供商的成本与性能数据完整可查。

整套工作流最终通过 bedrock-agentcore-starter-toolkit 打包部署至 Amazon Bedrock AgentCore 运行时，工具包支持自动创建 IAM 执行角色和 ECR 镜像仓库，并通过 requirements.txt 管理依赖。部署时可通过环境变量注入 SageMaker 端点名称、区域及可观测性开关，实现配置与代码分离。这一架构将成本优化（使用更小的领域模型）、数据驻留（SageMaker 端点可部署在指定区域）与模型灵活性（随时替换底层模型）统一在同一生产就绪的框架内，为企业级多智能体系统提供了可复用的工程范式。

要点

• SageMaker OpenAI 兼容端点可通过自定义 httpx.Auth 子类实现 Bearer Token 自动刷新，解决长会话鉴权过期问题
• Strands Agents 的「智能体即工具」模式支持异构模型协作，建议每次调用创建新实例以避免状态污染
• Bedrock AgentCore 的 OpenTelemetry 自动埋点不覆盖 SageMaker 端点，需手动补全 Token 级可观测性
• 将专职小模型（如 Qwen 3.5 9B）与通用大模型（如 Claude 系列）混合编排，可在性能与成本之间取得更优平衡
• bedrock-agentcore-starter-toolkit 可一键完成角色创建、镜像构建与运行时部署，显著降低多智能体系统的上线门槛