AWS 多智能体工作流：SageMaker AI 与 Bedrock AgentCore 集成指南
本文介绍如何将 Amazon SageMaker AI 上的 OpenAI 兼容端点与 Amazon Bedrock AgentCore 运行时结合，构建多智能体工作流。通过部署 Qwen 3.5 9B 模型，实现成本优化、数据驻留和模型灵活性，并解决 token 级可观测性问题。适合 AWS 开发者与 AI 架构师。
一句话看懂
AWS 发布新方案，将 SageMaker AI 上的自部署模型（如 Qwen 3.5 9B）与 Bedrock AgentCore 运行时结合，构建多智能体工作流，并解决 token 级可观测性难题。
详细发生了什么
AWS 官方博客发布了一篇技术指南，展示如何构建一个多智能体工作流，其中每个智能体使用最适合其任务的模型。架构通过一个 Amazon Bedrock AgentCore 容器连接三条模型托管路径：
- 编排智能体：使用 Bedrock 上的 Claude Haiku 4.5，负责分类用户意图，并通过全局跨区域推理路由任务。
- 预算智能体：使用 Bedrock 上的 Claude Sonnet 4.6，处理 50/30/20 预算分解，输出结构化 Pydantic 结果。
- 财务分析智能体：使用 SageMaker AI 上的 Qwen 3.5 9B，进行股票分析和投资组合构建，支持 tool calling。
用户请求进入编排智能体，编排智能体使用 Strands Agents 的“agents as tools”模式，将请求路由到预算或财务分析智能体。财务分析智能体通过 OpenAI 兼容 API 调用 SageMaker 实时端点。
部署步骤包括：使用 vLLM DLC 镜像在 ml.g6e.2xlarge 实例上部署 Qwen 3.5 9B；使用 Strands Agents 构建多智能体系统，处理 bearer token 自动刷新；最后通过 bedrock-agentcore-starter-toolkit 部署到 AgentCore 运行时。
关键挑战是：AgentCore 自动为 Bedrock 模型调用生成带 token 计数的 span，但对 SageMaker OpenAI 兼容端点不识别为生成式 AI 调用，导致 token 使用不可见。解决方案是手动发出 OpenTelemetry span，从 AgentResult.metrics.accumulated_usage 提取 token 使用。
中文圈视角
对于中文开发者，这个方案的价值在于模型灵活性：可以在 AWS 上混合使用托管模型和自部署模型，比如用 Qwen 3.5 9B 这类开源模型降低成本，同时保留 Claude 等闭源模型的能力。但需要注意：
- 国内访问：AWS 在中国区域（如宁夏、北京）提供 Bedrock 和 SageMaker 服务，但部分模型（如 Claude）可能受限，需确认可用性。
- 平替对比：国内类似方案有阿里云百炼（模型托管 + Agent 框架）和 ModelScope（开源模型部署），但多智能体编排和可观测性集成不如 AWS 成熟。
- 合规角度：数据驻留是亮点，自部署模型可确保数据不出域，符合国内数据出境要求。
- 盲点：中文社区对 AgentCore 的讨论较少，这个方案展示了如何将自部署模型无缝接入托管 Agent 运行时，值得关注。
几条值得记住的细节
- 模型选择：Qwen 3.5 9B 部署在 ml.g6e.2xlarge（1x L40S 48GB VRAM），使用 vLLM 0.22.1 镜像。
- token 刷新：使用 SageMakerAuth 类自动刷新 bearer token，避免长会话过期。
- 可观测性：手动发出 gen_ai.chat span，从 AgentResult.metrics.accumulated_usage 提取 token 使用。
- 部署区域：示例使用 us-west-2 和 ap-south-1，需根据模型可用性调整。
- 依赖库：需要安装 sagemaker-core、openai、httpx、strands-agents[otel]、yfinance、pydantic、bedrock-agentcore。
一句话总结
这个方案让开发者能灵活组合自部署和托管模型，同时获得完整可观测性，是构建生产级多智能体应用的有力参考。