## 从静态报表到对话式洞察：NarrateAI 的诞生 在 AWS 的销售、营销和全球服务（SMGS）组织中，管理层每天需要处理跨层级的复杂数据，并做出影响全球运营的时间敏感决策。传统的商业智能工具依赖静态仪表盘和人工报告，这种模式不仅耗时，还限制了组织的敏捷性。为此，AWS 团队构建了 **NarrateAI**——一个基于 **Amazon Bedrock AgentCore** 和自有数据湖的智能对话解决方案，通过自然语言问答为从 CEO 到一线经理的各级领导者提供即时、准确的业务洞察。 ## 两大核心挑战：数据碎片化与时间消耗 AWS 在传统 BI 实践中面临三大障碍： - **时间密集型准备**：领导者需要手动从多个仪表盘收集数据、核对不同来源的信息，并综合成报告，留给战略思考的时间所剩无几。 - **数据碎片化**：业务见解分散在不同系统和仪表盘中，指标不一致，难以形成统一的业务全貌。 - **有限的可访问性**：复杂仪表盘需要专业知识才能操作，导致领导者依赖中间团队，无法按需获取洞察，决策被延迟。 ## 技术架构：双层分离，智能协同 NarrateAI 采用**双层架构**，将批处理与实时交互解耦： 1. **批处理层**：负责从数据湖中定期提取、清洗和聚合数据，生成预计算的业务指标和上下文信息，确保查询响应速度。 2. **实时交互层**：通过 Amazon Bedrock AgentCore 驱动，部署了多个**专门化 AI Agent**，分别负责意图识别、智能路由、数据验证和答案生成。这些 Agent 协同工作，确保用户问题被准确理解，并从正确的数据源获取信息，最终以自然语言形式返回带上下文的洞察。 ## 关键工程模式与生产部署 团队在开发过程中提炼了若干可复用的工程模式： - **智能路由与验证**：利用 Agent 的编排能力，将问题分类并路由到最合适的子 Agent，同时内置验证机制，防止错误数据进入答案。 - **生产级部署**：采用 Amazon Bedrock 的托管服务，结合 AWS 的安全与监控能力，实现高可用和低延迟。 - **可扩展性设计**：架构支持轻松添加新的数据源和业务域，适应组织增长。 ## 实际效果与启示 NarrateAI 上线后，显著缩短了领导者的数据准备时间，从数小时降至秒级。CEO 等高层可以直接用自然语言询问“上周北美区的销售达成率是多少？与目标差距如何？”，系统即可返回带趋势分析和异常提示的答案。这不仅提升了决策效率，也让业务团队更专注于战略分析而非数据搬运。 对于希望构建类似解决方案的团队，AWS 建议从明确业务问题域开始，优先解决数据一致性，并利用 Bedrock AgentCore 的编排能力快速迭代。NarrateAI 的实践表明，对话式 AI 正成为企业级 BI 的下一个演进方向。
随着 AI 智能体在企业内大规模部署，一个典型难题浮出水面：**智能体泛滥但缺乏编排**。AWS 销售团队曾拥有超过 20 个领域专用智能体，销售代表需要自行判断该用哪个、手动拼接结果，认知负担沉重。为此，AWS 内部构建了 **Field Advisor**，基于 **Amazon Bedrock AgentCore** 打造统一编排层，让销售代表只需用自然语言提问，系统自动路由到正确的智能体或工具，并维护上下文、协调审批、返回统一答案。 ## 核心挑战：智能体越多，选择越难 在 AWS 销售组织内，超过 20 个智能体分别负责 CRM 操作、会议安排、客户洞察、产品推荐、合规检查等任务。销售代表需要记住每个智能体的用途，并在不同系统间频繁切换，手动整合信息。这种“认知切换”消耗了大量本应用于客户沟通的时间。 ## 为什么选择 Bedrock AgentCore AWS 内部团队选择 Bedrock AgentCore 的关键原因在于其**企业级编排能力**： - **隔离执行环境**：支持安全的多租户操作 - **统一网关**：跨 AWS 账户访问工具和智能体 - **持久化记忆**：维护会话和长期上下文 - **一致的身份传播**：集成 OAuth，权限清晰 - **内置可观测性**：追踪复杂请求流 - **持续质量监控**：集成评估机制 这些能力让工程团队无需自建基础设施，专注于提升领域智能。 ## Field Advisor：统一入口，消除认知负担 Field Advisor 作为中央编排层，销售代表用自然语言提问，系统自动： 1. **路由请求**到正确的智能体或工具 2. **维护跨多轮交互的对话上下文** 3. **协调敏感操作的审批流程** 4. **返回统一、连贯的响应** 最终，销售代表可以更快、更准确地获取所需信息，专注于客户对话而非系统操作。 ## 可衡量的业务价值 通过 Field Advisor，AWS 销售团队实现了显著的效率提升： - **减少系统切换时间**：统一入口避免了手动选择智能体 - **上下文连续性**：跨会话的记忆减少了重复提问 - **加速响应**：从多步操作变为单次自然语言交互 虽然具体数字未公开，但该方案已在全球 AWS 销售组织中部署，证明了其可扩展性和实际价值。 ## 对 AI 行业的启示 Field Advisor 的案例揭示了一个关键趋势：**智能体的价值不在于数量，而在于编排**。当企业部署多个 AI 智能体时，缺乏编排会导致“智能体泛滥”问题，反而增加用户负担。编排层（如 AgentCore）成为必要的基础设施，它允许企业构建“智能体中的智能体”——一个能理解全局并协调各专业智能体的中枢。 对于正在扩展 AI 应用的企业而言，Field Advisor 的架构思路值得借鉴：先建立统一编排层，再逐步添加专用智能体，而非相反。
## 代理经济的支付瓶颈 随着生成式 AI 代理大规模自主运行，它们需要实时访问付费 API、内容和服务。然而，传统支付方式（如信用卡）每笔交易固定收取约 0.30 美元手续费，让高频、低价值的微交易（例如每次调用仅几美分）变得不切实际。同时，开发者需要为每个外部服务手动管理计费账户，集成 x402 等机器对机器支付协议，并自建预算控制和安全合规系统——这往往耗费数月时间。 ## Amazon Bedrock AgentCore Payments 预览版 Amazon Bedrock AgentCore 推出的 **AgentCore Payments**（预览版）正是为了解决这些痛点。该功能提供以下核心能力： - **即时支付**：无需为每个服务提供商手动设置计费账户，代理能直接向外部付费服务付款。 - **稳定币支持**：利用稳定币实现成本效益极高的微交易，使亚美分级别的交易经济可行。 - **可配置支出护栏**：允许开发者精细控制代理预算和交易限额，防止预算超支。 ## 技术架构与价值 AgentCore Payments 作为底层基础设施层，抽象了服务器管理、安全性和集成复杂性，让开发者专注于代理逻辑本身。它原生支持 x402 等代理协议，并内置端到端可观测性，显著缩短了从开发到部署的周期。 ## 行业影响 在代理流量日益超过人类流量的趋势下，出版商和 API 提供商正在转向按使用付费模式。AgentCore Payments 降低了代理访问付费服务的门槛，推动了“代理商业”的进化——数以亿计的代理自主选择服务并实时交易，无需人工干预。 ## 小结 AgentCore Payments 通过解决微支付的经济性和集成复杂性，为代理经济提供了关键的支付基础设施。虽然仍处于预览阶段，但它展示了未来 AI 代理大规模商业化应用的潜在路径。
生成式 AI 已从实验性原型快速演进为需要在生产环境中可靠运行、具备可扩展性并满足实际性能约束的系统。随着企业走出演示与概念验证阶段，推理延迟、扩展能力、状态管理和运维可见性等挑战日益凸显。构建高性能 AI 智能体不仅需要强大的模型，更需要能够提供一致性能、跨交互保持上下文，并在生产环境中深度观察智能体推理与行为的实现方案。 本文提出一种在 AWS 上构建高度可扩展、无服务器的多智能体生成式 AI 系统的解决方案，该方案使用 **LangGraph 智能体**作为编排器，并与 **Amazon Bedrock AgentCore Memory** 及 **Amazon Bedrock AgentCore Observability** 集成。 ### 核心技术组合 我们的方法将无服务器技术如 **AWS Lambda** 和 **AWS Step Functions** 相结合。开发者可利用这些服务构建自动扩展、实时响应事件并免去基础设施管理的 LangGraph 智能体，非常适合动态、突发的智能体工作负载。通过组合这些服务，你可以编排复杂的多工具智能体工作流，实现持久状态管理、重试机制和细粒度成本控制。 **LangGraph** 的显式图执行模型支持确定性协调、并行执行以及智能体间的条件路由，使复杂的多智能体工作流更易于推理和调试。通过将编排逻辑与智能体行为分离，你可以独立地添加、移除或演进专用智能体，同时保持清晰、可审计的执行路径。这对于需要可预测行为、可扩展性和对多智能体推理进行结构化控制的生产系统尤为宝贵。 ### 可观测性与记忆 **AgentCore Observability** 扩展了这些能力，为每次调用提供详细可见性，捕获跨分布式无服务器组件的模型输入/输出、延迟和工具链指标。**AgentCore Memory** 的集成记忆服务使智能体能够在会话之间维持短期对话上下文和长期知识。 ### 方案概览 我们的无服务器 LangGraph 与 AgentCore 基础方案将 LangGraph 智能体部署在 AWS Lambda 上，由 Step Functions 编排，并通过 AgentCore 实现统一的可观测性和记忆管理。该架构支持智能体间的动态路由、并行执行和状态持久化，同时保持完全无服务器，按实际使用量付费，无需预置基础设施。 这种设计特别适合需要处理突发流量、快速迭代智能体行为，并希望在不增加运维负担的前提下获得生产级可观测性的团队。通过将 LangGraph 的灵活编排与 AWS 无服务器生态及 Bedrock AgentCore 的专用能力相结合，开发者可以构建出既强大又易于管理的多智能体系统。
在生成式 AI 从实验走向生产的过程中，推理延迟、状态丢失与可观测性不足成为核心瓶颈。本文介绍了一种集成 **NVIDIA NIM**（GPU 加速推理）、**Amazon Bedrock AgentCore**（托管运行时与共享内存）和 **Strands Agents**（无服务器多智能体编排）的架构，用于构建高性能、可扩展的多智能体系统。以营销活动审核系统为例，展示了并行推理、上下文持久化和可追踪执行路径的实现方法，为数字助手、自动化审核和 RAG 管道等场景提供了可复用的参考模式。 ## 生产级 AI 智能体的三大挑战 当智能体系统从原型走向生产环境时，开发者普遍面临三个关键问题： 1. **推理延迟**：并发请求下，大模型推理时间显著增加，导致响应变慢，用户体验下降。 2. **上下文丢失**：无状态执行环境使智能体在多次交互间丢失对话或任务上下文，造成重复工作或输出不一致。 3. **可观测性不足**：难以诊断故障、理解推理路径或控制成本，尤其在多智能体并行协作的场景中。 ## 三合一架构解析 ### NVIDIA NIM：GPU 加速推理 NVIDIA NIM 提供针对大模型的 GPU 加速推理微服务，显著降低单次推理延迟，并支持高并发吞吐。在本系统中，NIM 负责为所有智能体提供统一的推理后端，确保响应速度满足实时需求。 ### Amazon Bedrock AgentCore：托管运行时与共享内存 Bedrock AgentCore 作为智能体的托管执行环境，提供： - **共享内存**：多个智能体可读写同一上下文，实现跨任务的状态保持。 - **内置可观测性**：自动记录执行轨迹、输入输出与耗时，便于调试与成本分析。 - **运行时管理**：自动扩缩容，无需关注底层基础设施。 ### Strands Agents：无服务器多智能体编排 Strands Agents 提供轻量级的智能体编排框架，支持： - **并行执行**：多个专用智能体同时运行，互不阻塞。 - **结果聚合**：将各智能体的输出合并为统一结果。 - **错误处理**：单个智能体失败不影响整体流程。 ## 实战：营销活动审核系统 系统包含三个并行工作的专用智能体： - **合规审核智能体**：检查文案是否违反行业法规。 - **品牌一致性智能体**：验证内容是否符合品牌指南。 - **目标匹配智能体**：评估内容与营销目标的契合度。 三个智能体通过 Strands Agents 同时启动，共享 Bedrock AgentCore 中的上下文，并使用 NVIDIA NIM 进行推理。最终结果经聚合后输出审核报告。 该模式同样适用于数字助手、自动化审核和检索增强生成（RAG）管道等场景。 ## 小结 通过将 **NVIDIA NIM** 的推理加速、**Amazon Bedrock AgentCore** 的托管运行时与共享内存、以及 **Strands Agents** 的无服务器编排相结合，开发者能够构建出低延迟、有状态且可观测的多智能体系统。这一架构为生成式 AI 从实验到生产部署提供了清晰的路径，尤其适合需要高并发、低延迟与复杂协作的企业级应用。
## 核心要点 AgentWatch 是一种基于环境代理的 AWS 主动监控方案，每 15 分钟自动执行基础设施检查，汇总 CloudWatch 指标、日志和告警，将可操作报告推送至 Slack，并支持自然语言查询。方案设计了三种人机协同模式，在提升自动化的同时保留必要的人工监督。 ## 方案概述 在云基础设施日益复杂的背景下，**AgentWatch** 通过部署“环境代理”（ambient agents）实现了对 AWS 资源的持续、主动监控。这些代理并非被动等待告警，而是定期轮询并分析 CloudWatch 中的关键指标、日志和告警，覆盖多个 AWS 账户。 ## 核心能力 - **定期检查**：每 15 分钟执行一次基础设施健康检查。 - **多账户聚合**：跨账户汇总 CloudWatch 数据，形成统一视图。 - **智能报告**：将分析结果转化为结构化报告，直接推送至 **Slack** 等协作平台。 - **自然语言交互**：用户可用日常语言查询基础设施状态，例如“过去一小时内有哪些 EC2 实例的 CPU 利用率超过 80%？”。 ## 人机协同模式 AgentWatch 特别设计了三种 **Human-in-the-Loop** 模式，以平衡自动化效率与人工决策： 1. **监督模式**：代理生成报告后，由人工审核再执行操作。 2. **半自动模式**：对低风险告警自动响应，高风险告警需人工确认。 3. **异常上报模式**：代理检测到异常时，主动通知并附带修复建议，由人决定是否执行。 ## 应用价值 AgentWatch 适用于需要 7×24 小时监控但运维团队有限的企业。通过将重复性检查自动化，运维人员可将精力集中在复杂问题处理上。同时，自然语言查询降低了数据获取门槛，非技术团队成员也能快速了解系统状态。 ## 行业背景 当前 AI 驱动的运维（AIOps）正从被动响应转向主动预防。AgentWatch 代表了这一趋势：利用轻量级代理持续感知环境，而非依赖固定阈值告警。其多账户支持尤其适合采用 **AWS Organizations** 的大型企业，能够统一管理分散的资源。 ## 小结 AgentWatch 通过环境代理实现了主动、可交互的 AWS 监控，三种人机协同模式确保了自动化与可控性的平衡。对于追求运维效率与安全性的团队，这是一个值得关注的实践方案。
## 从创意到AI应用：30行代码构建智能研究助手 构建一个AI应用，通常需要数月时间处理复杂的架构、编排多个API调用、管理对话状态，并创建能够自主推理的智能体。但借助 **Strands Agents** 和 AWS 服务，这一切可以大幅简化——仅用 **30行代码** 就能构建一个功能完备的AI研究助手。 ### 为什么选择Strands Agents？ Strands Agents 是一个开源框架，旨在降低AI应用开发门槛。它通过**模型驱动**的方式，利用大语言模型（LLM）进行自主推理和规划，开发者只需提供**提示词和工具列表**，即可创建智能体，无需编写复杂的硬编码逻辑。这对于AWS环境下的AI开发尤为重要，因为传统方式往往需要同时掌握自然语言处理、分布式系统等专业知识。 ### 背后的AWS生态支撑 AWS为智能体应用提供了多种构建选项：**Amazon Bedrock** 提供基础模型（FM）驱动智能体；**Kiro** 则是一个AI驱动的IDE，让开发者能专注于决策而非编码。Kiro Powers 是Kiro IDE的扩展能力，通过封装MCP服务器、引导文件和钩子，形成可复用的单元。例如 **Strands Power** 就捆绑了SDK文档搜索、入门指南和正确的API模式，帮助Kiro准确搭建智能体。目前已有超过50个来自AWS、合作伙伴及社区的Powers，覆盖设计、部署、安全、可观测性等领域，开发者一键安装即可开始构建。 ### 实战：30行代码构建研究助手 以构建一个AI研究助手为例，核心步骤包括： 1. 定义智能体的**目标**（如“研究某个主题并生成报告”） 2. 指定可用的**工具**（如网络搜索、文档检索、代码执行） 3. 利用Strands Agents的**模型驱动**特性，让LLM自动规划执行步骤 最终，整个智能体的核心逻辑仅需约30行Python代码。开发者无需手动编排API调用或管理状态，Strands Agents会自动处理推理链、工具调用和上下文管理。 ### 价值与展望 这种“低代码+模型驱动”的模式，正在改变AI应用开发的游戏规则。它让更多开发者——即使没有机器学习博士学位——也能快速将创意转化为实际应用。对于企业而言，这意味着更短的开发周期、更低的试错成本，以及更灵活的业务场景适配。 随着Strands Agents等开源工具的成熟，以及AWS生态的持续完善，AI应用开发正从“专家特权”走向“大众创新”。未来，或许只需一个想法和几行代码，就能构建出真正智能的助手。
当数百到数千名用户被接入企业级 AI 平台时，业务领导者和平台所有者需要了解谁在使用平台、用户对收到的答案是否满意、以及哪些功能推动了最多的参与度。如果没有集中式的可观测性方案，这些数据会分散在多个 AWS 服务中，难以整合和分析。 本文介绍如何利用 **Amazon CloudWatch**、**AWS X-Ray** 和 **Amazon OpenSearch Service** 等工具，构建一个统一的可观测性解决方案，帮助企业监控 AI 平台的用户行为、性能指标和业务结果。 ### 核心架构 该方案采用 **事件驱动架构**，通过 **Amazon EventBridge** 捕获用户交互事件（如查询、反馈、错误），并将事件路由到 **Amazon Kinesis Data Firehose** 进行流式处理，最终存储在 **Amazon S3** 中。**AWS Glue** 和 **Amazon Athena** 用于数据目录和即席查询，而 **Amazon QuickSight** 则提供可视化仪表板。 ### 关键指标 - **用户活动**：活跃用户数、会话时长、查询频率。 - **性能**：API 响应时间、错误率、吞吐量。 - **业务指标**：用户满意度评分、功能采用率、对话完成率。 ### 实施步骤 1. **日志和指标收集**：在 AI 平台中嵌入 SDK，将日志和指标发送至 CloudWatch。 2. **追踪请求链路**：使用 X-Ray 追踪每个用户请求的端到端路径，识别瓶颈。 3. **数据湖构建**：将事件数据存储到 S3，并使用 Glue 构建数据目录。 4. **可视化分析**：通过 QuickSight 创建实时仪表板，支持过滤和钻取。 ### 价值与挑战 该方案使企业能够**实时洞察平台健康状况**，快速定位问题并优化用户体验。但需要注意**数据隐私**和**成本控制**——大量日志存储可能产生较高费用，建议设置生命周期策略。 总的来说，对于大规模 AI 平台，集中式可观测性不再是可选项，而是必需品。
在当今快节奏的商业环境中，效率就是竞争力。Amazon Quick 的文档与可视化创建能力正在重新定义专业工作者的生产力标准。本文将深入探讨其工作原理、核心功能，以及不同岗位的专业人士如何利用它每周节省大量时间。 ## 从技术执行到战略判断 大多数专业角色都隐含着一个前提：相当一部分工作时间必须花在文档撰写、数据整理和图表制作上。这些任务虽然必要，却往往挤占了真正需要人类判断力的战略思考时间。Amazon Quick 正是瞄准这一痛点——让 AI 接管重复性、格式化的文档工作，从而将人力释放到更高价值的事务中。 ## 核心能力：不只是模板，更是智能编排 Amazon Quick 并非简单的文档模板工具。它通过理解用户意图，自动从数据源提取关键信息，并按照最佳视觉布局生成专业文档和可视化图表。其底层技术融合了自然语言处理、数据分析和渲染引擎，能够根据输入内容动态调整结构、配色和图表类型。 例如，当用户输入“生成上一季度的销售分析报告”时，Amazon Quick 会自动查询相关数据库，识别出销售额、增长率、区域分布等指标，并以最优的折线图、柱状图或饼图组合呈现，同时生成文字摘要和趋势洞察。整个过程无需手动拖拽或格式调整。 ## 跨角色应用场景 - **市场分析师**：每周的竞品动态报告从 4 小时缩短至 20 分钟。只需提供关键词和关注点，Amazon Quick 自动抓取公开数据并生成带图表的简报。 - **项目经理**：周报、项目状态更新等例行文档现在可以一键生成。系统从协作工具中提取任务进度、风险项和里程碑，并自动排版。 - **销售代表**：客户拜访后的会议纪要和跟进邮件，Amazon Quick 可根据谈话录音或笔记快速生成，并附带行动建议。 - **高管助理**：董事会议程、背景材料、决策摘要等复杂文档的初稿可在几分钟内完成，人工仅需审核和微调。 ## 行业意义与未来展望 Amazon Quick 的出现不是孤立的工具升级，而是 AI 从“辅助打字”向“辅助决策”演进的关键一步。当文档创作的时间成本大幅下降，企业可以更频繁地进行数据复盘、更及时地输出洞察，从而在竞争中占据信息优势。 当然，这并不意味着人类工作者的价值被削弱。相反，AI 承担了“执行层”的繁琐工作，让专业人士能更专注于定义问题、解读异常和做出判断。未来，随着模型对业务上下文的理解不断加深，Amazon Quick 这类工具可能从“文档生成器”进化为“工作流智能体”，主动建议下一步行动并跨应用执行。 ## 小结 Amazon Quick 的价值不仅在于节省时间，更在于重新分配注意力。在每周被解放出来的数小时里，专业人士可以选择：深入思考战略、创造新方案、或者——真正地休息一下。这或许正是 AI 赋能职场最理想的状态。
Amazon Nova Act 现已符合 HIPAA 合规要求，可在医疗保健和生命科学领域处理受保护的健康信息（ePHI）。该服务支持部署自主浏览器 AI 代理，自动化复杂的工作流程，如理赔处理和转诊协调。本文介绍了 Nova Act 的核心功能、HIPAA 合规对代理型 AI 的重要性以及如何快速上手。 ## Amazon Nova Act 是什么？ Amazon Nova Act 是一项 AWS 服务，用于构建和管理可靠的 AI 代理集群，以大规模自动化生产环境中的 UI 工作流。Nova Act 能够在浏览器中完成重复性 UI 任务，并在适当时升级给人工监督员。它通过 API 调用、远程 Model Control Protocol（MCP）或代理框架（如 Strand Agents）与外部工具集成。用户可以通过自然语言和 Python 代码的组合来定义工作流。 对于医疗组织而言，这意味着更少的行政负担、更快的理赔周转以及更一致的流程执行。 ## 为什么 HIPAA 合规对代理型 AI 至关重要？ 与仅生成文本的模型不同，代理型 AI 系统会与实时系统交互、访问数据并执行可能涉及受保护健康信息（PHI）的工作流。根据 AWS 的**责任共担模型**，AWS 负责底层基础设施的安全，而客户仍需负责配置控制措施以确保其部署符合 HIPAA 要求。 ## 医疗用例 借助 HIPAA 合规资格，您现在可以自动化以下任务： - **预约安排**：在提供者和支付方门户中自动安排预约。 - **保险验证**：自动验证患者保险资格。 - **事先授权**：自动处理事先授权流程。 - **理赔管理**：在支付方网站上检查理赔状态、提交上诉并跟踪报销。 - **转诊跟踪**：在提供者之间发送和跟踪转诊。 - **合规报告**：从多个系统收集数据以进行合规报告。 ## 如何开始？ 要开始使用 Amazon Nova Act，请访问 AWS 管理控制台，创建代理并定义工作流。AWS 提供了详细的文档和示例代码，帮助您快速集成。请注意，HIPAA 合规需要您与 AWS 签订商业伙伴协议（BAA），并确保您的部署配置满足安全要求。 ## 总结 Amazon Nova Act 的 HIPAA 合规资格为医疗行业利用代理型 AI 自动化关键工作流打开了大门。通过减少手动操作，组织可以提高效率、降低成本并减少错误。随着 AI 在医疗领域的应用不断深入，合规性将成为推动广泛采用的关键因素。
## 从规则引擎到智能代理：放射科工作流的范式转变 传统放射科工作列表系统依赖僵化的规则引擎，无法考虑关键上下文——如放射科医生的专长、当前工作量、疲劳程度以及病例复杂性。这导致了一个普遍问题：医生倾向于挑选简单、高价值的病例，而回避复杂研究，造成诊断延迟和成本增加。一项涵盖 62 家医院、分析 220 万项研究的数据显示，低效的病例分配导致紧急病例平均延迟 **17.7 分钟**，并在医院网络中造成 **210 万至 420 万美元** 的额外成本。 ### 传统系统的三大缺陷 1. **静态专业匹配**：仅根据预设规则分配病例，忽略医生连续处理复杂病例数小时后的疲劳状态。 2. **被动负载均衡**：仅响应当前队列深度，而非根据病例复杂度、预计解读时间或医生疲劳模式进行前瞻性调度。 3. **缺乏学习能力**：当规则产生次优分配时，系统不会自动改进，低效模式会持续重复，直到人工更新逻辑。 ### AI 代理如何破局 基于 **Amazon Bedrock AgentCore** 和 **Strands Agents SDK** 构建的 AI 代理系统，能够实时推理以下因素： - **团队专长**：动态匹配病例与最适合的亚专科医生。 - **工作负载与疲劳**：考虑医生连续工作时长和当前任务量，避免疲劳诊断。 - **病例复杂性**：根据影像类型、历史数据和紧急程度分配优先级。 这种 **Agentic AI** 方案将放射科工作流从简单的任务管理提升为真正的自主编排——在正确的时间，将正确的病例无缝分配给正确的亚专科医生，让医生专注于诊断质量而非排队。 ### 行业实践与前景 **Radiology Partners** 已将此视为关键工作流能力，并与 AWS 合作推进落地。未来，此类系统有望显著减少诊断延迟、优化资源利用率，并降低医疗成本。对于医疗 IT 决策者而言，从规则引擎向智能代理的迁移，将是提升放射科运营效率的下一个突破口。
随着 AWS 基础设施的扩展，运维工作流日益复杂。SRE 和 DevOps 工程师常常需要在 AWS 管理控制台、CLI 文档和多个服务仪表盘之间频繁切换，手动将业务问题翻译成正确的 API 语法，并在不同服务间串联调用。这种摩擦在事故排查、容量规划和安全审计等场景中尤为突出。 本篇文章介绍如何利用 **Amazon Bedrock AgentCore Runtime** 对 **Model Context Protocol (MCP)** 的支持，将 **Amazon Quick** 与 AWS 服务通过 **AWS API MCP Server** 连接起来，构建一个能够将自然语言直接转化为 AWS CLI 命令的对话式 AI 助手，从而减少关键时刻的工具切换。 ### 解决方案概览 借助 Amazon Bedrock AgentCore Runtime 和 MCP，用户可以用自然语言提问，例如“显示 us-east-1 区域所有正在运行的 EC2 实例”，系统即可直接调用 AWS API 返回结果，无需记忆复杂的 CLI 语法。所有请求都运行在现有 IAM 权限范围内，并通过 Amazon CloudWatch 保留完整的审计轨迹，便于合规。 架构流程如下： 1. **用户提问**：在 Amazon Quick 中以自然语言输入问题。 2. **身份认证**：Amazon Cognito 通过 OAuth 2.0 客户端凭证流程获取 JWT 令牌。 3. **智能代理**：Amazon Quick 的自定义代理解析用户意图。 4. **连接 AWS API MCP Server**：认证后的请求通过 Amazon Bedrock AgentCore Runtime 发送至 AWS API MCP Server，执行相应的 API 调用。 ### 实际应用场景 - **日常运维**：快速查询资源状态、日志或策略配置。 - **故障排查**：跨服务关联分析，无需手动拼接数据。 - **容量规划**：自动汇总多个服务的指标。 - **安全审计**：标准化 API 调用序列，提升可重复性。 ### 关键优势 - **降低认知负荷**：用自然语言代替复杂命令，减少上下文切换。 - **安全可控**：严格遵循 IAM 权限，审计日志完整。 - **可复用集成**：通过统一的 MCP 标准，避免为每个工作流重复构建连接逻辑。 这一方案为 AWS 运维团队提供了一种更高效、更智能的工作方式，让 AI 真正成为运维流程中的得力助手。
随着 SaaS 提供商加速将 AI 智能体（Agent）融入产品，多租户架构的复杂性成为从原型到生产的关键瓶颈。近日，AWS 官方博客发布系列文章，深入探讨如何利用 **Amazon Bedrock AgentCore** 构建安全、高效的多租户智能体应用。本文为系列第一篇，聚焦核心设计考量与隔离模式选择。 ## 多租户智能体的三大挑战 与传统 SaaS 应用不同，多租户智能体系统除了要解决安全、治理和响应准确性等常规问题，还必须应对**租户隔离**、**租户身份**、**可观测性**、**数据隔离**、**成本归属**以及**噪声邻居（noisy neighbor）** 缓解等独特挑战。这些因素直接决定了系统能否在生产环境中稳定运行。 Amazon Bedrock AgentCore 是一项托管的无服务器服务，专门用于构建、部署和运营智能体应用。它内置了身份管理、记忆、可观测性和评估等能力，旨在简化多租户架构的搭建。 ## 核心设计考量：三大隔离模式 文章提出了多租户智能体架构中需要权衡的关键组件，并围绕三种隔离模式展开：**Silo（竖井）**、**Pool（池化）** 和 **Bridge（桥接）**。 - **Silo 模式**：为每个租户部署独立的运行时环境，提供最强的噪声邻居防护和合规审计能力，但成本较高。 - **Pool 模式**：所有租户共享同一容器镜像和进程池，降低基础设施开销，但要求严格的进程内租户上下文传递。 - **Bridge 模式**：介于两者之间，通过部分共享实现成本与隔离的平衡。 ## Agent 运行时部署：专属 vs 共享 一个关键决策点是 Agent 运行时的部署方式。**专属运行时**为每个租户实例化独立的执行环境，拥有自己的容器镜像、进程空间和生命周期；**共享运行时**则将所有租户的 Agent 置于同一进程池中。Amazon Bedrock AgentCore 通过 **会话管理** 机制解决了这一矛盾——它允许在共享基础设施上实现逻辑隔离，同时保持高性能和低延迟。 ## 租户身份与数据隔离 在多租户智能体中，**租户身份**必须贯穿整个请求链路。AgentCore 支持将租户 ID 嵌入每个请求，确保下游服务（如知识库、API 调用）能够正确区分数据归属。**数据隔离**则通过分层存储策略实现：敏感数据按租户加密存储，共享数据通过访问控制列表（ACL）限制。 ## 可观测性与成本归属 **可观测性**是多租户系统的难点。AgentCore 集成了 AWS CloudWatch，能够按租户维度记录调用次数、Token 消耗、错误率等指标，帮助运营商快速定位问题。**成本归属**则通过标签（Tagging）机制实现，每个租户的推理和存储消耗都能精确追踪，便于计费分摊。 ## 总结与展望 构建生产级多租户智能体应用，必须从设计之初就考虑隔离、身份和可观测性。Amazon Bedrock AgentCore 通过托管运行时、内置会话管理和细粒度监控，大幅降低了实现难度。本文为系列开篇，后续文章将进一步探讨具体实现模式与最佳实践。
在处理数百万字符的文档时，传统大语言模型（LLM）的上下文窗口往往成为瓶颈。即使是最长的上下文窗口，也可能因输入过长而拒绝请求，或产生基于不完整信息的回答。本文介绍了如何利用 **Amazon Bedrock AgentCore Code Interpreter** 和 **Strands Agents SDK** 实现**递归语言模型（RLM）**，从而突破这一限制。 ## 为什么上下文窗口不够用？ 以金融分析为例，比较一家公司两年年报中的指标。每份报告 300–500 页，加上分析师报告、SEC 文件等，总字符数可达数百万。直接输入模型时，要么超出上下文窗口限制而失败，要么虽然“塞入”但模型难以关注中间部分的信息——这就是著名的 **“lost in the middle”** 问题。上下文窗口大小是一个硬限制，单纯通过提示工程无法解决。我们需要一种将文档大小与模型上下文窗口解耦的方法。 ## RLM：将上下文视为环境 RLM 由 Zhang 等人在 arXiv:2512.24601 中提出，它重新定义了问题：不将整个文档喂给模型，而是将输入视为一个**外部环境**，模型通过编程方式与之交互。模型只接收查询和环境描述，然后编写代码来搜索、切片、迭代分析文档。当需要理解某个特定部分的语义时，模型会委托给**子 LLM 调用**，并将结果保存在工作记忆中。 ## 实现方式 通过 **Bedrock AgentCore Code Interpreter**，你可以： - 处理任意长度的文档，无上下文窗口上限。 - 将 Code Interpreter 作为**持久工作记忆**，进行迭代式文档分析。 - 在沙盒化 Python 环境中编排子 LLM 调用，分析特定文档片段。 具体流程如图 1 所示：根 LLM 生成代码探索文档环境，将语义分析委托给子 LLM，并将结果累积在工作记忆中，然后优化下一步操作。 ## 实际价值 这种递归方法不仅突破了上下文窗口的硬限制，还避免了“lost in the middle”问题。对于金融、法律、学术研究等需要处理超长文档的领域，RLM 提供了一种可扩展的解决方案。Amazon Bedrock AgentCore 和 Strands Agents SDK 的组合，让开发者能够快速构建这类应用，而无需从头实现复杂的工作流。 ## 小结 上下文窗口不再应该是文档分析的瓶颈。通过递归语言模型和 Amazon Bedrock AgentCore，你可以将文档处理能力提升到新的水平。无论是百万字符的报告还是多文件集合，RLM 都能让你在不丢失信息的前提下进行深入分析。
## 从数据孤岛到实时洞察：OPLOG 的 AI 代理实践 在电商与物流行业，数据碎片化是普遍挑战。土耳其科技驱动型履约公司 OPLOG 每月处理数百万件商品，服务横跨土耳其、英国和德国的多个品牌与全球市场。然而，其业务数据分散在 Hubspot CRM、通信系统、Microsoft Teams 以及 Databricks 数据仓库中，导致传统商业智能（BI）系统难以提供及时、全面的洞察。 为破解这一困局，OPLOG 基于 **Amazon Bedrock AgentCore** 构建了一套由 AI 代理驱动的生产级 BI 系统。该系统利用 **Strands Agents SDK** 开发了三个专用 AI 代理，分别负责**销售管道管理**、**数据质量管控**和**潜在客户调研**，并集成了 **Anthropic 的 Claude Sonnet** 模型与 **Amazon Bedrock Knowledge Bases** 实现检索增强生成（RAG）。 ### 核心架构与实现 三个 AI 代理分工明确： - **销售管道代理**：自动从 Hubspot CRM 抓取销售阶段数据，结合客户沟通记录与团队聊天上下文，自动更新交易状态、识别瓶颈，并生成每周预测报告。 - **数据质量代理**：持续监控 CRM 中的字段完整性、重复记录和异常值，自动触发数据清洗工作流，将数据完整度从 70% 提升至 91%。 - **调研代理**：针对潜在客户，自动从公开数据源和内部知识库中提取公司背景、行业趋势和竞品信息，生成结构化的客户画像，将人工调研时间缩短 98%。 所有代理通过 **Amazon Bedrock AgentCore** 统一管理，利用 Claude Sonnet 的推理能力进行任务分解与决策，并通过 **RAG** 机制从 Amazon Bedrock Knowledge Bases 中检索最新的业务文档和交易记录，确保输出基于实时数据。 ### 业务成效：数据驱动决策的闭环 OPLOG 的实践证明了 AI 代理在 BI 场景中的巨大价值： - **销售周期缩短 35%**：代理实时更新管道状态，销售团队能立即跟进高价值机会，避免因信息滞后导致的丢单。 - **CRM 数据完整性提升 91%**：自动化数据校验与补全大幅减少了人工录入错误，为后续分析提供可靠基础。 - **人工调研时间减少 98%**：调研代理将原本需要数小时的客户背景调查压缩至几分钟，让销售团队专注于高价值互动。 ### 行业启示：AI 代理重塑 BI 范式 OPLOG 的案例并非孤例。随着企业数据量激增，传统 BI 工具（如报表与仪表盘）已难以满足实时、交互式的决策需求。AI 代理通过**自主感知、推理与行动**，能够主动发现数据异常、触发工作流并生成可执行的洞察，将 BI 从“被动查询”升级为“主动服务”。 结合 **Amazon Bedrock AgentCore** 的托管能力，企业无需自建复杂的代理编排系统，即可快速集成大语言模型、知识库和业务 API。对于面临类似数据碎片化问题的 B2B 组织而言，这一架构提供了一条低门槛、高回报的落地路径。 > 提醒：本文基于 AWS 官方博客内容整理，所有数据均来自 OPLOG 的实际运营结果。
## 当招聘变成“体力活”：AI 如何破局？ 一份针对 748 名 HR 领导者的调查显示，招聘人员平均在每个职位空缺上花费 **17.7 小时** 处理行政事务——相当于两个多工作日。另一项 2024 年的 SmartRecruiters 调查发现，**45% 的人才招聘负责人** 超过一半的工作时间花在可自动化的任务上。这种行政负担导致简历筛选流于表面，大量合格候选人被忽略，而匹配结果往往取决于简历格式和关键词密度，而非真实能力。 ## 架构解析：Serverless + 大模型 + 安全护栏 AWS 近期发布了一篇技术博客，详细展示了如何利用 **Amazon Bedrock** 构建一套 AI 驱动的招聘助手。这套参考架构（非生产就绪方案）整合了多个 AWS 服务，形成一个协同工作的无服务器系统： - **Amazon Bedrock Converse API + Amazon Nova Pro**：负责核心的 AI 推理，包括简历解析、候选人评分、技能评估和面试题生成。 - **AWS Lambda**：处理业务逻辑，串联各个模块。 - **Amazon API Gateway**：提供 API 路由。 - **Amazon DynamoDB & Amazon S3**：分别存储结构化数据（如评分结果）和原始简历文件。 - **Amazon Bedrock Guardrails**：提供 **PII 匿名化、提示词攻击检测和偏见内容过滤**，确保 AI 应用负责任地运行。 前端方面，使用 **AWS Amplify** 托管 Web 应用，**Amazon Cognito** 处理用户认证与 JWT 令牌管理。 ## 核心能力：从简历到面试题的全链路智能化 1. **简历解析与多维评分**：AI 不仅提取基本信息，还能基于职位要求计算 **多维度兼容性分数**，避免“关键词堆砌”式的误判。 2. **个性化面试题生成**：根据候选人的背景和岗位需求，动态生成有针对性的面试问题，帮助面试官深入考察真实能力。 3. **数据驱动的洞察**：所有评估结果以结构化数据存储，方便后续分析和决策。 ## 行业背景与思考 当前，AI 在招聘领域的应用已从简单的关键词匹配走向 **深度语义理解与推理**。Amazon Bedrock 提供的托管大模型服务，让企业无需自建基础设施即可调用前沿模型，同时通过 Guardrails 解决合规与伦理问题——这对处理敏感个人数据的 HR 场景尤为重要。 不过，博客也明确指出，这套架构仅用于 **学习目的**，并非生产就绪方案。实际落地时，企业需要根据自身需求调整，例如增加更严格的隐私保护措施、优化成本控制，或与现有 ATS（申请人追踪系统）集成。 ## 小结 AI 招聘助手并非要取代人类面试官，而是将 HR 从繁琐的行政工作中解放出来，让他们专注于更有价值的决策——比如判断候选人的文化契合度、软技能和发展潜力。随着 Amazon Bedrock 等平台降低了大模型的使用门槛，这类智能化工具将加速进入中小企业，改变整个招聘行业的效率格局。
## 概述 传统上，业务分析师在调整仪表板以响应变化的需求时，往往需要等待数天。典型的流程涉及向 IT 团队提交修改请求，由 IT 人员解读需求、查阅 API 文档、理解表结构并部署变更。虽然这种方式能保证适当的监督和质量控制，但在需要快速更新仪表板时，可能导致数天的周转时间。 本文介绍的方案结合了 **Amazon Bedrock AgentCore**、**Strands Agents** 和 **Amazon QuickSight** 的强大功能，构建了一个安全、可扩展且智能的系统，用于创建和运行 AI 代理，同时将数据转化为可执行的业务洞察。 ## 解决方案架构 该方案采用基于 Amazon Bedrock AgentCore 和 Strands 框架的多智能体架构。Amazon Bedrock AgentCore 是一个智能体平台，用于安全地大规模构建、部署和运行高效代理，无需管理基础设施。Strands Agents 是一个代码优先的框架，用于构建与 AWS 服务集成的代理。Amazon QuickSight 则提供 AI 驱动的 BI 能力，将分散的数据转化为战略洞察。 架构由三个专门代理协作组成： - **查找仪表板代理**：执行发现操作，包括搜索仪表板、检索仪表板和数据集中的列元数据。 - **修改仪表板代理**：执行配置变更，如验证列、更新表格视觉效果以及创建新的仪表板版本。 - **编排代理**：根据意图分类，将用户请求路由到相应的专门代理。 ## 工作流程 编排代理作为用户交互的入口。当用户提交自然语言查询（例如“将 lastname 添加到测试仪表板”）时，Amazon Nova 将请求分类为对话型或操作型。对话型查询直接利用 Nova 的大语言模型能力进行响应；操作型请求则通过 Strands 框架路由到相应的专门代理进行处理。 ## 行业背景与价值 在 AI 行业，将自然语言处理与智能代理结合，正在重新定义企业与数据交互的方式。这一方案不仅缩短了仪表板修改的周期，还降低了非技术用户的使用门槛。业务分析师无需掌握技术细节，即可通过自然语言指令完成复杂的仪表板操作，从而加速决策过程。 该方案体现了 **Agentic AI** 在商业智能领域的落地潜力：通过多代理协作，将意图识别、任务分解与执行自动化融为一体。Amazon Bedrock AgentCore 提供的安全性和动态扩展能力，确保了生产级部署的可靠性。 ## 关键优势 - **效率提升**：将仪表板修改时间从天级缩短至分钟级。 - **自然语言交互**：用户无需学习特定命令或 API。 - **安全可控**：代理访问权限和数据操作受到严格管理。 - **可扩展性**：基于微服务架构，易于添加新的代理或功能。 ## 总结 通过 Amazon Bedrock AgentCore、Strands Agents 和 Amazon QuickSight 的组合，企业可以构建一个智能的仪表板自动化系统，让数据分析师和业务用户都能以更自然、更高效的方式获取洞察。这不仅是技术上的进步，更是企业数据文化向自助式、即时响应方向转型的重要一步。
亚马逊云科技今日宣布，Amazon SageMaker AI 实时推理端点正式支持 OpenAI 兼容 API。这意味着使用 OpenAI SDK、LangChain 或 Strands Agents 等框架的开发者，只需修改端点 URL，即可直接调用 SageMaker AI 上托管的模型，无需编写自定义客户端、SigV4 签名包装器或重写代码。 ## 核心变化：一条 /openai/v1 路径打通壁垒 SageMaker AI 端点现在暴露一个 **/openai/v1** 路径，原生接受 Chat Completions 格式的请求，并返回包含流式响应在内的标准回复。该功能对所有使用标准 SageMaker AI API 创建的端点和推理组件自动生效。SageMaker AI 会根据 URL 中的端点名称进行路由，因此任何 OpenAI 兼容的客户端都能即插即用。此外，用户现在可以为端点创建**限时 bearer 令牌**，直接用于 OpenAI 客户端，进一步简化了认证流程。 ## 三大典型应用场景 ### 1. 自有基础设施上的智能体工作流 如果你使用 Strands Agents 或 LangChain 构建多步骤 AI 智能体，现在可以将这些工作流完全运行在自己的 SageMaker AI 端点上。智能体调用模型时沿用同一套 OpenAI 兼容接口，但推理实际运行在用户账户内的专用 GPU 实例上，兼顾性能与数据安全。 ### 2. 多模型统一托管，单一接口调用 如果需要运行多个模型——例如 Llama 处理通用任务、微调版 Mistral 处理领域问题、小模型做分类——可以将它们全部托管在单个 SageMaker AI 端点上，通过推理组件分配独立资源。每个模型都可通过同一个 OpenAI SDK 调用，应用代码中无需维护多套 API 客户端或路由逻辑。 ### 3. 微调模型零代码改造上线 针对特定场景微调的开源模型，可直接部署到 SageMaker AI 并通过 OpenAI 兼容接口调用。应用程序只需修改端点 URL，无需任何代码改动，即可享受微调模型的定制能力。 ## 行业视角：降低云上推理的迁移成本 长期以来，AWS 用户若想将 OpenAI 生态中开发的应用迁移到自托管模型，往往需要额外开发 SigV4 签名层或适配自定义 SDK。此次更新直接消除了这一障碍，使得 **SageMaker AI 成为 OpenAI 生态系统的“一等公民”**。对于已投资 Agent 框架和 LLM 网关的企业，这意味着可以在不改变架构的前提下，灵活切换底层推理供应商，或将部分工作负载迁入自有账户以控制成本与延迟。 Caffeine.AI 的 AI/ML 工程师 Giorgio Piatti 在公告中表示：“我们运行 AI 编码智能体，通过一个兼容 OpenAI 聊天补全协议的 LLM 网关使用多个提供商。bearer 令牌功能让我们能将 SageMaker 作为即插即用的 OpenAI 兼容推理端点加入，无需自定义 SigV4 签名，原生适配我们的网关、Vercel AI SDK 和标准 OpenAI 客户端。” ## 快速上手 AWS 官方提供了配套 Jupyter Notebook（[GitHub 仓库](https://github.com/aws-samples/)），演示从部署到调用的完整流程。用户可以通过标准 SageMaker API 创建端点，获取 bearer 令牌后，在 OpenAI 客户端中将 `base_url` 设置为 `https://<endpoint-url>/openai/v1` 即可开始使用。 此次更新标志着 AWS 在**模型服务兼容性**上的重要一步——不强迫用户锁定在特定 SDK，而是主动适配业界最广泛使用的接口标准。对于正在构建多模型、多提供商 AI 系统的团队来说，这无疑降低了架构复杂度与运维成本。
在构建视觉购物、图像或文档理解、图表分析等应用时，如何验证模型输出是否真正基于源图像是一大挑战。纯文本评估器无法判断描述是否忠实反映图像、提取的发票金额是否与文档一致，或屏幕摘要是否虚构了不存在的按钮。Gartner 预测，到 2030 年，80% 的企业软件将具备多模态能力，而 2024 年这一比例还不足 10%。缺乏自动化多模态评估，企业只能在昂贵的人工审核和不可靠的纯文本代理之间左右为难。 如今，AWS 在 Strands Evals SDK 中推出了四种新的多模态大语言模型（MLLM）作为裁判的评估器，专门用于图像到文本任务：**Overall Quality**（整体质量）、**Correctness**（正确性）、**Faithfulness**（忠实性）和 **Instruction Following**（指令遵循）。每个评估器都会根据源图像对模型输出进行评分。评估器将图像直接发送给多模态裁判模型，同时附上查询、响应以及可选的参考答案。裁判模型返回基于图像的分数以及推理过程字符串，便于调试。 这些评估器可以无缝替换现有 Strands Evals 工作流中的纯文本评估器，并集成到持续集成（CI）中，自动捕捉视觉幻觉、事实错误和指令违规。本文将介绍如何设置这四种多模态评估器并运行图像到文本任务；如何在有参考和无参考评估之间切换；如何为特定领域标准编写自定义多模态评估标准；如何在 Amazon Bedrock 上选择平衡准确性、成本和延迟的裁判模型；以及如何应用提示设计选择来提升评估器与人类判断的一致性。 ## 设置与使用 首先，确保已安装 Python 3.10 或更高版本。通过 Strands Evals SDK 可以快速调用这些评估器。示例代码如下： ```python from strands_evals import MultimodalEvaluator evaluator = MultimodalEvaluator( judge_model="anthropic.claude-3-sonnet-20240229-v1:0", evaluator_type="faithfulness" ) result = evaluator.evaluate( image_path="invoice.jpg", query="提取发票总金额", response="总金额为 $123.45", reference="$123.45" # 可选 ) print(result.score, result.reasoning) ``` ## 自定义多模态评估标准 若需针对特定领域制定标准，可编写自定义评估标准。例如，在医疗影像报告中，可以定义“报告必须描述病变位置和大小”等规则，评估器将据此打分。 ## 选择裁判模型 Amazon Bedrock 提供了多种多模态模型，如 Claude 3 Sonnet、Claude 3 Haiku 等。**Claude 3 Sonnet** 在准确性和延迟之间取得了良好平衡，适合大多数场景；而 **Claude 3 Haiku** 则更注重成本效益。用户可根据任务需求灵活选择。 ## 提示设计技巧 实验表明，在提示中加入“逐步推理”指令（如“请先描述图像内容，再评估回答”）可以显著提升评估器与人类判断的一致性。此外，明确要求模型输出评分理由，有助于调试和审计。 通过引入多模态评估器，开发者可以更可靠地自动化评估图像到文本任务的输出质量，减少人工干预，加速 AI 应用的落地。
实时语音转写是语音助手、直播字幕、联络中心分析和无障碍工具等应用的核心能力。传统请求-响应推理需要等待完整音频上传后才能开始转写，这引入的延迟破坏了实时体验。从 2025 年 11 月起，Amazon SageMaker AI 支持双向流式推理，允许客户端与模型容器之间持续双向传输数据。同时，vLLM 通过其 Realtime API（基于 WebSocket 的双向流）支持实时音频转写。本文将两者结合，展示如何使用 SageMaker AI 的 vLLM 容器部署 Mistral AI 的 Voxtral-Mini-4B-Realtime-2602 模型，构建一个完全托管的实时语音转文本服务。 ## 关键特性 构建生产级语音 AI 应用需要多个基础设施组件紧密配合，并满足严格的延迟要求。SageMaker AI 和 vLLM 各自解决了不同部分的问题： - **实时语音模型与高效 GPU 服务**：核心是能够增量处理音频的 ASR 模型，vLLM 通过其 Realtime API（原生 WebSocket 端点 `/v1/realtime`）提供支持，并采用分段 CUDA 图执行减少 GPU 内核启动开销，从而降低流式转写中的每 token 延迟。 - **双向流式推理**：SageMaker AI 支持双向流，客户端可同时发送音频并接收转写结果，无需等待完整音频。 - **完全托管与可扩展**：SageMaker AI 负责基础设施管理，包括自动缩放、监控和安全性。 ## 部署步骤 1. **准备模型**：从 Hugging Face 获取 Voxtral-Mini-4B-Realtime-2602 模型，并将其打包为适用于 vLLM 的格式。 2. **创建 SageMaker 端点**：使用 SageMaker SDK 创建一个启用了双向流的端点，指定 vLLM 容器镜像。 3. **配置 WebSocket 客户端**：客户端通过 WebSocket 连接到端点，持续发送音频数据并接收实时转写结果。 完整示例代码可在 [GitHub 仓库](https://github.com/aws-samples/amazon-sagemaker-ai-vllm-realtime) 中找到。 ## 性能与优势 相比传统方法，该方案显著降低了端到端延迟。例如，在语音助手场景中，用户说话后几乎立即看到转写文本，交互更加自然。此外，SageMaker AI 的托管特性减少了运维负担，而 vLLM 的开源特性允许用户灵活调整模型配置、量化和编译设置。 ## 应用场景 - **语音助手**：实时理解用户指令并快速响应。 - **直播字幕**：为直播视频生成实时字幕。 - **联络中心分析**：实时转写客户通话，进行情感分析或合规检查。 - **无障碍工具**：帮助听障人士实时获取语音信息。 这一组合为开发者提供了构建实时语音应用的高性能、低成本方案，推动了 AI 语音技术的普及。