2026年8月14日，AWS机器学习博客发布了一篇标题朴素但内涵深远的技术文章：「Building agentic workflows with SageMaker AI and Bedrock AgentCore」（用SageMaker AI和Bedrock AgentCore构建Agentic工作流）。

作者是Ayush Sharma、Shabna MT和Vivek Gangasani三位AWS工程师。文章的表面形式是一篇技术How-to：一步步演示如何把Qwen 3.5 9B部署到Amazon SageMaker AI，然后通过Strands Agents框架将它集成进一个同时运行Claude Haiku 4.5和Claude Sonnet 4.6的多Agent工作流，最后把整套系统交付到Bedrock AgentCore运行时管理。

但如果你只把它看作技术教程，你错过了这篇文章真正重要的东西。

这是AWS对”企业AI未来应该长什么样”的一次完整的架构声明。

一、三个Agent，三种模型，一个工作流

AWS的示例架构实现了一个金融场景下的智能预算规划系统，由三个专职AI Agent协作完成：

编排Agent（Orchestrator）：使用Claude Haiku 4.5在Amazon Bedrock上运行。负责解析用户请求意图，决定将任务路由给哪个下游Agent，通过跨Region全局推理实现低延迟响应。

预算规划Agent（Budget Agent）：使用Claude Sonnet 4.6在Amazon Bedrock上运行。专门处理50/30/20预算分配规则（50%必需支出，30%可选支出，20%储蓄/投资），使用结构化的Pydantic数据模型输出，确保数据格式严格一致。

金融分析Agent（Financial Analysis Agent）：使用Qwen 3.5 9B，部署在Amazon SageMaker AI上，通过OpenAI兼容接口接入。负责股票分析和投资组合构建，运行Tool-calling工具调用。

三个Agent通过Bedrock AgentCore容器统一管理，所有模型调用路径汇聚到一个生产就绪的运行时环境中。

这个架构图传达的第一个关键信息：没有任何一个模型需要包揽所有能力。最优的AI生产系统是模型专化与协作的结合——不同的任务选择最适合的模型，而不是用同一个最强的模型来解决所有问题。

二、为什么要在Claude旁边放一个Qwen？

这是这篇文章里最反直觉的设计选择，也是最值得深究的一个细节。

AWS是Anthropic的战略投资者和主要云基础设施合作伙伴，Amazon Bedrock是Anthropic Claude系列模型的主要分发渠道之一。按照常规逻辑，AWS的官方技术教程应该展示”全Claude”方案——三个Agent全用Claude，简洁、统一、符合商业逻辑。

但AWS工程师在这篇文章里选择了把Qwen 3.5 9B放进这个工作流，并通过SageMaker AI进行自定义部署。这个选择揭示了AWS的几个核心判断：

一、成本优化是生产级AI的硬约束。Claude Sonnet 4.6是高性能模型，相应成本较高。Qwen 3.5 9B是一个中等规模的开放权重模型，部署在SageMaker上的成本结构与Bedrock上的API调用完全不同。在特定场景（如大批量金融数据分析）里，用一个经过微调的领域专属小模型替代旗舰模型，可以在维持结果质量的同时大幅降低推理成本。

二、数据主权和本地部署需求是企业真实存在的刚性需求。把模型部署在自己的SageMaker实例上，数据不必离开客户的AWS账户边界——这对金融、医疗、政府等受高度监管的行业至关重要。Bedrock上的托管API调用无法满足某些严格数据合规场景的要求。

三、模型多样性本身是竞争优势，而非技术债。在企业AI架构中，依赖单一模型供应商是一种战略风险。多模型架构带来的灵活性——能够在不同任务节点选择最优模型——本身就是有价值的能力。

这三个判断合在一起，构成了AWS反对”AI单供应商锁定”的架构主张：开放性是企业AI基础设施的第一原则。

三、Bedrock AgentCore：AWS的Agent运营平台战略

理解这篇文章的另一个关键是搞清楚Amazon Bedrock AgentCore到底是什么。

AgentCore不是一个AI模型，也不是一个Agent框架——它是一个Agent运行时管理平台。它的功能是：统一接收来自不同模型来源的Agent容器，为它们提供标准化的部署、监控、观测性（observability）和生命周期管理。

在AWS的设计里，无论一个Agent里运行的是Claude、Qwen还是其他任何模型，都可以被打包成一个标准AgentCore容器，统一纳入管理。这意味着：从运营管理的视角，多模型多Agent系统不再是一个需要为每个模型单独维护的”技术孤岛集合”，而是一个标准化的、可统一监控和管理的服务集群。

这个设计思路和AWS十年前推出的ECS（弹性容器服务）逻辑高度相似：容器化技术本身并不是AWS发明的，但AWS提供了一个统一的运行时管理层，让容器化部署变得可以工业化操作。现在AgentCore在对AI Agent做同样的事。

AWS的市场定位因此非常清晰：不争做最好的AI模型，而争做AI Agent的”运营层”。模型可以是任何人的，但运行时管理、监控、安全边界、成本控制——这些基础设施的控制权在AWS。

这是云计算公司参与AI竞争的战略核心逻辑：拥有”土地”（算力、存储、网络），同时拥有”规则”（运行时标准、安全策略、成本管理）。

四、OpenAI兼容接口：互操作性的战略意义

AWS在这篇文章里特别强调了Qwen 3.5 9B通过”OpenAI兼容端点”接入整个工作流的实现方式。

这个技术细节远比它表面上看起来重要。

OpenAI API已经成为AI行业事实上的接口标准——不是因为OpenAI的技术做了什么标准化努力，而是因为市场上绝大多数开发工具、框架和库都率先支持了OpenAI的API格式。Hugging Face的模型部署工具可以用它，LangChain和LlamaIndex默认支持它，绝大多数AI应用的代码库也是围绕它构建的。

AWS在SageMaker AI上实现OpenAI兼容端点，意味着：任何可以被部署在SageMaker上的开放权重模型，都可以无缝接入原本为OpenAI API设计的整个应用生态——不需要重写代码，不需要修改框架，不需要适配层。

这个决定的战略含义是：AWS并不是在说”我们的API格式更好”——他们是在说”我们的平台让你保留你已有的技术投资”。这对企业的迁移成本考量极为重要。

更深层的含义：这也是AWS在悄悄推进一种”模型中立”的互操作标准。Qwen今天能用OpenAI兼容接口接入AgentCore，理论上任何符合这个接口标准的开放权重模型都可以——包括Mistral、Llama系列、DeepSeek系列乃至各种垂直领域微调模型。

云计算的历史教会我们：谁定义了基础设施层的互操作标准，谁就在很大程度上掌握了上层应用的归属权。

五、可观测性（Observability）：生产AI的最后一公里

这篇AWS博客还有一个不那么显眼但极具实践价值的细节：文章专门介绍了如何获取SageMaker端点的”token级别可观测性（token-level observability）”——因为Strands Agents框架本身默认不提供这个能力。

这个问题听起来像是技术细节，但它是AI系统从”能用”到”可管理”的关键差距。

在传统软件系统里，可观测性由三个支柱构成：日志（Logs）、指标（Metrics）、追踪（Traces）。工程师能看到系统在每一个时刻做了什么、做得怎么样、在哪里出了问题。

在早期的AI Agent系统里，这套机制是缺失的——你知道最终输出了什么，但你不知道中间的推理过程消耗了多少token（成本不可预测），不知道哪个Agent节点是瓶颈（优化无从下手），不知道整个工作流里哪里失败了（故障排查困难）。

AWS在这篇文章里提供了一种用Strands Agents结合自定义token追踪实现完整可观测性的方法——这是把AI Agent纳入企业运营标准体系的技术基础。

没有可观测性，就没有生产级AI。这个判断，对于任何想把AI Agent从POC推进到规模化运营的企业工程师，都是最重要的工程原则之一。

六、多视角：这个架构选择有什么被忽视的代价？

AWS博客展示的是成功路径，但这个架构设计也带来了真实的工程挑战：

多模型协作的延迟叠加问题：三个Agent串行或并行调用时，每个模型的响应延迟都会叠加。在实时交互场景（如即时客服），多模型多Agent架构是否能维持可接受的响应速度，是一个需要根据具体业务需求仔细评估的工程问题。

专有SageMaker部署的运维负担：将Qwen 3.5 9B部署在SageMaker上，相比直接使用Bedrock的托管API，意味着用户需要自行管理模型更新、Endpoint扩缩容、故障恢复等运维工作。这不是零成本的灵活性。

多模型体系的一致性风险：当不同Agent使用不同模型时，不同模型的输出风格、知识截止日期、幻觉概率各不相同。如何在多模型协作中维持整体输出的一致性和可信度，是一个尚未有通用解法的工程和设计难题。

供应商依赖的新形式：虽然AWS强调了”模型中立”，但把Agent管理统一在AgentCore下，意味着整个运营层（监控、部署、安全策略）深度绑定了AWS。换一个云厂商意味着整套AgentCore的迁移——这是另一种形式的平台锁定。

结语：AWS的架构主张与AI基础设施的竞争格局

这篇官方博客代表了AWS对企业AI基础设施的完整主张，可以总结为三个核心立场：

第一，开放胜于封闭：最优的企业AI系统应该能够混合使用任何来源的模型，而不是锁定在单一供应商的模型栈里。

第二，运营层的价值高于模型本身：AgentCore作为统一运行时平台，才是AWS真正的战略资产——模型只是运行在上面的workload，而管理这些workload的基础设施属于AWS。

第三，可观测性是从实验到生产的必要条件：没有token级别的追踪和成本可见性，任何AI Agent系统都无法真正进入企业的生产环境。

这三个立场，与OpenAI的企业策略（高度集成、模型中心、平台绑定）和Anthropic的策略（Claude为核心、安全为品牌、企业API为主要渠道）形成了鲜明对比。

没有一种策略天然正确——市场最终将由企业客户的实际选择来裁定。但AWS的开放架构主张，对于那些有数据主权顾虑、有多云策略、有成本控制压力的大型企业客户，有着不容忽视的吸引力。

这场AI基础设施的架构之战，刚刚开始分出第一条清晰的战线。

三大云厂商的企业AI基础设施战略全对比：AWS vs Azure vs Google Cloud

要真正理解AWS选择”开放多模型+运行时管理”这条路的战略意义，必须把它放在三大云厂商的整体竞争框架里对比分析。

微软Azure：垂直整合+生态绑定

Azure的企业AI策略以”高度垂直整合”为核心。Azure AI Foundry把模型部署、微调、评估、应用发布整合在一个统一界面里；Azure OpenAI Service以独家权利分发OpenAI系列模型，为企业提供了”ChatGPT/GPT-4能力+Azure安全合规”的组合；Copilot深度集成Office 365，让AI能力直接嵌入企业员工的日常工作流。

这个策略的优势是：对于已经深度投入微软生态的企业（Exchange、SharePoint、Teams、Dynamics 365），Azure的AI价值主张极为清晰——你不需要额外的集成工作，AI能力就已经在你的工作流里了。

但局限性也同样清晰：如果你不在微软生态里，或者你需要使用GPT之外的模型，Azure的整合优势就大幅削减。Azure虽然也通过Azure AI Catalog提供包括Meta Llama、Mistral等开放模型，但整体设计理念仍然是”在Azure生态里选模型”，而不是”把任意地方的模型都用在Azure上”。

Google Cloud：Gemini内部生态优先

Google Cloud的企业AI战略围绕Gemini生态构建。Vertex AI Agent Builder是Google的Agent平台，深度整合Gemini系列模型，并利用Google在搜索（Grounding/RAG）、翻译（多语言）、Office文档（Workspace AI）等方面的独特能力。

Google的优势是：Gemini在特定场景里（如长上下文处理、多模态任务、代码生成）有明确的技术领先；Google Workspace的用户基础庞大，Workspace AI的自然渗透路径天然存在。

但Google Cloud的商业执行能力在企业市场一直是弱点——Google的企业销售和实施服务历史上都不如AWS和Azure成熟。更重要的是，Gemini生态对第三方模型的开放程度不如AWS，这使得数据主权和模型多样化需求强烈的企业客户可能选择其他平台。

AWS：开放多模型+运营层统一

AWS的策略与前两者截然不同：它不强推某一个特定模型（虽然通过Anthropic合作关系和Bedrock平台分发Claude系列），而是构建一个能够统一管理任意来源模型的运营基础设施。

AgentCore的价值主张直接针对”多模型时代的运营复杂度”问题：随着企业在生产中同时使用5-10个不同的AI模型（各有其最擅长的任务类型），如何统一监控、统一安全策略、统一成本分析——这个运营层问题，正在成为企业AI架构师最棘手的日常挑战之一。

AWS的”开放运营层”策略，理论上是三种策略中对模型供应商锁定风险最小的——这对那些正在思考”5年后AI模型格局变了怎么办”的大型企业CTO，有着特殊的战略吸引力。

对中国企业的特殊含义：数据主权与模型主权的双重关切

这篇AWS博客在中国企业AI从业者群体里引发了一些额外的讨论，值得在这里展开。

在中国市场，企业AI决策的考量维度比其他市场多了两个关键约束：数据主权（数据不能出境，不能传输到境外服务器）和模型主权（对使用境外模型的监管不确定性）。

AWS中国区（由光环新网和西云数据运营）的存在为中国企业提供了”使用AWS基础设施但数据留在境内”的选项。但更重要的是，SageMaker AI上自部署Qwen 3.5 9B的架构，对中国企业来说代表了一种特别有价值的技术路径：

第一，Qwen来自阿里巴巴/通义，是中国企业在合规层面最无顾虑的大语言模型选项之一；第二，SageMaker的自部署意味着模型权重在自己控制的基础设施上，不涉及向境外传输模型推理请求；第三，AgentCore的多模型管理层可以在中国区部署，统一管理本地化模型的Agent工作流。

这是一个”AWS基础设施+中国本土大模型+本地数据合规”的完整技术组合方案——对于在中国运营的跨国企业（需要同时满足中国数据合规和全球AI能力需求），这个架构有着难以替代的实用价值。

附：为什么这场架构之战值得关注——历史的三次重演

技术行业有一个反复出现的历史模式：每一次重大技术范式转变期，基础设施标准的控制者都会在价值链中跃升为最重要的角色。

第一次是互联网时代。早期互联网是异质化的——不同网络用不同协议通信。TCP/IP成为统一标准之后，掌握网络设备和带宽的公司（思科、AT&T）成为了这个时代的核心基础设施控制者。

第二次是云计算时代。虚拟化技术让计算资源变成了可以按需分配的商品，AWS通过率先将这种商品标准化并以服务形式提供，建立了云基础设施主导地位——即便今天微软Azure和Google Cloud合在一起超过AWS，AWS依然是云原生标准和工具链中最重要的参照系。

第三次，可能就是现在发生的AI Agent时代。AI模型已经是商品化的趋势（价格战、开源、多供应商），真正的争夺正在转移到”Agent运行时”层：谁的管理框架成为标准，谁就获得了在AI时代扮演AWS在云计算时代那种角色的入场券。

AWS发布AgentCore并建立OpenAI兼容接口标准，是它在这场争夺中最明确的一次战略落子。

Google Cloud的对应产品是Vertex AI Agent Builder；微软的是Azure AI Foundry；Anthropic直接打造了Claude的Enterprise计划和Agent API。

但在这个多方角力的生态中，AWS的优势在于：它是最大的企业云基础设施提供商，大多数想要部署AI Agent的企业，其核心数据和计算已经跑在AWS上。当AgentCore可以无缝接入这个既有的企业AWS环境，迁移摩擦就降到了最低。

这不是模型能力的比赛，而是一场生态锁定的静默战争。AWS这篇博客——用Qwen和Claude在同一个Agent工作流里协作——是这场战争迄今最清晰的一次公开示范。

延伸思考：开发者视角的真实问题

在技术社区，这篇AWS博客发布后引发了一些有价值的讨论。一些开发者提出了以下问题，值得记录在这里：

问题一：Strands Agents是一个足够成熟的多Agent框架吗？ 相比LangGraph、AutoGen、CrewAI等已有较大社区的框架，Strands Agents的生态相对年轻。AWS推荐它的部分原因可能是它与AgentCore的深度集成——而不单纯是技术上最优选择。选择框架时需要考量长期社区支持的稳定性。

问题二：这个三Agent架构对所有金融场景都适用吗？ 博客展示的是一个相对标准的个人财务规划用例（50/30/20预算）。对于需要处理非结构化监管文件、多语言客户请求或实时市场数据的真实金融机构场景，架构的复杂度会显著提升，相应的工程成本和运维负担也会加大。

问题三：token-level observability的成本是多少？ 增加详细的token追踪会带来额外的计算和存储开销。在超大规模部署中，可观测性基础设施本身的成本可能不可忽视，需要根据业务场景在可观测性精度和成本之间找到平衡点。

这些问题没有唯一正确答案，但它们提醒我们：AWS博客展示的是一个可行的方向，不是一个开箱即用的解决方案。真实的企业实施，始终需要在架构原则和具体约束之间进行复杂的权衡。

更深一层：SageMaker + AgentCore组合意味着什么竞争压力

单独看AgentCore，它是一个Agent运行时管理工具。单独看SageMaker，它是一个机器学习模型训练和推理平台。但当AWS将这两者紧密结合，并通过一篇详细的技术博客对外展示它们的集成路径，背后传递的信号是：AWS正在把”模型训练到Agent部署”的完整链条整合进一个统一的基础设施体系。

这对以下几类企业用户的影响尤为深远：

已有自研模型的大型企业：许多金融机构、医疗集团、制造业企业在过去两年里已经投入资源在SageMaker上微调了适合自己业务的专属模型。此前这些模型主要服务于内部预测和分类任务，与对话式AI Agent能力相对割裂。SageMaker+AgentCore的组合让这些已有的专属模型可以直接”升级”为生产级AI Agent的执行节点，过去的模型训练投资找到了新的应用出口。

有数据主权法规约束的跨国企业：欧盟GDPR、中国数据安全法、印度个人数据保护法等不同司法管辖区的数据主权要求，使得某些数据类型必须在特定地理区域内的服务器上处理。SageMaker的区域化部署加上AgentCore的统一管理接口，理论上可以支持”每个区域有自己的本地模型实例，但通过统一的Agent编排层协调工作”——这是跨国企业实现合规与智能化平衡的关键架构路径。

想要减少OpenAI/Anthropic API依赖的企业：在硅谷之外，很多企业已经开始认真讨论”AI主权”问题——不希望核心业务逻辑完全依赖于由几家美国公司控制的云API。Qwen 3.5 9B通过SageMaker自部署的路径，给了这些企业一个可行的技术选项：使用开放权重的非美国来源模型（Qwen来自阿里巴巴/通义）处理敏感任务，通过AgentCore与其他模型协作完成更复杂的工作流。这不是反美国化，而是企业IT策略里的”供应商多元化”原则在AI时代的延伸。

AWS这篇技术博客，在平静的工程语言下，藏着深刻的地缘政治与商业战略考量。

结语：一篇技术博客的系统性信号

“Building agentic workflows with SageMaker AI and Bedrock AgentCore”——这篇2026年8月14日发布的AWS工程博客，表面上是一篇给高级工程师看的How-to教程。但任何在AI行业工作的人，读到其中「Qwen和Claude在同一个工作流里各司其职」的设计选择，都不应该把它当作一个随机的技术决策。

它是AWS在AI Agent时代的一次完整的战略表态：基础设施应该是开放的、可组合的、不偏向任何单一模型供应商的——而AWS将成为这个开放生态中的管理层和运营层。

如果这个判断成立，那么未来三到五年内，企业AI基础设施领域最关键的竞争维度，将不是「哪个模型更聪明」，而是「谁的Agent运行时管理平台成为事实标准」。

这场竞争，已经悄然开始了。更重要的是，这场竞争的结果将深刻影响未来十年哪些企业能够真正掌控自己的AI命运，而哪些企业将再一次把核心技术主权交给少数几家科技巨头托管。选择在今天，就已经在发生了。

AWS这篇博客在发布后的48小时内，在技术社区（HackerNews、Reddit r/MachineLearning、Twitter/X的AI工程师圈子）引发了相当热度的讨论。除了前面提到的技术问题之外，还有一个有趣的元讨论：为什么是Qwen 3.5 9B？在AWS可以选择任意开放权重模型的情况下，选择一个来自中国阿里巴巴的模型作为示例，是一个纯粹的技术决策（Qwen在特定任务上的表现确实优秀），还是一个带有地缘政治信号的战略声明（我们不偏向任何一国的模型生态）？

技术社区的共识倾向于前者——Qwen 3.5 9B在工具调用（Tool-calling）和金融分析类任务上的实际表现，在同等规模模型中确实处于较高水平。但地缘政治解读也并非没有道理——在中美AI竞争日益激烈的背景下，一家美国最大云服务商在官方技术博客里展示一个中国AI公司的模型，本身就是一个值得记录的行业信号。

这个问题没有”正确答案”，但它提醒我们：即使是最技术性的工程博客，在2026年的AI地缘政治背景下，也可能承载超出技术意义的信号价值。

技术本身是中性的，但技术选择背后的战略意图从来不是。

参考来源：

  1. AWS官方博客 “Building agentic workflows with SageMaker AI and Bedrock AgentCore” — aws.amazon.com/blogs/machine-learning/ by Ayush Sharma, Shabna MT, Vivek Gangasani (2026-08-14)
  2. Amazon Bedrock AgentCore产品文档 — AWS官方文档
  3. Strands Agents开源框架 — strandsagents.com
  4. “AWS Vs. Microsoft Vs. Google Cloud Earnings Q2 2026 Face-Off” — CRN (2026-08-03)
  5. “Cloud Market Share Q2 2026: Google Gains Share As AWS Falls” — CRN/Synergy Research Group (2026-08-06)
  6. “Amazon’s AWS posts fastest growth since 2021, citing AI and chip demand” — CNBC (2026-07-30)