## 九月更新速览：AWS 为 AI 构建者铺路 AWS 在九月围绕 **Amazon Bedrock**、**Amazon Bedrock AgentCore** 和 **Strands** 发布了一系列更新，核心思路是让构建者在模型、运行时和工具链每一层都拥有更多选择。随着 AI 模型能力提升和可选范围扩大，行业关注点正从单纯的模型性能转向成本效益、系统集成与治理能力。 ### 模型选择更自由：OpenAI 模型登陆 Bedrock 最受关注的更新是 **Amazon Bedrock Managed Agents**（由 OpenAI 驱动）进入公开预览。这意味着构建者可以在 AWS 环境内使用 OpenAI 模型构建生产级 AI 代理，同时保持企业级安全：数据留在 AWS，复用现有 **IAM 权限**，并通过 **AWS CloudTrail** 实现完整审计。此外，持久会话和内置人工审批流程有助于降低开发开销和风险。 ### 代理运行更快、更可衡量 **AgentCore 运行时**迎来重要升级。新版本优化了内存管理，显著降低了无服务器代理的**冷启动延迟**，代理启动更快，基础设施开销更小。AWS 强调，这让用户只为实际使用量付费，而非为闲置资源买单。 与此同时，AgentCore 还增强了内置评估能力，让构建者能够更高效地衡量代理表现——在代理进入生产环境、处理长周期任务和敏感操作时，这种可观测性变得尤为关键。 ### 知识库同步自动化，企业连接器原生集成 九月更新还带来了**自动化知识库同步**与**原生企业连接器**。这解决了 AI 应用与当前业务信息脱节的问题：代理需要基于最新企业知识进行推理，而手动同步既慢又易错。新功能让数据管道更直接、更可靠，帮助企业将 AI 应用与实时业务信息连接起来。 ### 行业背景：从模型竞赛到系统工程 AWS 在公告中指出，行业对话正在转变。模型性能不再是唯一问题，客户开始权衡特定用例的成本与收益，尤其是在将工作委托给生产环境中的代理时。AI 代理已进入需要推理企业知识、执行长周期任务并在安全、准确和治理至关重要的系统中行动的阶段。 因此，焦点正从模型本身转向围绕模型的更广泛系统：代理能访问的上下文、能执行的操作，以及企业数据如何被治理和保护。九月的更新正是为了强化这些基础——扩大模型选择、让代理操作更高效可衡量，并创造更直接的方式将 AI 应用与最新业务信息连接。 对于正在构建企业 AI 的团队而言，这些更新传递了一个清晰信号：AWS 正在押注**开放选择**和**系统化治理**，而非单一模型绑定。
## 从演示到生产：Postman Agent Mode 的规模化挑战 构建一个能在演示中工作的 AI 代理，与为 **4000 万开发者** 运行一个代理，是完全不同的工程问题。Postman 在推出 **Agent Mode** 时，原本以为模型质量和提示设计会是最大的难题，但真正的挑战来自于将一个代理集成到拥有 **11 年历史**、界面驱动假设根深蒂固的成熟产品中。 ### 为什么需要 Agent Mode？ Postman 已演进了 11 年，开发者习惯了通过展开侧边栏、检查标签页、打开请求来定位信息。而代理需要直接对数据进行推理，而不是导航屏幕。Agent Mode 提供了一种 AI 原生的工作方式，覆盖 **API 测试、文档、发现和实现**。 ### 架构模式：控制工具蔓延与上下文瓶颈 Postman 和 AWS 分享了在让成熟产品对 AI 代理可读的过程中浮现的架构模式： - **控制工具蔓延**：避免代理可用工具数量爆炸，保持工具集精简且聚焦。 - **暴露基于 schema 的读取**：让代理通过结构化 schema 直接读取数据，而非模拟界面操作。 - **将上下文视为主要瓶颈**：不是能力不足，而是上下文窗口有限，需要精心管理。 这些模式帮助团队将生产级代理推向原型之外。 ### 在 Amazon Bedrock 上运行 Agent Mode 运行在 **Amazon Bedrock** 上，该服务提供对基础模型的托管访问。Postman 的全球开发者社区产生 **可变、延迟敏感且带有突发流量** 的需求。借助 Amazon Bedrock，Postman 无需运营自己的模型服务基础设施，同时保留了模型选择的灵活性，并能控制吞吐量、地理处理和成本。 具体而言，Agent Mode 利用了 Amazon Bedrock 的以下能力： - **模型灵活性**：可根据任务选择不同基础模型。 - **地理范围的跨区域推理**：满足数据驻留要求。 - **模型相关的零数据保留**：确保数据隐私。 - **多级提示缓存**：优化延迟和成本。 ### 对生产级 AI 代理的启示 Postman 的经验表明，将代理集成到成熟产品中，需要重新审视产品的 API、用户体验和知识分布。团队应关注上下文管理、工具设计和 schema 暴露，而非仅仅追求模型能力。这些经验可以帮助更多团队将生产代理从原型推向实际应用。
## 当AI智能体学会“按次买单” AI智能体（Agent）正在从演示走向生产环境，但一个基础问题始终没有优雅的答案：**当智能体需要调用外部服务时，它怎么付钱？** 传统方案要么依赖预充值账户，要么由开发者手动管理API密钥和账单。这两种方式都难以支撑“智能体自主决策、按需调用”的愿景——你总不能给每个智能体发一张信用卡。 AWS在**Amazon Bedrock AgentCore**中给出的答案是：**payments（支付）能力**。它让智能体能够按需为服务付费，而**消费限额由基础设施层强制执行**，不依赖智能体自身的“自律”。 ### BlockRun与Incarna的实践 根据AWS官方分享的案例，**Incarna**的智能体通过**x402协议**向**BlockRun**购买模型推理服务，**一次请求结算一次**。 x402是一个基于HTTP的支付协议，旨在让机器之间的微支付像发起一次网页请求一样自然。听起来简单，但真正落地并不轻松。 Incarna的工程团队原本预计，为智能体添加x402支付支持需要**数月**的开发工作——涉及支付流程编排、限额控制、异常处理、安全审计等一系列环节。而借助Amazon Bedrock AgentCore payments，这一周期被压缩到了**数天**。 ### 为什么这件事值得关注 **第一，支付正在成为智能体基础设施的一部分。** 过去我们讨论智能体，焦点在推理能力、工具调用、记忆管理。但当智能体开始自主采购算力、数据或API时，支付能力就不再是外围功能，而是核心基础设施。 **第二，基础设施级限额比智能体自律更可靠。** AgentCore payments将消费限额放在平台层执行，这意味着即使智能体逻辑出现偏差或遭遇提示注入攻击，也不会产生失控账单。对于企业级部署而言，这是能否上生产的关键门槛。 **第三，微支付可能重塑AI服务的经济模型。** 如果每次推理都能被独立计价和结算，那么模型提供方、工具开发者、智能体运营方之间的价值分配将变得更加细粒度。BlockRun以“按请求”方式提供推理服务，正是这种趋势的早期信号。 ### 仍需观察的问题 目前这一模式仍处于早期。x402协议的实际采用范围、跨服务商的互操作性、以及在高并发场景下的结算性能，都还有待更多生产案例验证。AWS并未披露具体的交易规模或延迟数据。 但方向已经清晰：**智能体要真正自主，就得先学会自己付账。** 而支付基础设施的成熟度，可能成为下一阶段Agent竞争的分水岭。
## 多团队共享 GPU 集群，为什么这么难？ 生成式 AI 的算力需求正在把 GPU 集群变成企业里最昂贵的共享资产。一个典型场景是：数据科学团队要训练大语言模型，计算机视觉组跑推理任务，研究团队则在试验新架构——三拨人都盯着同一批 GPU。如果没有一套好的多租户架构，结果往往是资源被少数人抢占、团队之间互相干扰、账单无法归因，管理员被基础运维拖住，创新速度反而变慢。 AWS 给出的答案是一套基于 **Amazon SageMaker HyperPod** 的参考架构。HyperPod 本身是面向生成式 AI 的托管集群服务，由 **Amazon EKS** 或 Slurm 编排，自动处理节点健康监控、故障恢复和集群生命周期管理。而这次的重点，是如何在它之上叠加一层完整的多团队治理体系。 ## 架构的五个关键组件 这套参考架构的设计思路可以概括为“身份—隔离—公平—计费”的链路： - **统一身份认证**：使用 **AWS IAM Identity Center** 做集中式认证，团队成员用同一套身份体系接入，避免为每个团队单独维护账号。 - **按团队划分的 SageMaker AI Domain**：每个团队拥有独立的 Domain，获得定制化的用户界面与体验，彼此互不干扰。 - **Kubernetes 命名空间隔离**：工作负载在集群内按命名空间隔离，这是多租户安全边界的基础。 - **HyperPod Task Governance 保障公平**：在共享集群上做资源配额与调度治理，防止某个团队独占 GPU。 - **命名空间级成本分摊**：把 GPU 开销按命名空间归集，实现按团队的可视化与内部计费（chargeback）。 架构整体呈现为从左到右的分层流：用户身份 → 授权控制 → 集群内隔离的工作负载命名空间。示例中，Team A 和 Team B 共享同一个 HyperPod EKS 集群，各自运行在独立命名空间中。 ## 对企业的实际意义 这套方案解决的是 AI 基础设施规模化过程中最现实的矛盾：**算力集中采购的成本优势，与团队自治、安全隔离之间的张力**。 对平台团队而言，命名空间级隔离加上 Task Governance，意味着不必再靠人工审批来分配 GPU；对财务和管理层而言，成本分摊让“谁用得多谁付得多”变得可执行，而不是一笔糊涂账；对一线研究者和工程师而言，独立 Domain 保留了操作独立性，不会因为共享集群而牺牲日常体验。 值得注意的是，这套架构依赖 EKS 编排路径，因此更适合已经或计划采用 Kubernetes 生态的组织。对于纯 Slurm 用户，隔离与治理的实现方式会有所不同。 ## 小结 HyperPod 的价值不只在“把 GPU 管起来”，更在于把多团队共享这件事变成可治理、可计量、可扩展的工程实践。当 GPU 预算持续攀升，能否公平且透明地共享集群，正在成为衡量 AI 平台成熟度的一项关键指标。
## 快讯：Anthropic 最轻量模型再升级 **Claude Haiku 5.5** 现已在 **Amazon Bedrock** 和 **Claude Platform on AWS** 上正式可用。据 Anthropic 介绍，这是 Claude 5.5 家族中**速度最快、效率最高**的模型，专为**子代理（subagents）** 和高频、成本敏感型任务设计，大多数任务成本比 **Claude Haiku 4.5 降低约 75%**。 ## 核心亮点 - **首个支持 effort controls 的 Haiku 模型**：可按任务调节成本与智能的平衡，而不是整个工作负载使用单一设置。 - **编码能力增强**：可作为子代理进行请求路由、代码审查和长文档分类。 - **知识工作**：从中小型文档提取关键信息、初步扫描、知识库快速问答。 - **交互应用**：响应速度足以支撑简单对话的快速回答。 - **传统 NLP 任务**：分类、摘要、文本生成，满足生产级规模与成本要求。 - **代理编码与多步工具使用**：支持高分辨率图像，可作为重复性浏览器和桌面任务的计算机使用子代理。 ## 在 AWS 上使用 通过 **Amazon Bedrock**，你可以在 AWS 基础设施内使用 Haiku 5.5，享受区域数据驻留，并与现有 AWS 控制集成： - **AWS IAM** 管理访问权限 - **AWS CloudTrail** 审计 - **Amazon CloudWatch** 监控 - **Amazon Bedrock Guardrails** 内容护栏 - 用量计入 AWS 账单 **Claude Platform on AWS** 则通过 AWS 管理控制台提供 Anthropic 原生平台体验，使用相同的 API、功能和控制台，统一 AWS 计费和身份验证。 ## 适用场景 Haiku 5.5 适合在开发工作流中快速迭代 UI/UX 变更、处理小规模特定代码库，以及需要大规模、低成本、快速响应的代理任务。对于追求极致性价比、又不想牺牲 Claude 系列智能水平的团队，这是一个值得评估的选项。 > 本文基于 AWS 官方发布信息整理，具体性能数据以 Anthropic 和 AWS 官方文档为准。
企业正在用 RAG 从 SharePoint、Google Drive、Confluence 等知识源中挖掘洞察，但这些源里往往藏着受复杂权限结构保护的敏感信息。让 AI 生成的答案严格遵守这些权限，是企业 AI 落地中最棘手的难题之一。 **Amazon Quick** 与 **Amazon Bedrock Knowledge Bases** 给出的思路是：不再把权限复制到 AI 系统里，而是在查询时直接向权威源实时验证用户的访问权限。 ## 问题出在哪 设想这样一个场景：SharePoint 站点所有者为企业创建了一个知识库，多个部门的成员通过 AI 助手从中获取答案。关键要求是——每个成员只能拿到自己有权访问的文档所生成的洞察。这是一个普遍的企业挑战：既要让 AI 洞察普惠全员，又不能破坏现有的安全态势。一份未经授权的文档出现在 AI 回答中，就可能泄露机密战略文件、未公开的财务数据或敏感的人力资源信息。 ## 传统方案的三处硬伤 常见的 RAG 访问控制采用“复制再过滤”的方式：数据源连接器（如 SharePoint 连接器）在周期性同步任务中拉取 ACL，将其作为属性复制并存储到索引中；查询时，AI 系统把登录用户映射到已存储的 ACL 属性上，据此过滤结果。 这一做法表面合理，却有三个根本性弱点。 **第一，AI 系统并非权限的权威来源。** 在这种模式下，AI 系统独自承担权限执行的责任，却并不掌握权限的源头。这要求数据连接器在各类数据源之间准确复刻复杂且源特有的 ACL 逻辑。每个数据源都有自己的权限模型，要在几十个连接器中映射继承层级、群组成员关系、条件访问策略和拒绝规则，极易出错。 **第二，权限过期带来风险。** 周期性同步意味着权限变更无法即时反映，用户可能在一段时间内看到本已无权访问的内容。 **第三，维护成本高。** 每新增一个数据源，就要为其权限模型单独适配，扩展性差。 ## 实时验证的思路 Amazon Quick 与 Amazon Bedrock Knowledge Bases 转而采用实时 ACL 执行：在查询时刻直接与权威源核验权限。这样一来，AI 系统不再需要复制和推断权限，而是把判断权交还给真正掌握权限的系统。 对于正在推进企业 RAG 落地的团队而言，这提醒我们：访问控制不是事后补丁，而是架构设计的第一性问题。把权限验证放在正确的位置，才能在开放知识获取的同时守住安全底线。
## 为什么传统的ROI模型不再适用？ 在AI卓越中心（AI CoE）的路线图中，**智能体自动化**（agentic automation）正成为焦点。然而，大多数企业仍在用**RPA时代的ROI模型**来评估其价值——计算节省的时间乘以人力成本，再减去构建成本。这套方法专为基于规则的自动化工具设计，却严重低估了智能体所创造的价值。 传统模型建立在几个假设之上：流程稳定、任务基于规则、工作即全部职责、节省的时间等同于已实现的价值。但智能体自动化的价值恰恰存在于这些假设之外。 ### 传统商业案例的三大盲区 1. **维护成本被忽略**：RPA模型假设流程不变，因此没有考虑自动化随流程变化而产生的维护成本。 2. **异常处理无价**：模型假设任务基于规则，因此没有为异常情况设置任何价值项。 3. **人类监督成本未计入**：模型假设工作就是全部，从未计算人类监督的成本。 4. **节省的时间未必转化为利润**：释放的产能往往被积压的工作重新填满，从未到达损益表。 麦肯锡指出，成功的AI转型遵循“**1:3:5模式**”——每在智能体技术上投资1美元，就应在流程重塑上花费3美元，在能力建设和采用上花费5美元。然而，大多数公司完全颠倒了这个公式。 ## 智能体价值模型：四个维度 我们提出一个更完善的框架——**智能体价值模型**（Agentic Value Model），从四个维度衡量价值，并关注价值能否到达损益表的条件。 ### 1. 时间节省 这仍然重要，但智能体将节省时间扩展到固定规则RPA处理不佳或无法处理的工作上。 ### 2. 异常处理 智能体能够推理和适应，从而处理传统自动化无法应对的异常情况，减少人工干预。 ### 3. 决策质量 智能体可以提升决策的一致性和准确性，这部分价值在传统模型中完全缺失。 ### 4. 维护经济学 智能体能够适应流程变化，降低长期维护成本，而RPA则需要持续更新规则。 ## 如何优先选择自动化工作流？ 并非所有工作流都适合智能体自动化。AI CoE领导者应优先考虑那些**涉及判断、异常和跨系统协调**的流程，因为这些正是智能体价值最大的领域。 关键在于：**价值不在于任务本身，而在于任务周围**——判断、异常、协调。真正的收益来自围绕智能体重新设计工作流，而非将智能体塞进一个不变的流程中。 ## 结语 构建智能体自动化的商业案例，需要超越“节省时间”的狭隘视角，采用更全面的价值模型。只有这样，企业才能准确评估智能体自动化的真正潜力，并做出明智的投资决策。
Qlik 基于 **Amazon Bedrock** 打造了 **Qlik Answers**，为全球超过 **40,000 家客户**提供可溯源、可信赖的企业级 AI 问答能力。面对数据孤岛、跨区域数据主权和模型容量规划三大挑战，Qlik 采用分层多智能体架构、跨区域推理和 **Amazon Bedrock Guardrails**，在结构化与非结构化数据之上实现了规模化落地。 ## 企业 AI 的“最后一公里”：从数据到可信答案 员工并不缺数据，缺的是快速提问并获得可信答案的方式。分析师常常耗费数小时翻阅文档、仪表盘和机构记忆，只为回答同事一句简单的提问。当企业尝试用生成式 AI 填补这一鸿沟时，往往撞上同一堵墙：答案没有来源、无法验证结果、在受监管环境中难以部署。 Qlik 作为数据集成、数据质量、分析和 AI 领域的全球领导者，为其 **40,000 多家客户**构建了 **Qlik Answers**。自 2026 年 2 月正式可用以来，该产品已从早期能力走向日常使用：仅 **Discovery Agent**（AI 驱动的异常与离群值检测智能体）自发布以来就为客户发现了超过 **100,000 个发现项**，且大多数启用了智能体工具的 Qlik Cloud 账户都在积极使用。 ## 三大挑战：Qlik 如何破局 Qlik 在将 Qlik Answers 推向生产环境时，需要同时解决三个问题： **1. 编排专业推理而不拖慢速度** 企业问题差异巨大：有些需要快速查找，有些则需要从结构化分析、非结构化文档、术语定义或自动化流程中提取信息。单一的通用助手往往随着能力增加而变慢、变不准。 **2. 满足跨区域数据主权要求** Qlik 的客户遍布欧洲、亚太和美洲，每个地区都有各自的数据驻留期望。单一的全球部署模型无法满足这些要求，而 11 个独立的区域构建又难以维护和持续改进。 **3. 提前数月预测模型容量** Token 消耗和模型可用性需要在重大发布前 **3–6 个月**进行规划。Qlik 随后根据客户实际使用情况验证这些预测，确保采用率的增长不会变成容量问题。 ## 解决方案：分层多智能体架构与 Amazon Bedrock Qlik Answers 为员工（而非仅分析师）提供了一个用自然语言提问的统一入口。其核心架构包括： - **分层多智能体架构**：将不同任务分派给专门的智能体，避免单一通用助手的能力瓶颈。 - **跨区域推理**：利用 Amazon Bedrock 的跨区域推理能力，在满足数据主权的同时保持全球一致的体验。 - **Amazon Bedrock Guardrails**：为答案提供安全护栏，确保输出可信、合规。 Qlik 的实践表明，企业级 AI 的落地不仅需要强大的模型，更需要围绕数据主权、容量规划和可信溯源进行系统性设计。通过 Amazon Bedrock，Qlik 在规模化的同时兼顾了信任与合规，为行业提供了一个可复用的参考架构。
## 从「只诊断」到「可执行」：AWS 补上事故响应的最后一公里 在生产环境中，**缩短事故从发现、调查到修复的时间（MTTR）** 始终是运维团队的核心目标。但现实往往是：工程师需要在深夜快速定位跨组件问题、找到根因，再手动执行修复。 AWS 的 **DevOps Agent** 是一款由 AI 驱动的代理，能够基于关联的指标、日志和应用拓扑，全天候自动对事故进行分诊，并提供**根因分析（RCA）** 与修复建议。不过，出于对生产环境安全性的考量，多数企业会将这类可观测性代理保持在**「观察并报告」模式**——它能诊断问题，但不会直接改动生产资源。 这留下了一个缺口：AI 给出了答案，最后一步仍需人工完成。 ### 解决方案：用无服务器工作流补齐修复环节 AWS 官方博客介绍了一套自动化补救工作流，将 **AWS DevOps Agent** 的调查总结转化为**经过预验证的修复方案**，让值班工程师只需一次审批动作即可完成处置。 该方案整合了三项服务： - **AWS Lambda Durable Functions**：用于构建具备弹性的多步骤应用与 AI 工作流，最长可运行一年，无需管理额外基础设施或编写自定义状态管理与错误处理代码。函数会自动检查点进度、在长时间任务中挂起执行，并在中断后恢复，保持可靠推进。 - **Amazon EventBridge**：接收调查完成事件，并触发后续处理函数。 - **Amazon Bedrock**：用于生成或验证修复方案。 ### 工作流如何运转 根据文章描述，整体流程如下： 1. **AWS DevOps Agent 完成事故调查**，发出包含症状、发现和根因分析的事件。 2. **Amazon EventBridge** 接收该调查完成事件，触发 `devops-agent-trigger` 函数，并传入调查内容。 3. **Lambda 函数打包调查摘要**，进入后续自动化处理链路。 4. 结合 **Amazon Bedrock** 将调查总结转化为预验证的修复动作。 5. 在变更真正触达基础设施之前，**可选地加入人工审批环节**，值班工程师一键确认即可执行。 ### 为什么值得关注 这套方案的价值在于平衡了自动化与可控性：既保留了 AI 代理在诊断阶段的高效，又通过**单次审批**机制避免了 AI 直接改动生产资源带来的风险。对于希望降低 MTTR、同时又不愿放弃人工把关的团队来说，这是一种务实的折中路径。 目前该方案仍以官方技术博客形式呈现，具体的部署细节、Bedrock 提示词设计以及审批机制实现，需参考原文完整内容。
## 真正的障碍不是「不知道」，而是「没动过手」 企业在推动 AI 落地时，最大的拦路虎往往被误判为「认知不足」。但 AWS 在一项内部调研中发现，**90% 的业务人员其实渴望亲手构建 AI 智能体**，他们缺的不是意愿，而是安全上手的「脚手架」——合适的工具、结构化的支持和允许试错的空间。 这些人的岗位大多在销售、运营、财务或产品部门，日常并不写生产代码，却越来越多地被要求评估 AI 方案、回应客户疑问、挖掘自动化机会。他们看过演示、考过认证，可一旦被问到「这东西到底怎么跑起来的」，却答不出只有亲手构建过才能给出的答案。这种「知」与「行」之间的断层，直接拖慢了采用速度，也错失了大量真实场景中的落地机会。 ## 数据揭示的断层 调研中，**80% 的受访者表示探索过 Amazon Bedrock 及 Amazon Bedrock AgentCore**——后者是一个可用任意框架或模型大规模构建、连接和优化智能体的平台。然而，**真正动手碰过 Strands Agents SDK 或用 AWS Lambda 构建智能体的人不足五分之一**。 更值得注意的是，许多人主动回避黑客松和构建活动，原因是「觉得自己的技术底子不够，没法跟工程师同台竞争」。这种心理门槛，比技术门槛更隐蔽，也更致命。 ## 六周「造物」计划：配对导师，用生产级工具做原型 针对这一现状，团队设计了一套为期**六周的结构化项目**，核心做法是： - **将业务人员与导师配对**，降低独自摸索的挫败感； - **直接使用生产级工具**，而非玩具级沙盒，让原型在项目结束后仍具备扩展潜力； - **营造允许失败的氛围**，把「不敢碰」转化为「敢试错」。 项目的目标不是把业务人员训练成工程师，而是让他们具备「构建者」的底气——能亲手搭出可运行的 AI 原型，并在组织中持续放大这种能力。 ## 为什么这套方法值得复制 当前 agentic AI 工具已大规模开放，企业内部的 AI 对话早已无处不在。真正的分水岭不在于谁懂得多，而在于谁动过手。当业务团队从「讨论 AI」转向「用 AI 造东西」，采用速度、生产力增益和用例挖掘都会随之改变。这套六周手册的价值，正在于它提供了一条可复制的路径：**用结构化支持替代技术门槛，用动手构建替代纸上谈兵。** > 对于希望缩小 AI 知识—能力差距的组织而言，关键动作或许很简单：给工具、给导师、给许可，然后让业务人员自己造一次。
在数据库运维领域，故障排查往往依赖人工经验，耗时且效率低下。Cornerstone OnDemand 的 Enterprise DataOps 团队曾面临这一困境：每次数据库性能问题平均需要 **45 分钟**的诊断时间，工程师们不得不在多个工具和系统视图之间手动查询、交叉引用日志，再跨团队交接。如今，这一局面被一个名为 **Orion AI** 的多智能体系统彻底改变。 ### 从被动救火到主动自动化 Cornerstone OnDemand 是一家全球领先的劳动力就绪解决方案提供商，服务覆盖 **186 个国家、1.4 亿用户**。其 Enterprise DataOps 团队此前长期处于被动响应状态，四大痛点尤为突出： - 数据库性能调查每次耗时约 **45 分钟**，涉及多个工具和系统视图； - 数据库生命周期工作流需要 **10 个以上**手动步骤，从建立连接到状态更新沟通； - SRE 团队与数据团队之间的报告存在 **15 分钟延迟**； - 冗余和重叠的警报制造噪音，掩盖了真正重要的信号。 这些因素导致工程师的时间被大量消耗在手动协调上，而非解决问题本身。 ### Orion AI 的架构与设计 Orion AI 是一个多智能体系统，采用**中心辐射型拓扑**：一个协调智能体（元编排器）将任务委派给多个专业子智能体。工程师通过一个 Web 应用与系统交互，在同一界面中提问并批准操作，无需切换工具。 这些智能体覆盖基础设施监控、数据库诊断、数据库生命周期操作、客户分析和知识驱动支持等场景。系统的构建遵循两大原则： - **数据隐私**：依托 AWS 共享责任模型下的控制措施； - **深度集成**：与现有运维工具无缝对接。 技术栈上，**Amazon Bedrock** 提供对基础模型的托管访问，**Strands Agents**（AWS 开源智能体编排框架）则充当编排层。 ### 成果与可复用经验 Orion AI 上线后，数据库诊断时间从 **45 分钟骤降至 10 分钟**，降幅达 **78%**。更令人瞩目的是，这一系统由一个 **三人团队在六个月内**完成交付。 对于其他希望复用的团队，Cornerstone 的设计决策提供了宝贵参考： - **明确痛点优先级**：聚焦高频、高耗时的运维环节； - **中心辐射架构**：平衡集中协调与专业分工； - **选择托管服务**：降低基础设施负担，加速开发； - **紧密集成现有工具**：减少工程师的学习成本与切换开销。 这一案例表明，多智能体系统在运维自动化领域具有巨大潜力，能够将工程师从重复性劳动中解放出来，专注于更高价值的任务。
## 为什么你的 AI 助手总是“失忆” 市面上的 AI 助手单轮问答表现不错，但一旦涉及连续性就露怯。你三周前提到自家花坛排水太快、只使用有机肥、矮牵牛正被热浪折磨——这些信息在下一轮对话中全部归零。问题不在回答质量，而在于助手对你一无所知。 AWS 机器学习博客近日发布了一篇技术方案，展示如何利用 **OpenClaw** 开源智能体系统与 **Amazon Bedrock AgentCore** 运行时，构建一个能持续积累上下文的个人助手。示例场景是一个名为 **Sprout** 的园艺助手，但架构本身与领域无关——替换角色设定和技能清单后，同一套流水线可服务于客服机器人、健身教练或内部帮助台。 ## 架构拆解：两个入口，一个智能体 整个方案的请求流从两个入口汇聚到同一个 AgentCore 运行时智能体： - **Telegram 消息**：经 Amazon API Gateway 与 Webhook Lambda 函数进入； - **定时任务**：如晨间浇水提醒，由 Amazon EventBridge Scheduler 与 cronjob Lambda 触发。 两者都调用 AgentCore 运行时的 `InvokeAgentRuntime` API。运行时内一个轻量级 `server.py` 进程负责协调 **OpenClaw 网关**、**AgentCore memory** 与 **Amazon Bedrock Converse API**。工作区存储由 Amazon S3 提供。 ## 记忆如何变成可检索的知识 AgentCore memory 的核心价值在于将一次性对话转化为持久化、结构化的知识。方案特别强调了**元数据标签**的作用：给记忆打上结构化标签后，就能用元数据过滤器检索与当前问题真正相关的记录。 例如，Sprout 可能记住“用户的三周前提到花坛排水快”，并附上 `topic: garden_bed`、`time: 3_weeks_ago` 等标签。当用户今天问“我的矮牵牛怎么了”，系统能精准调取相关历史，而不是翻遍全部聊天记录。 ## 成本与部署 整套系统封装在单个 **AWS CloudFormation 模板**中，一条命令即可部署，采用按量计费模式。对于轻度个人使用，月成本仅**几美元**。 ## 设计启示 这篇方案传递了一个明确信号：AI 助手的竞争维度正在从“单点回答质量”转向“跨会话连续性”。AgentCore memory 提供的结构化记忆与元数据过滤，为开发者提供了一条可复用的路径。如果你正在构建任何需要记住用户的助手，这套架构值得参考。
生成式 AI 的普及速度已经超过个人电脑和互联网，2025 年全球 AI 相关投资规模高达 **5816.9 亿美元**。当企业争相把 AI 嵌入运营流程时，一个棘手的问题随之而来：如何确保这项技术被负责任地使用？AWS 给出的答案之一，是推动客户对齐国际标准 **ISO/IEC 42005:2025**，并把「AI 系统影响评估」作为治理体系的关键抓手。 ## 为什么需要 AI 系统影响评估 按照 AWS 的表述，AI 系统影响评估是一套**文档化的风险识别流程**。无论是开发、提供还是使用 AI 系统的组织，都需要通过这一流程审视 AI 对组织自身、个人、社区、群体乃至整个社会可能造成的影响。 它的价值不只是「合规打勾」，而是把评估输出接入企业更广泛的风险管理体系，让 AI 风险与其他业务风险在同一套语言下被讨论和处置。对于正在从试点走向规模化部署的企业来说，这种系统化方法能减少「边做边补」带来的治理盲区。 ## 标准为何重要 AWS 在文中强调，基于标准的治理框架是一条务实的路径，而 AWS 的投入方向是让这些标准**可执行**。具体来看： - Amazon 长期参与 ISO 的 AI 风险管理标准制定，并已为多项 AI 服务取得相关认证，包括 **Amazon Bedrock**、**Amazon Q Business**、**Amazon Transcribe** 和 **Amazon Textract**。 - AWS 同时鼓励客户用这些标准去认证自己的服务。 - 在工具层面，AWS 提供了对齐 ISO/IEC 42005 等负责任 AI 实践的支撑，例如 **ISO/IEC 42001:2023 AI 管理体系（AIMS）在 AWS 上的实施指南**，以及 **Well-Architected Framework 的 Responsible AI Lens**，帮助客户把标准嵌入企业风险管理生态。 ## 谁在承担「翻译」工作 文章引用 AI Adoption Initiative 相关研究者的观点，提出劳动力通过一个「AI 劳动力栈」与 AI 产生关联，其中包含 AI 创新者、促进者和使用者。研究者认为，**促进者往往是国家 AI 战略中「缺失的中间层」**，但他们恰恰负责把 AI 能力转化为企业、行业和公共服务中的实际部署。 AWS 表示，其支持的对象正是这群促进者——帮助他们在组织内建立或改进系统化的 AI 治理方法。 ## 一个值得注意的信号 ISO/IEC 42005:2025 把 AI 系统影响评估的最佳实践进行了标准化，涵盖如何开展评估以及如何记录评估结果。对于希望在全球市场保持合规一致性的企业而言，这类标准正在从「加分项」变成「基础设施」。AWS 的布局逻辑也很清晰：先让自身服务通过认证，再把实施指南和架构框架开放给客户，降低对齐门槛。 AI 治理不会因为一份标准就自动落地，但有了可参照的流程和工具，企业至少不必从零摸索。
## 当共享集群遇上多团队协作 **Amazon SageMaker HyperPod** 为机器学习团队提供了大规模加速计算资源，用于训练和微调模型。当多个团队共用一个集群时，技术搭建通常不是难题——真正的挑战在于**治理**：谁可以用集群？每个团队分多少容量？资源竞争时如何仲裁？使用偏离策略时谁负责？ AWS 最新发布的一篇技术博客，系统性地回答了这些问题。文章聚焦于如何通过 **Amazon SageMaker Unified Studio** 来管理 HyperPod，同时保留底层治理控制。 ## 四层控制模型 文章提出了一个可重复的治理框架，涵盖四个控制层级： - **组织层**：定义整体基础设施边界与身份策略 - **项目层**：管理团队对集群的访问权限与项目关联 - **集群层**：分配共享容量、设置资源配额 - **工作负载层**：监控任务运行、审计使用情况 这个分层设计的核心思路是**职责分离**：基础设施团队继续通过 Amazon SageMaker AI 接口和 API 管理集群，而 ML 团队则在项目工作区内发起训练任务。 ## Unified Studio 带来的便利与挑战 通过 SageMaker Unified Studio，用户可以将一个 SageMaker HyperPod 集群连接到一个项目。项目成员随后可以启动机器学习工作负载、查看集群和任务信息，甚至打开 JupyterLab 工作流。 这种便利性很有价值，但也带来了新的治理考量：当多个团队共享同一个集群的可见性时，**谁可以做什么**的控制变得更加关键。文章强调，需要跨这些层级设计身份、容量和可观测性策略。 ## 可复用的运营模式 文章最终给出的建议是建立一个**可重复的模型**：基础设施团队保留集群运营职责，同时以项目上下文的方式向 ML 团队提供经过审批的 HyperPod 计算资源。这种模式既利用了既有的云运营流程，又让 ML 团队能在熟悉的项目环境中高效工作。 对于正在规模化 AI 训练能力的企业而言，这套治理框架提供了一条兼顾效率与合规的路径。
## 告别命令行：HyperPod Spaces 管理迎来图形化界面 对于使用 **Amazon SageMaker HyperPod** 进行基础模型训练和推理的团队来说，一个长期存在的效率瓶颈正在被打破。AWS 近日宣布，用户现在可以直接在 **SageMaker Studio** 的用户界面中，创建和管理运行在 HyperPod EKS 集群上的 **SageMaker Spaces**。这意味着数据科学家和机器学习工程师无需离开浏览器，也无需使用命令行工具，即可在几秒内启动 **JupyterLab** 和 **Code Editor** 开发环境。 ### 背景：从 CLI 到可视化管理的演进 SageMaker HyperPod 是 AWS 专为大规模基础模型训练和推理打造的基础设施，通过 **Amazon EKS** 编排，团队可以在数百个加速器上运行分布式训练作业，并享有内置的弹性和自动故障恢复能力。今年早些时候，AWS 推出了 **SageMaker Spaces for HyperPod**，这是一个附加组件，允许开发者在 HyperPod EKS 集群上直接创建交互式开发环境。其核心价值在于，组织可以让交互式工作负载与训练作业、模型部署在同一套基础设施上并行运行，并支持 **分数 GPU 分配**，从而最大化 GPU 投资回报。 然而，此前创建和管理 Spaces 主要依赖 **HyperPod CLI** 或 **kubectl** 命令。虽然这种方式为基础设施管理员提供了强大而精细的控制，但对于偏好可视化界面的数据科学家来说，操作门槛较高。 ### 新功能：Studio 中的完整管理界面 此次更新在 HyperPod 集群详情页中新增了 **IDE and Notebooks 标签页**，提供了一个完整的 Space 管理用户界面。主要能力包括： - **创建 Space**：通过引导式表单配置计算资源、命名空间、存储、HyperPod Task Governance 计算配额管理以及镜像设置。 - **查看所有 Space**：在可搜索的表格中查看名称、应用类型、状态、访问类型、存储、GPU 和 vCPU 分配情况。 - **启动和停止 Space**：一键操作，方便在 Space 闲置时释放计算资源。 ### 意义与影响 这一更新显著降低了使用 HyperPod 进行交互式开发的复杂度。数据科学家不再需要记忆 CLI 命令或依赖 kubectl 配置，就能快速获得开发环境，将更多时间投入到模型开发本身。对于已经采用 HyperPod 进行大规模训练的企业来说，这有助于提升 GPU 资源利用率，并让更多团队成员能够自助式地使用高性能计算资源。 从行业趋势看，AI 开发工具正从“基础设施为中心”向“开发者体验为中心”转变。AWS 此次将 HyperPod Spaces 的管理能力集成到 Studio，正是这一趋势的体现。不过，目前该功能主要面向已使用 SageMaker Studio 和 HyperPod 的用户，对于尚未部署这些服务的团队，仍需先完成底层基础设施的搭建。
## 把语音助手塞进航空公司 App，需要解决哪些问题？ 航空公司早已拥有成熟的 App 和网站，旅客可以在上面查航班、选座位、管理订单。但如果加入一层自然语音交互，这些操作就能用「说」来完成——不用退出当前页面，也不用在层层菜单里翻找。 AWS 近期发布的一篇技术博客展示了如何基于三项托管服务构建这样的**语音旅行管家**： - **Amazon Bedrock AgentCore**：用于大规模构建、部署和运营 AI Agent 的智能体平台，支持自选框架和模型； - **Amazon Nova Sonic**：Bedrock 上的语音到语音模型，面向实时语音交互； - **Amazon Bedrock Knowledge Bases**：全托管的检索增强生成（RAG）服务，让回答扎根于企业自有文档。 ### 旅客能做什么？ 按照博客描述，旅客对着 App 说话，管家就能调出行程、更改座位、更新餐食偏好、回答政策问题，并能在需要时转接人工客服。整个过程中，语音层与现有界面并行运行，旅客可以在同一次会话里自由切换点击和说话。 ### 工程上的三个关键点 博客指出，构建语音层需要在几个方面仔细设计： 1. **双向音频流**：需要同时处理上行和下行音频，并在多轮对话中保持上下文连贯； 2. **后端解耦**：Agent 要能触达现有后端系统，但又不能与它们紧密耦合； 3. **弹性伸缩**：节假日出行高峰前流量会骤增，系统需要按需扩展。 ### 技术实现路径 博客给出的方案将项目拆分为多个模块，方便复用适配现有后端，并以工具形式暴露给 Agent。具体包括： - 使用 **AWS CDK** 部署语音 AI 管家； - 用 **Strands Agents 框架**构建 Agent，结合 **Amazon Nova 2.5 Sonic** 实现实时语音，托管在 **AgentCore runtime** 上； - 通过 **AgentCore Gateway** 以 **MCP（Model Context Protocol）** 连接后端服务； - 用 **Amazon Bedrock Knowledge Bases** 回答航空公司政策问题； - 在需要时向旅客提供参考编号并转接人工客服。 博客强调，示例后端使用合成数据，便于开发者将模式迁移到自己的系统。Agent 在写入任何更改前都会先与旅客确认，确保操作可控。 ### 为什么值得关注 对于航空、酒店、零售等拥有复杂后端和大量政策问答场景的行业，这套方案提供了一条可复用的路径：用托管服务处理语音、Agent 编排和知识检索，把工程精力集中在体验和业务集成上。目前该方案以技术博客形式发布，尚未披露具体客户案例或性能数据，实际落地效果仍需结合自身系统验证。
## 智谱 GLM 5.3 上架 Amazon Bedrock 来自 **Z.ai（智谱 AI）** 的 **GLM 5.3** 现已正式在 **Amazon Bedrock** 上线。根据官方在 Hugging Face Hub 上发布的信息，这是一个拥有 **753B 参数**的**混合专家（MoE）模型**，专门针对**编码**和**长周期智能体（long-horizon agentic）任务**进行优化。 对于企业用户而言，这意味着无需自行搭建和运维推理基础设施，即可通过完全托管的 API 调用这一前沿开源权重模型。 ### 相比 GLM 5 有哪些升级？ GLM 5 今年早些时候已登陆 Amazon Bedrock，GLM 5.3 延续同一技术路线，并带来多项关键提升： - **编码能力更强**：Z.ai 称其在 **DeepSWE、Terminal Bench 3.0、FrontierSWE** 等多个编码基准上表现具有竞争力，并在内部编码基准上较 **GLM 5.2 提升约 50%**。官方未给出与 GLM 5 的直接对比，原因是改进幅度较大，相关基准测试本身已在 GLM 5.1 发布后进行了更新。 - **涌现出网络安全能力**：Z.ai 报告该模型在安全任务上的基准表现突出，发布时在 **CyberGym 基准上取得 84.5 的领先分数**，使其天然适合防御性安全流程。 - **更深入的 Amazon Bedrock 集成**：支持**跨区域推理配置文件**、**隐式与显式提示缓存（prompt caching）**，并在 **OpenAI 兼容的 Responses 与 Chat Completions API** 以及 **Invoke 与 Converse API** 之间实现了更好的功能对齐。 ### 核心能力定位 GLM 5.3 面向**复杂系统工程**与**长周期智能体任务**设计，包括多步推理、工具调用等场景。典型用例包括：跨数百个文件重构代码仓库、维持数小时不丢失上下文的智能体工作流，以及在每一步都依赖工具调用的复杂系统问题推理。 ### 如何在 Bedrock 上使用 在 Amazon Bedrock 上，用户可以通过 **OpenAI 兼容 API** 调用 GLM 5.3，并借助**提示缓存**降低成本和延迟。官方博客还演示了一个实际智能体工作流：使用开源 AI 渗透测试智能体 **Strix** 对自有应用运行**经授权的安全测试**。 目前，GLM 5.3 在 Bedrock 上的访问权限面向**符合条件的企业客户**开放。 > 需要注意的是，本文所述基准数据均来自 Z.ai 官方发布，实际表现可能因任务和配置而异。
## 监管环境下的 AI 编码新通道 对于需要满足严格合规要求的组织而言，将生成式 AI 引入日常开发流程一直是个棘手问题。**Anthropic 的 Claude Opus 5.5 和 Claude Sonnet 5.5 现已在 AWS GovCloud (US) 区域上线**，为受监管和 ITAR 工作负载提供了一条 AI 辅助开发的合规路径。 ### 为什么这次发布值得关注 AWS GovCloud (US) 专为有高合规需求的美国客户设计，允许在敏感环境中部署生成式 AI 工作负载，同时保持合规控制。Amazon Bedrock 在此区域内置了多项安全特性： - **数据保护**：客户内容不会被存储、记录日志、用于训练 AWS 模型，也不会与第三方共享。 - **合规认证**：Claude Sonnet 5 持有 FedRAMP Class D（原 High）认证以及 DoD Impact Level 4 和 5（IL4/IL5）授权；Claude Opus 5.5 和 Claude Sonnet 5.5 在 Amazon Bedrock 上持有 FedRAMP Class D 认证。 - **安全集成**：与 AWS GovCloud (US) 中现有的安全控制和合规框架集成，在保持与其他 AWS 区域相同高标准的同时，提供额外的授权路径。 ### Claude Code 如何融入这一场景 **Claude Code** 是 Anthropic 的智能体编码工具。结合 Amazon Bedrock 在 GovCloud 中的部署，开发团队可以运行 AI 辅助工作流，加速日常开发任务，同时保持合规对齐。这意味着受监管行业的开发者不必再在效率和合规之间做非此即彼的选择。 ### 技术实现要点 Amazon Bedrock 在 AWS GovCloud (US) 中支持两个端点界面：**bedrock-runtime** 和 **bedrock-mantle**，两者均由相同的底层 Mantle 推理引擎驱动，采用零操作员访问（ZOA）架构。其中 bedrock-runtime 端点使用 AWS SDK（InvokeModel 和 Converse API），并支持 Amazon Bedrock Guardrails 和 Amazon Bedrock Knowledge Bases。 ### 需要留意的边界 需要注意的是，此方案并非适用于所有组织或合规计划。在采用前，务必根据自身组织的合规要求及适用的监管义务进行评估。同时，模型认证状态可能变化，建议查阅 Amazon Bedrock 模型合规页面获取最新信息。 对于在政府、国防或受监管行业工作的开发团队而言，这一组合提供了一条值得认真评估的 AI 辅助开发路径——既利用了前沿模型能力，又未脱离合规框架。
## 从“会写代码”到“会调优推理”：SageMaker 给编程 Agent 装上新技能 开发者们早已习惯用 **Kiro、Claude Code、Codex** 等编程助手来加速日常开发，但面对 Amazon SageMaker AI 上复杂的推理部署——选实例、挑容器、调参数——这些助手往往爱莫能助。现在，亚马逊为它们补上了这块短板。 Amazon SageMaker AI 优化生成式 AI 推理正式推出 **aws-ai-ml 技能**，通过 **Agent Toolkit for AWS** 提供给各类编程 Agent。安装后，你的编程助手将获得推理优化与基准测试的深度专业知识，能够： - 对端点进行基准测试 - 推荐部署配置 - 对比不同性能运行结果 - 生成可执行的 **SageMaker Python SDK v3** 代码 ### 为什么需要这个技能？ SageMaker AI 的托管能力覆盖实时、批量和异步模式，支持按需与预留容量、异构实例、VPC 隔离、自动扩缩容，并与所有 SageMaker AI 训练路径集成。功能强大，但**广度与深度并存**意味着大多数工程师在开始时并不清楚哪个实例族或服务容器最适合自己的场景。他们带着的是**用例**：一个性能目标、一个成本上限，或者一个待评估的模型。 aws-ai-ml 技能正是为了弥合“意图”与“基础设施”之间的鸿沟。你只需告诉 Agent 你想达成什么，它就会生成可执行的 SageMaker Python SDK v3 代码，供你审查、修改并在自己的环境中运行。Agent 会提出有针对性的澄清问题，基于真实基准和实测性能数据生成代码，并像解决方案架构师一样适应你的业务约束。整个过程**完全透明**，每一步都以代码形式实时呈现，没有黑盒 UI。 ### 快速上手 你可以通过 Agent Toolkit for AWS 在本地安装 aws-ai-ml 技能，也可以在 Amazon SageMaker Studio 的 JupyterLab 空间中使用。无论哪种方式，**10 分钟内**就能从零开始进入工作对话。 该技能本质是一个工具包，可插入任何支持 **Model Context Protocol (MCP)** 的编程 Agent，将其转变为 SageMaker AI 推理优化专家。对于正从模型原型走向生产部署的团队来说，这或许能显著缩短调试与选型的时间。
## 从手动重建到一键晋升 企业团队在开发账户中快速搭建 Amazon Quick 的智能体、操作连接器、知识库和空间，但将这些资源迁移到生产账户时，却只能手动重建——重新配置每个智能体、重新关联连接器、重新授权、重新配置 S3 存储桶和知识库数据源。这个过程不仅缓慢、难以审计，还容易出错，削弱了企业所需的治理能力。 AWS 最新发布的一篇技术文章提出了一种解决方案：在 **Amazon Bedrock AgentCore** 上构建一个**幂等、可审计的 MCP 服务器**，实现跨账户资源晋升的自动化。 ## 核心思路：用 API 驱动治理 Amazon Quick 的资源本身是可编程的。通过 Amazon Quick API（属于 Amazon Quick Sight API 的一部分），团队可以对空间、智能体、操作连接器、知识库和流程进行完整的生命周期管理——创建、读取、更新、删除和列出。这意味着，任何业务用户在 Quick 中配置的内容，都可以通过 API 检查、重建、更新和治理，包括权限。 该方案的关键在于：**不再手动重建每个资源，而是通过 API 读取资源及其权限，然后在另一个账户中精确复现**。这实现了真正意义上的“晋升”，即从开发环境到生产环境的受控迁移。 ## 为什么重要 对于运行独立开发、生产和 QA 账户的企业来说，缺少原生的跨账户晋升机制一直是个痛点。手动重建不仅耗时，而且难以保证一致性，审计追踪更是几乎不可能。通过自动化、幂等的 MCP 服务器，团队可以获得： - **可重复性**：每次晋升都产生相同的结果，消除人为错误 - **可审计性**：所有操作通过 MCP 服务器记录，满足合规要求 - **治理能力**：权限和资源配置随资源一起迁移，确保安全策略一致 ## 技术实现要点 该方案基于 **Model Context Protocol (MCP)**，并在 Amazon Bedrock AgentCore 上运行。MCP 服务器作为中间层，封装了读取源账户资源、在目标账户中重建资源的逻辑。幂等性设计确保重复执行不会产生副作用，这对于生产环境的稳定性至关重要。 虽然文章未披露具体代码细节，但强调了“读取-复制-应用”的模式：通过 API 获取资源定义和权限，然后在目标账户中重新创建。这为企业在多账户架构下管理 AI 资源提供了可复用的范式。 ## 展望 随着智能体 AI 在企业中的普及，跨环境资源管理将成为刚需。Amazon Quick 的这一方案展示了如何利用可编程 API 和 MCP 协议，将治理和自动化结合起来。对于正在探索 AI 落地的企业而言，这种模式不仅适用于 Quick，也可能为其他 AI 服务的跨账户管理提供参考。