AWS发布如何使用SageMaker AI模型和MLflow可观测性构建Strands智能体：SageMakerAIModel提供者、自动日志追踪和A/B测试变体

AWS机器学习博客发布了关于如何使用三个组件构建AI智能体的详细技术指南：开源Strands Agents SDK、用于模型托管的Amazon SageMaker AI端点，以及用于可观测性的SageMaker AI Serverless MLflow。对于因操作或监管原因无法完全依赖Amazon Bedrock等托管服务的组织而言，该指南具有重要参考价值。

什么是Strands Agents

Strands Agents是一个「只需几行代码即可构建和运行AI智能体的模型驱动方法的开源SDK」。在架构上，该框架结合三个组件：

• 语言模型（进行推理的LLM）；
• 系统提示（角色和行为的定义）；
• 工具集（智能体可以调用的函数列表）。

这种极简模式与其他智能体SDK（LangChain、AutoGen、CrewAI）类似，但模型驱动的理念——让智能体将决策交给模型而非将其编码为僵化的工作流程——是其独特特征。

为何选择SageMaker而非Bedrock

AWS在文章中明确列出了组织选择自管理SageMaker端点而非托管Bedrock服务的四个原因：

• 基础设施控制——对计算实例、VPC网络和安全设置的控制；
• 模型灵活性——自定义模型、微调变体、Bedrock目录中未必有的开源模型；
• 成本可预测性——预留实例和竞价定价使运营成本变异系数降低；
• 高级MLOps——模型注册表、A/B测试、版本管理。

Strands SDK包含**SageMakerAIModel提供者，允许智能体使用运行Qwen3**或其他开源LLM的端点。

MLflow作为可观测性层

该指南增添的主要价值是与SageMaker AI Serverless MLflow的集成：

• 自动记录执行追踪；
• 工具使用模式（智能体何时调用哪个工具）；
• 决策工作流程（哪条推理路径导致了最终动作）。

激活是声明式的——代码中只需一次mlflow.strands.autolog()调用——无需自定义仪器化。这实现了监管框架越来越多要求的两件重要事情：

• 生产环境中对智能体行为的监控；
• 允许对决策进行追溯分析的审计追踪。

这在欧盟AI法案的背景下特别相关，其第12条要求自动日志记录，第72条要求市场后监控。

实施流程：五个步骤

AWS在文章中描述了五步工作流：

• 通过SageMaker JumpStart部署基础模型；
• 使用引用已部署端点的SageMakerAIModel创建Strands智能体；
• 通过mlflow.strands.autolog()启用自动日志记录；
• 部署多个模型变体进行并行A/B测试；
• 通过带有自定义评分器的MLflow GenAI评估框架****评估智能体。

第4步（A/B测试）在生产开发的背景下特别有用——组织可以逐渐将流量转移到新变体并测量质量和成本差异，而非冒险进行「大爆炸」式迁移。

突出的应用场景

AWS为四类工作负载推荐此架构：

• 有严格延迟要求的对话AI——共享托管服务对p99延迟的控制不够充分；
• 需要可预测成本的高容量应用——托管服务的按令牌计费成为主要成本；
• 有数据驻留要求的合规敏感部署——需要对位置和加密进行精确控制；
• 模型实验——完整迁移前的系统A/B测试。

实践启示

对于已在AWS上工作的团队的三点考量：

• MLflow集成开销低，无需大规模重构即可引入现有智能体实现；
• SageMakerAIModel提供者开放了Bedrock目录以外的本地或区域性开源模型的大门，这对希望控制数据驻留的欧洲组织具有重要意义；
• 智能体变体的A/B测试不仅仅需要部署——还需要定义的质量指标（自定义评分器）和流量引导策略。

该指南技术性较强，面向已有SageMaker经验的实践者。对于在AWS环境中开始使用智能体的团队，它定义了一种标准架构——Bedrock托管服务的替代方案，拥有更多控制但也有更大操作责任。