随着AI Agent在企业中的快速普及，安全挑战日益凸显。本文深入分析AWS与Cisco AI Defense的联合解决方案，如何通过自动扫描与统一治理，应对可见性不足、安全瓶颈和合规风险三大难题，助力企业安全扩展MCP与A2A部署。 ## AI Agent规模化带来的安全新挑战 自2024年11月**Model Context Protocol (MCP)** 推出以来，企业部署的MCP服务器数量从个位数激增至数十乃至上百个。这些服务器充当AI Agent与外部数据源、API之间的桥梁，极大扩展了Agent的能力。2025年4月，**Agent-to-Agent (A2A) Protocol** 的发布进一步推动了自主Agent间的直接通信，无需人工介入。随后，**Agent Skills** 在企业基础设施中遍地开花。 这种快速增长暴露了三大安全缺口： - **可见性缺失**：团队无法全面掌握哪些工具和Agent正在运行，安全团队难以维持监督。 - **安全审查瓶颈**：手动审查流程无法匹配部署速度，每个AI应用部署可能延迟数周，形成积压。 - **合规风险**：SOX、GDPR等框架要求审计追踪，但自主AI Agent的运作往往缺乏记录，审计失败导致监管处罚风险。 ## 联合方案：自动扫描与统一治理 AWS与Cisco AI Defense的合作直击上述痛点。通过**AI Registry**（AWS支持的开源项目）与Cisco AI Defense的集成，企业能够获得： ### 1. 全面可见性 AI Registry提供中央注册表，自动发现并记录所有MCP服务器、AI Agent和Agent Skills。无论部署在云端还是本地，安全团队都能通过统一仪表盘查看工具清单、Agent间的通信关系以及使用情况。 ### 2. 自动化安全扫描 Cisco AI Defense对每个注册的MCP服务器和Agent进行**自动安全扫描**，识别已知漏洞、恶意代码或不当权限配置。扫描结果与风险评分关联，帮助团队优先处理高危项。 ### 3. 合规审计就绪 系统自动生成审计日志，记录Agent的每一次工具调用和数据访问。这些日志符合SOX和GDPR要求，审计人员可随时回溯，大幅降低合规风险。 ## 实际价值：从数周延误到即时部署 过去，安全团队手动审查一个MCP服务器可能耗时数周，导致AI应用上线严重滞后。现在，自动扫描将审查时间压缩至分钟级，且不牺牲安全性。对于已部署的Agent，持续监控能及时发现异常行为，避免运营中断。 ## 结语 AI Agent的规模化部署不可逆转，但安全不能成为绊脚石。AWS与Cisco AI Defense的联合方案，通过自动化、集中化的安全治理，为企业提供了“加速而不牺牲安全”的可行路径。对于正在扩展AI Agent的企业而言，这不仅是技术升级，更是合规与信任的基石。
在微调大语言模型（LLM）时，如何平衡数据治理与机器学习服务的高效性是一大挑战。本文介绍了一种将 **Databricks Unity Catalog** 与 **Amazon SageMaker AI** 集成的安全、完整的 LLM 微调工作流，并利用 **Amazon EMR Serverless** 进行数据预处理。该方案可在保持统一治理、追踪数据血缘的同时，使用现有服务进行模型训练，不牺牲安全与合规要求。 ## 核心挑战 当使用 SageMaker AI 微调 LLM 时，若底层数据存储在 Amazon S3 并由 Unity Catalog 管理元数据和权限，训练任务直接读取 S3 对象会绕过 Unity Catalog 的细粒度授权模型，导致策略执行不一致、审计漏洞和合规风险。例如，无法追踪哪些数据训练了哪些模型，这在受监管行业和生产环境中尤为关键。 ## 解决方案架构 该工作流包含以下步骤： 1. **数据读取**：从 Unity Catalog 管理的表中读取训练数据，确保经过治理控制。 2. **数据预处理**：使用 **EMR Serverless** 运行 Apache Spark 进行数据清洗和转换，无需管理集群。 3. **模型微调**：利用 **SageMaker AI Training** 作业对 **Ministral-3-3B-Instruct** 模型进行微调。 4. **血缘追踪**：将训练后的模型注册回 Unity Catalog，并在其中追踪从源数据到模型的完整数据血缘。 ### 架构组件 | 组件 | 用途 | |------|------| | Amazon SageMaker AI Studio (JupyterLab Space) | 工作流编排与模型训练 | | Amazon EMR Serverless | 基于 Spark 的数据预处理，无需集群管理 | | Databricks Unity Catalog | 元数据目录、治理与血缘追踪 | | Hugging Face | 获取预训练模型 | | Amazon S3 | 数据存储 | ## 实施要点 - **安全访问**：通过 IAM 角色和 Unity Catalog 的授权机制，确保 SageMaker AI 训练作业只能访问已授权数据。 - **血缘维护**：在 Unity Catalog 中记录数据来源、转换步骤和模型输出，满足审计要求。 - **无服务器处理**：EMR Serverless 自动扩缩容，简化基础设施管理。 该集成模式适用于受监管行业的 AI 工作负载，帮助企业在不放弃现有工具的前提下实现集中治理与可追溯性。
在金融监管日益严格的背景下，亚马逊金融科技团队正借助AWS的生成式AI服务，打造一套可扩展的智能应用，彻底改变监管问询的处理方式。该方案以 **Amazon Bedrock** 为核心，结合知识库、检索增强生成（RAG）等技术，让各团队能够自主构建并维护专属的监管知识体系。 ## 挑战与方案 传统监管问询依赖人工查阅大量文档，耗时且易出错。Amazon Finance的解决方案允许每个团队创建独立的 **知识库**，上传内部政策、合规手册、历史问询记录等专属资料。当收到监管问询时，系统自动检索相关文档，并利用大语言模型生成准确、合规的回复草稿，大幅缩短响应时间。 ## 技术架构亮点 - **Amazon Bedrock**：作为生成式AI的基础平台，提供对基础模型的访问，并支持私有化部署，确保数据安全。 - **知识库与RAG**：通过Amazon Bedrock的知识库功能，团队可轻松上传文档，系统自动进行向量化处理。RAG技术确保模型生成的回答严格基于团队自有数据，减少幻觉风险。 - **可扩展性与治理**：每个团队独立管理知识库，既保证了灵活性，又通过统一的权限控制满足审计与合规要求。 ## 落地价值 该应用已在Amazon内部多个金融团队试点，显著提升了监管问询的处理效率。据内部数据显示，**问询响应时间缩短了60%以上**，同时回复一致性和准确性得到提升。更重要的是，方案降低了合规门槛——非技术团队也能通过简单的文档上传，快速构建AI驱动的问答能力。 ## 行业启示 这一实践展示了生成式AI在高度监管行业的落地路径：**不是替代人工，而是增强专业能力**。通过将领域知识注入AI系统，企业既能享受自动化带来的效率红利，又能牢牢把控合规风险。对于金融、医疗等强监管行业，这种“可控的AI”模式或将成为主流。
在智能文档处理（IDP）领域，一个长期存在的痛点是如何为未知文档集合快速创建提取模式（Schema）。传统方法需要大量人工标注和分类，成本高昂且难以规模化。AWS 最新推出的 **多文档发现（Multi-Document Discovery）** 功能，为这一问题提供了自动化解决方案。该功能作为 IDP Accelerator 的预处理步骤，能够自动分析未知文档，通过视觉嵌入（Visual Embeddings）进行聚类，并利用 AI 代理（Agents）生成对应的模式，从而大幅降低从原始文档到可执行提取流程的门槛。 ## 核心机制：从混乱到有序 多文档发现功能的核心流程分为三步： 1. **文档聚类**：基于文档的视觉特征（如布局、字体、表格结构等）生成嵌入向量，自动将相似文档归为一类。无需预先定义类别，系统自主发现文档类型。 2. **模式生成**：对每个聚类中的代表性文档，利用 **Amazon Bedrock** 提供的大模型能力，自动分析并生成提取模式（包括字段名、数据类型、位置等）。 3. **配置输出**：生成符合 IDP Accelerator 要求的配置文件，可直接用于后续的文档提取任务。 这一过程完全自动化，用户只需上传文档集合（通过 S3 存储桶或 ZIP 文件），即可获得结构化的模式配置。 ## 技术亮点：视觉嵌入与代理协作 该功能的两个关键技术组件值得关注： - **视觉嵌入（Visual Embeddings）**：不同于传统的 OCR 或文本分析，视觉嵌入直接捕捉文档的版面布局和视觉特征，使得即使文档内容差异较大（如发票与合同），只要视觉结构相似就能被正确聚类。这对于处理混合文档集合尤其有效。 - **AI 代理（Agents）**：在模式生成阶段，系统使用基于大模型的代理来模拟人类专家的分析过程，能够理解文档中的字段含义、层级关系，并生成准确的提取规则。 ## 实际应用与价值 多文档发现功能特别适合以下场景： - **海量文档归档**：企业拥有大量未分类的历史文档（如扫描件、PDF），需要快速建立索引和提取关键信息。 - **动态文档类型**：不断接收新格式文档的业务流程（如供应商发票），无需每次手动配置。 - **IDP 项目启动**：在正式部署 IDP 前，快速了解文档集合的组成和复杂度，降低项目风险。 该功能已集成到 **IDP Accelerator**（一个开源的、无服务器文档处理解决方案）的 Discovery Module 中。用户可以通过 IDP Accelerator 控制台直接使用，或通过 API 集成到现有工作流。 ## 行业影响与展望 多文档发现功能的推出，标志着文档处理自动化从“半自动”迈向“全自动”的重要一步。过去，企业需要投入大量人力进行文档分类和模式定义，现在这一过程可以完全由 AI 驱动。结合 Amazon Bedrock 的多模型支持，该功能具备良好的扩展性，未来有望支持更复杂的文档类型和提取需求。 对于正在构建智能文档处理管线的团队来说，这一功能显著降低了初始配置的复杂度，使得 IDP 项目能够更快地从试点走向生产。
2025 年 8 月 2 日生效的 **欧盟 AI 法案** 对微调大型语言模型（LLM）的组织提出了新的合规要求：必须追踪微调过程中消耗的计算资源（以浮点运算次数 FLOPs 计量），以确定是否触发新的监管义务。本文介绍如何利用开源工具 **Fine-Tuning FLOPs Meter** 在 **Amazon SageMaker AI** 上实现 FLOPs 追踪，通过一个配置标志即可判断合规状态，并生成审计就绪文档。 ## 欧盟 AI 法案与 FLOPs 追踪要求 法案将 AI 模型的使用者分为两类： - **下游用户**：使用现有模型且未进行实质性修改的组织，义务较轻。 - **GPAI 模型提供者**：对模型合规性负全责的组织，需承担更严格的义务。 微调 LLM 时，分类取决于微调消耗的计算量是否超过原始训练计算量的 **三分之一（30%）**。若超过，则视为进行了“实质性重新训练”，使用者将被重新分类为提供者。 ## 为什么是 30% 阈值？ 监管分析认为，使用超过原始训练计算量 30% 的算力进行微调，通常会导致模型行为发生显著变化，相当于创建了一个具有不同风险的新模型，因此应承担完整的提供者义务。 ## 大多数组织面临的情景 由于模型提供者很少公布精确的预训练 FLOPs，多数组织只能估算。下表列出了三种常见情景： | 情景 | 描述 | 合规状态 | |------|------|----------| | 1 | 已知原始训练 FLOPs，微调消耗低于 30% | 下游用户 | | 2 | 未知原始训练 FLOPs，需估算 | 需估算后判断 | | 3 | 微调消耗超过 30% | GPAI 提供者 | ## 使用 Fine-Tuning FLOPs Meter 实现追踪 **Fine-Tuning FLOPs Meter** 是一个开源工具，可集成到 Amazon SageMaker AI 的微调流水线中。它通过在训练脚本中添加一个配置标志（`--track-flops`），自动记录每次训练作业的 FLOPs 消耗，并与预设阈值比较，输出合规状态。 ### 核心能力 - **自动计算 FLOPs**：基于模型架构、参数量、训练数据量、批次大小、训练步数等参数，精确估算微调消耗的 FLOPs。 - **合规判断**：用户可设置原始训练 FLOPs（如已知），工具自动计算微调比例并给出“下游用户”或“GPAI 提供者”的结论。 - **审计就绪文档**：生成包含计算过程、参数细节和最终结论的报告，可直接用于审计。 ### 集成步骤 1. **准备 SageMaker 训练环境**：创建 Notebook 或使用 SageMaker Studio，配置 IAM 角色和网络。 2. **安装 Fine-Tuning FLOPs Meter**：通过 pip 安装 `fine-tuning-flops-meter` 包。 3. **修改训练脚本**：在 PyTorch 或 TensorFlow 训练脚本中导入工具，添加 `--track-flops` 参数。 4. **启动训练作业**：使用 SageMaker SDK 或控制台启动训练，工具自动记录 FLOPs。 5. **查看报告**：训练完成后，在 CloudWatch 日志或输出目录中获取合规报告。 ## 实际案例 假设某组织使用 Llama 2 7B 模型进行领域微调，原始训练 FLOPs 约为 1.7×10²²（来自公开论文）。微调使用了 1000 条数据，训练 3 个 epoch，批次大小为 8。Fine-Tuning FLOPs Meter 估算微调消耗为 5.1×10¹⁸，远低于 30% 阈值（5.1×10²¹），因此合规状态为“下游用户”。 ## 总结 欧盟 AI 法案的 FLOPs 追踪要求看似复杂，但借助 Amazon SageMaker AI 和 Fine-Tuning FLOPs Meter，组织可以轻松实现自动化合规判断。这一方案不仅降低了手动计算错误的风险，还为审计提供了可靠证据。对于正在微调 LLM 的企业，建议尽早集成此类工具，以应对不断演变的监管环境。
## 快速上手：让 AI Agent 具备实时网络搜索能力 在 AI Agent 的实际应用中，**实时获取外部信息** 是突破模型知识边界的关键。近期发布的 Strands Agents 框架与 Exa 搜索引擎的集成，为开发者提供了一套轻量级方案：让 Agent 能够自主执行网络搜索，并将结果纳入推理链条。 ### 集成架构：两个核心工具 Exa 集成在 Strands 中暴露了两个核心工具： - **`web_search`**：执行关键词或自然语言查询，返回结构化结果列表（标题、摘要、URL）。 - **`web_contents`**：根据 URL 抓取指定页面内容，用于深度分析。 开发者只需在 Agent 配置中声明 Exa 工具的 API 密钥，即可启用。无需额外编排，Agent 会在需要时自动调用这些工具，就像调用计算器或数据库一样自然。 ### 实际用例：多步骤任务中的搜索链 以一个典型的“竞品调研”场景为例： 1. Agent 先使用 `web_search` 查询“2024 年最佳 AI 写作工具”，获取前 10 条结果。 2. 接着，它调用 `web_contents` 逐一打开排名靠前的产品页面，提取定价、功能列表、用户评价等关键信息。 3. 最后，Agent 将结果汇总成对比表格，并给出推荐理由。 整个过程无需人工干预，Agent 自动判断何时需要搜索、搜索什么、以及如何使用结果。 ### 对 AI 行业的启示 Strands + Exa 的组合，本质上是在解决 **大语言模型的知识截止问题**。传统上，开发者需要通过 RAG（检索增强生成）或微调来注入外部知识，但这两者都有维护成本高、更新不及时的痛点。而搜索集成模式让 Agent 直接对接实时网络，信息新鲜度与广度都大幅提升。 不过，这种模式也带来新挑战：**搜索结果的可靠性** 与 **API 调用成本**。Exa 虽然提供高质量索引，但面对恶意网站或虚假信息时，Agent 仍需具备一定的批判性筛选能力——这往往需要额外的提示工程或后处理逻辑。 ### 小结 对于希望快速为 Agent 注入实时搜索能力的团队，Strands 与 Exa 的集成是一个**开箱即用**的选择。它降低了构建“搜索增强型 Agent”的门槛，尤其适合情报收集、市场调研、竞争分析等需要频繁访问外部信息的场景。未来，随着更多搜索引擎（如 Bing、Google Custom Search）的接入，这类 Agent 的适用面将进一步扩大。
## 一句话速览 **Anthropic** 今日宣布，其原生 AI 平台 **Claude Platform** 已通过 **AWS** 正式上线，成为首个在 AWS 中提供原生 Claude 体验的云服务。用户无需额外注册、签署独立合同或管理独立账单，即可通过 AWS 账户直接调用 Claude 的全部 API、功能与控制台体验。 ## 核心看点：原生体验，零摩擦集成 Claude Platform on AWS 并非简单的模型托管服务，而是将 Anthropic 原生平台的完整能力搬到了 AWS 生态内。用户可以使用与 Anthropic 直连完全一致的 **Messages API**、**Claude Managed Agents（测试版）**、**顾问工具（测试版）**、**网页搜索与抓取**、**MCP 连接器（测试版）**、**Agent Skills（测试版）**、**代码执行**以及 **Files API（测试版）** 等全栈能力。 从接入方式看，AWS 的三项基础设施优势被无缝复用： - **身份认证**：直接使用 AWS IAM 凭证，无需管理独立 API 密钥。 - **计费**：通过 AWS Marketplace 按用量计费，AI 支出可与其他 AWS 服务统一追踪管理。 - **审计**：所有活动记录在 AWS CloudTrail 中，方便企业以一致的安全策略监控 AI 使用。 ## 与 Amazon Bedrock 互补，而非替代 需要特别注意的是，Claude Platform on AWS 的底层请求与数据处理仍在 Anthropic 侧完成，**不**像 Amazon Bedrock 那样在 AWS 安全边界内执行。因此，它更适合**没有特定区域数据驻留要求**的团队。Anthropic 明确表示，该服务与 Amazon Bedrock 上的 Claude 模型形成互补关系——用户可以根据自身合规需求选择最合适的接入方式。 ## 三步上手，极简激活 想要尝鲜的用户可通过 **AWS Marketplace** 激活服务，之后仅需三个步骤即可完成首次 API 调用： 1. **创建工作区（Workspace）**：按项目、环境或团队隔离资源，同时保持统一管理与计费。工作区也是 Claude Platform 在 IAM 中的主要资源实体。 2. **身份认证**：使用已有 AWS IAM 凭证完成鉴权。 3. **调用 API**：直接通过 Messages API 等接口发送请求。 ## 行业视角：云厂商与 AI 平台的深度绑定 此次合作标志着 AWS 在 AI 平台竞争中的一次重要卡位。此前，Anthropic 的 Claude 模型主要通过 Amazon Bedrock 对外提供，但原生平台与托管模型在功能迭代速度、工具链深度上存在差异。Claude Platform on AWS 的推出，意味着 AWS 用户现在可以**在统一账单和安全审计下**，享受与 Anthropic 直连同等的“第一方”体验。 对于企业而言，这降低了采用前沿 AI 工具的摩擦——无需跨平台管理凭证、无需单独谈判合同、无需切换控制台。但数据处理的边界问题仍是需要仔细评估的变量，尤其对于金融、医疗等强监管行业。 ## 小结 Claude Platform on AWS 是 Anthropic 与 AWS 合作深化的产物，它模糊了“云市场托管”与“原生平台”的界限。在 AI 基础设施日趋复杂、企业合规要求日益严格的当下，这种“原生体验+云生态集成”的模式可能成为未来 AI 服务交付的新范式。
在航空航天、汽车和重工业制造领域，企业通常维护着大量技术文档。这些文档不仅包含文字规范，还融合了工程图纸、CAD 图、检测照片、热分析图和疲劳曲线等视觉内容。例如，关于“喷嘴喉部最高壁温”的查询，答案可能隐藏在一张热轮廓图中，而非文字描述里。传统的纯文本检索系统无法提取这类信息，因为它们无法“看”懂图像内容。 **Amazon Nova Multimodal Embeddings** 填补了这一空白。它能够将文本、图像和文档页面映射到同一个向量空间，使得文本查询可以检索到工程图，图像查询也能找到对应的文字规范。本文基于 **Amazon Bedrock** 和 **Amazon S3 Vectors**，构建了一个面向航空航天制造文档的多模态检索系统，并在 26 个制造场景查询上评估了系统性能，对比了纯文本方案与多模态方案的生成质量。 ## 为什么多模态检索对制造业至关重要 制造文档往往混合了多种信息形式。一份工单可能既有文字装配步骤，也有标注完成的照片；检测报告包含合格/不合格测量值和焊缝射线图像；材料认证文件则列出表格化机械性能以及工程师在设计评审时必须参考的 S-N 疲劳曲线。 具体来看，本数据集中的一些典型视觉信息示例： - 工程图纸中嵌入的扭矩规范表，而非独立文字。 - 用颜色编码的热轮廓图展示火箭发动机喷嘴的峰值温度。 - 制造工艺流程图用决策菱形和颜色编码门控标识质量管控点，相关周期时间直接标注在图上。 纯文本检索系统通常通过 OCR 提取文字，再对提取的字符串进行嵌入和索引。当答案出现在文档的文字部分时，这种方式有效；但面对图中的空间关系、检测图像中的视觉模式，纯文本系统就无能为力了。 ## 系统构建与评估 本方案利用 **Amazon Nova Multimodal Embeddings** 将文档页面（包括文字和图像）统一编码为向量，存储在 **Amazon S3 Vectors** 中，并通过 **Amazon Bedrock** 进行检索。在 26 个制造场景查询上的测试表明，多模态检索能够准确返回包含关键视觉信息的文档片段，而纯文本检索则因无法解析图像而遗漏重要内容。最终生成质量对比显示，多模态方案在涉及图表、照片和工程图的查询上显著优于纯文本方案。 这一能力为制造业智能化打开了新的大门：工程师可以直接用自然语言描述一个视觉特征，系统就能从海量文档中找到对应的图纸或照片，大幅提升信息获取效率和设计、维修、质检等环节的决策质量。
在 Miro，每年因缺陷误路由和重复分配导致的累计生产力损失高达 42 年。通过与 AWS PACE 团队合作，Miro 开发了基于 Amazon Bedrock 的 BugManager 解决方案，将团队重新分配次数减少六倍，缺陷解决时间从数天缩短至数小时。 ## 挑战：从近 100 个团队中准确路由缺陷 Miro 作为拥有超过 9500 万用户的 AI 创新工作空间，其工程组织包含近 100 个团队，每个团队负责特定产品领域。缺陷报告往往杂乱无章，包含文本、堆栈跟踪、截图甚至视频，且缺乏上下文。此外，团队结构动态变化——合并、新设、产品演进——使得传统基于规则或简单机器学习的方法难以维持高准确率。 ## 解决方案：基于 Amazon Bedrock 的 BugManager Miro 与 AWS PACE 团队合作，利用 **Amazon Bedrock** 构建了 BugManager。该方案通过以下关键步骤实现高精度路由： 1. **增强上下文**：自动从 GitHub PR、Confluence 文档、README 文件和历史工单中提取相关信息，丰富缺陷报告。 2. **多模态理解**：利用 Bedrock 基础模型的能力处理文本、堆栈跟踪、截图等异构数据。 3. **动态适应**：模型能够适应团队重组和职责变化，无需频繁重新训练。 ## 成果：六倍更少的重新分配，五倍更快的解决时间 BugManager 上线后，Miro 团队观察到显著改进： - **团队重新分配次数减少 6 倍**：缺陷首次分配即命中正确团队的比例大幅提升。 - **解决时间缩短 5 倍**：从数天降至数小时，减少了不必要的上下文切换。 - **累计生产力损失**：原本每年 42 年的浪费被大幅削减。 ## 技术架构亮点 BugManager 的架构充分利用了 Amazon Bedrock 的托管基础模型服务，无需管理底层基础设施。核心流程包括： - 缺陷报告进入后，通过 Bedrock API 调用预训练模型进行语义分析。 - 模型输出候选团队及置信度分数，并结合实时组织数据（如团队职责映射）进行最终决策。 - 系统持续从人工纠正中学习，通过反馈循环提升准确率。 Miro 的案例表明，生成式 AI 在 DevOps 领域的应用正从“辅助”走向“核心”。通过将 AI 嵌入缺陷路由这一关键环节，不仅提升了开发效率，更直接改善了产品交付质量和客户满意度。
Amazon Quick 推出五项新能力，帮助数据专业人士大规模交付可信、可复现的AI驱动洞察。其中，**数据集问答（Dataset Q&A）** 允许用户通过自然语言直接查询数百万行数据，系统自动生成SQL并执行，同时遵循行级和列级安全策略，确保结果既快速又合规。这填补了从提问到获得可信答案之间的时间鸿沟，让企业数据真正服务于决策。
哈里伯顿（Halliburton）与 AWS 生成式 AI 创新中心合作，基于 Amazon Bedrock 构建了一款 AI 助手，可将自然语言查询直接转换为可执行的地震数据处理工作流。传统上，配置 Seismic Engine 中的约 100 种专业工具需要深厚的地球物理专业知识，且耗时耗力。新方案通过对话式交互，让地质学家和数据科学家用自然语言描述需求即可生成工作流，同时提供工具文档问答能力。评估显示，工作流创建速度最高可提升 95%。 ## 技术方案与架构 该方案以 **Amazon Bedrock** 为核心，结合 **Bedrock Knowledge Bases**、**Amazon Nova** 模型和 **Amazon DynamoDB** 实现端到端流程： 1. **自然语言理解**：用户输入如“对地震数据进行噪声衰减”后，Amazon Nova 模型解析意图并映射到 Seismic Engine 的 API 参数。 2. **知识库检索**：通过 Bedrock Knowledge Bases 检索内部文档，获取工具配置细节和最佳实践。 3. **工作流生成**：系统自动编排工具链，生成可执行的 JSON 工作流脚本。 4. **问答能力**：用户可就特定工具或参数提问，AI 从文档库中提取答案并解释。 ## 关键成果与行业影响 测试结果显示，该 AI 助手将工作流创建时间从数小时缩短至几分钟，**加速比高达 95%**。哈里伯顿 Landmark 部门地下技术经理 Phillip Norlund 表示：“这次合作将传统耗时的流程构建任务减少了一个数量级，不仅提升了效率和准确性，还让高级地球物理工具对更广泛的用户群体变得触手可及。” ## 可复用的经验 对于希望将生成式 AI 应用于复杂技术工作流的组织，该项目提供了几点启示： - **知识库是基础**：将专业文档和工具 API 结构化为可检索的知识，是 AI 准确理解上下文的关键。 - **模型选择需平衡**：Amazon Nova 在推理速度和专业准确性之间取得了良好平衡，适合实时交互场景。 - **渐进式落地**：从高频、低风险的流程切入，逐步扩展到更复杂的多步骤工作流。 ## 未来展望 随着能源行业对数据处理效率的要求不断提高，AI 辅助工作流将成为标配。哈里伯顿计划将这一能力集成到更多云原生应用中，并探索利用多模态模型直接分析地震图像，进一步缩短勘探周期。
随着 GPU 需求激增，短期 GPU 容量获取成为 ML 工作负载的一大挑战。AWS 推出了 **EC2 Capacity Blocks for ML** 和 **SageMaker 训练计划**，为短期、时间敏感的 ML 任务提供预留 GPU 容量，解决了按需实例和 Spot 实例在可用性上的不确定性。 ## 为什么需要短期 GPU 容量方案？ GPU 供不应求已是行业常态。对于负载测试、模型验证、限时工作坊或发布前准备推理容量等短期任务，传统方案各有短板： - **按需实例**：启动灵活，但容量随区域供需波动，一旦释放实例可能无法立即重新获取，导致用户被迫保持实例运行，增加成本。 - **Spot 实例**：成本可降低 90%，但可用性不确定，不适合不能中断的关键任务。 - **按需容量预留（ODCR）**：适用于长期稳态工作负载，但短期可用性有限，且按需计费无成本优势。 ## 两大新方案：EC2 Capacity Blocks for ML 与 SageMaker 训练计划 ### EC2 Capacity Blocks for ML 该服务允许用户**提前预留 GPU 容量**，以小时为单位购买，最长可预留 14 天。它专为短期、确定性的工作负载设计，例如： - 模型训练和调优 - 推理测试 - 模型评估和验证 - 限时活动或工作坊 用户只需指定所需实例类型、数量、区域和时长，即可锁定容量，避免按需实例的可用性风险。计费按预留时段收取，无需长期承诺。 ### SageMaker 训练计划 对于使用 Amazon SageMaker 进行模型训练的用户，**SageMaker 训练计划**提供了类似的预留能力。用户可创建训练计划，指定训练作业的 GPU 需求和时间窗口，AWS 会确保在指定时段内提供所需容量。这特别适合需要定期或定时执行的训练任务，如夜间训练或批量模型更新。 ## 如何选择？ | 场景 | 推荐方案 | |------|----------| | 短期、不可中断的训练/推理任务 | EC2 Capacity Blocks for ML | | 定期或计划性 SageMaker 训练作业 | SageMaker 训练计划 | | 可容忍延迟的探索性实验 | 按需实例 | | 成本优先、可中断的任务 | Spot 实例 | ## 实际应用案例 一家 AI 初创公司需要在产品发布前对推荐模型进行 48 小时的负载测试。通过 EC2 Capacity Blocks for ML，他们提前一周预留了所需的 p4d.24xlarge 实例，确保测试期间 GPU 容量可用，测试完成后立即释放，避免了按需实例可能遇到的容量不足或额外空闲成本。 另一家金融科技公司使用 SageMaker 训练计划，将每日模型重训练安排在凌晨 2-4 点，利用低峰时段预留 GPU 容量，既保证了训练按时完成，又优化了成本。 ## 总结 短期 GPU 容量管理不再需要“碰运气”。EC2 Capacity Blocks for ML 和 SageMaker 训练计划为时间敏感的工作负载提供了**确定性**和**灵活性**的平衡，帮助企业在 GPU 稀缺的环境下高效运行 ML 工作流。
强化学习（RL）在训练大语言模型时面临一个关键挑战：奖励信号的质量直接影响模型学习效果。传统方法中，不精确或不完整的奖励函数容易导致“奖励黑客”现象——模型找到取巧方式最大化分数，却未真正习得期望行为。为解决这一问题，AWS 在 **SageMaker AI** 上推出了基于可验证奖励的强化学习（RLVR），通过规则化、可客观验证的奖励信号提升训练透明度和效果。 RLVR 的核心在于将奖励建立在可验证的事实基础上，尤其适用于数学推理、代码生成、符号操作等任务。例如，在数学问题中，模型输出的答案可直接与标准答案比对；在代码生成中，可通过运行测试用例验证正确性。这种机制有效避免了传统 RL 中因奖励设计缺陷导致的偏差。 技术层面，RLVR 通常与 **Group Relative Policy Optimization（GRPO）** 结合使用。GRPO 是一种策略优化算法，通过比较同一问题下多个生成样本的相对表现来更新模型，无需依赖独立的奖励模型，从而降低训练复杂性并提高稳定性。此外，**少样本示例** 的引入能进一步引导模型理解任务格式和期望输出，加速收敛。 AWS 官方博客以 **GSM8K** 数据集（小学数学习题集）为例，演示了完整实现流程。读者可以学习如何配置 SageMaker AI 训练环境、定义可验证奖励函数、集成 GRPO 算法，并最终提升模型的数学解题准确率。该方法具备高度可迁移性，同样适用于代码生成、逻辑推理、符号计算等场景。 对于 AI 从业者而言，RLVR+GRPO 的组合提供了一条兼顾效率与可靠性的路径。它不仅减少了人工设计复杂奖励函数的工作量，还通过客观验证机制增强了模型行为的可解释性。随着大模型在专业领域的落地需求增长，这种基于规则验证的强化学习范式有望成为模型对齐与能力提升的重要工具。
亚马逊云科技（AWS）今天宣布推出 **Amazon Bedrock AgentCore Payments** 的预览版，这是一套内置于 AgentCore 中的全新功能，旨在让 AI 代理能够即时访问并支付其所使用的资源。该功能由 AWS 与 **Coinbase** 和 **Stripe** 合作开发，前者提供钱包基础设施，后者提供支付通道。 ### 为什么需要“会花钱”的代理？ 我们正经历软件构建和使用方式的根本性转变。AI 代理已从被动等待指令的助手，进化为能主动调用 API、访问 MCP 服务器、与其他代理协作，并代表用户完成复杂多步骤任务的智能体。随着代理承担的任务日益多样化，其生态圈也在快速扩张。 未来，服务、工具和内容必须同时为人类和代理设计。代理将在单一执行循环中，自主发现、评估并按需支付资源。这就要求支持它们的服务以“每次调用几分之一美分”的方式定价，并实现实时计费。像 x402、ACP、MPP 和 AP2 等早期协议已在探索这一模式，团队也在试验支持支付的代理。然而，支撑这一“代理经济”规模化运转的基础设施尚不存在。 ### 开发者曾经的痛点 对于想要抢占先机的开发者而言，过去的路异常艰难：需要与每个服务提供商建立定制化的计费关系、安全地管理凭证、执行支出治理、应对合规要求，并在碎片化的环境中编写编排逻辑。这往往需要数月的工程投入，且风险极高——一个配置错误的支付流程，不仅会给出错误答案，更可能造成真实的资金损失。 ### AgentCore Payments 如何解决？ AgentCore Payments 并非一个外挂模块，而是原生内置于 AgentCore 中的能力。AgentCore 本身是用于大规模构建、连接和优化代理的平台，其安全机制在基础设施层实施，代理无法绕过。 开发者在 AgentCore 中构建代理时，可以利用相同的身份系统、代理网关和可观测性工具，直接为代理赋予支付能力。这意味着代理可以： - 访问付费的 Web 内容、API 或 MCP 服务器 - 按需购买计算资源或第三方服务 - 与其他付费代理进行协作 Cox Automotive、Thomson Reuters 和 PGA TOUR 等公司已在利用 AgentCore 构建能够推理、规划并在复杂工作流中行动的代理。如今，这些代理也可以进行交易，且所有操作都在统一的安全和治理框架下完成。 ### 行业影响与展望 AgentCore Payments 的推出，标志着 AI 代理从“信息处理”向“价值交换”迈出了关键一步。当代理能够自主完成发现、评估和支付的全流程，一个真正的“代理经济”将加速到来。这不仅会催生新的商业模式（如按调用付费的 API 市场、代理即服务），也将对现有的 SaaS 定价、数字支付和身份管理格局产生深远影响。 目前该功能处于预览阶段，AWS 尚未公布正式上线时间及具体定价。但可以预见，随着更多开发者接入，支付能力将成为智能代理的标配——正如今天的 API 调用一样自然。
Tomofun，这家总部位于台湾的宠物科技初创公司，旗下产品 **Furbo 宠物摄像机** 正在重新定义宠物主人与宠物远程互动的方式。Furbo 将智能摄像头与 AI 结合，能够检测狗狗吠叫、奔跑或异常活动等行为，并实时向主人发出警报。这一能力的核心是计算机视觉和视觉语言模型，它们从视频流中解读宠物的动作。 最初，Furbo 的推理工作负载运行在基于 GPU 的 Amazon EC2 实例上。虽然 GPU 提供了高吞吐量，但由于需要支持大规模实时宠物活动警报的持续推理，成本高昂。为了降低成本并保持准确性，Tomofun 转向了由 **AWS Inferentia2** 驱动的 EC2 Inf2 实例，这是亚马逊自研的 AI 芯片。 ## 挑战：降低大规模实时视觉语言模型的 GPU 推理成本 运行先进的视觉语言模型（如 BLIP）原本托管在 GPU 实例上，但对于需要始终在线、实时推理的大规模工作负载来说，成本效益不佳。挑战有两方面：Tomofun 需要在数十万台设备上持续进行宠物行为监控，同时保持模型保真度和吞吐量，且不能大幅重写已针对 PyTorch 优化的 BLIP 代码库。 ## 解决方案概览 系统通过 AWS 服务实现了大规模宠物行为检测。其架构核心是 **Elastic Load Balancing (ELB)** 和 **Amazon EC2 Auto Scaling 组**，使用 EC2 Inf2 实例，能够随着推理负载的实时增长进行弹性伸缩。当摄像头捕捉到一帧画面时，数据通过 Amazon CloudFront 和 ELB 路由到第一层 Auto Scaling 组（托管宠物行为检测 API 服务器）。API 层处理请求后，将图像转发给第二层 Auto Scaling 组（专用于推理）。 ## 技术实现与优势 Tomofun 利用 AWS Inferentia2 的 **Neuron Core** 架构和 PyTorch Neuron 编译器，将 BLIP 模型转换为高效推理格式。通过 **模型并行** 和 **流水线并行** 技术，将模型分布在多个 Neuron Core 上，显著提升了吞吐量。与 GPU 方案相比，Inf2 实例在保持同等精度的同时，推理成本降低了约 **40-50%**，且延迟满足实时检测需求。 ## 总结 Tomofun 的成功实践表明，对于大规模、始终在线的视觉语言模型推理，AWS Inferentia2 提供了 **高性价比** 的替代方案。通过优化模型部署和利用弹性伸缩，企业可以在不牺牲性能的前提下显著降低运营成本。
全球领先的航运公司 Hapag-Lloyd 正通过生成式 AI 革新其客户反馈分析流程。其数字客户体验与工程团队基于 **Amazon Bedrock**、Elasticsearch 以及 LangChain 和 LangGraph 等开源框架，构建了一套智能反馈分析解决方案，将原本需要数小时甚至数天的手动分析工作压缩至几分钟，并实现了从被动响应到主动洞察的转变。 ## 痛点：手工分析，难以规模化 Hapag-Lloyd 拥有约 14,000 名员工，运营 313 艘集装箱船，服务覆盖 600 多个港口。其数字客户体验与工程团队分布在汉堡和格但斯克，负责面向客户的网页和移动产品。此前，团队每两周进行一次客户反馈分析：产品经理导出 CSV 文件，逐条阅读数百条评分和评论，手动分类情感和主题。这种方式不仅耗时、重复，而且难以扩展，限制了团队对市场变化的快速响应能力。 ## 解决方案：AI 驱动的反馈分析管道 为了解决这一瓶颈，团队构建了一套基于生成式 AI 的自动化分析系统。核心组件包括： - **Amazon Bedrock**：作为基础模型平台，提供高性能的生成式 AI 能力，用于理解客户评论的语义和情感。 - **Elasticsearch**：用于存储和检索海量反馈数据，支持快速查询和聚合。 - **LangChain 与 LangGraph**：开源框架，用于编排 AI 工作流，将多步骤分析任务（如情感分类、主题提取、趋势识别）串联成自动化管道。 该方案实现了端到端的自动化：客户反馈从各渠道流入后，系统自动进行情感分析、主题聚类，并生成可视化摘要和趋势报告。产品经理无需再手动翻阅 CSV 文件，而是可以直接在仪表盘中查看关键洞察，例如“运输延误”相关负面评论增加了 20% 或“新订舱界面”获得积极反馈。 ## 业务价值：从效率提升到战略转型 引入 AI 分析后，Hapag-Lloyd 的反馈分析周期从数天缩短至数小时，且分析深度大幅提升。团队能够更频繁地获取洞察，并更快地将客户声音融入产品迭代。更重要的是，这一项目标志着公司向“AI-native”转型的关键一步——将 AI 作为核心能力嵌入工程实践，从而构建更智能的产品、加速创新并提升客户价值。 这一案例也展示了传统行业如何利用生成式 AI 解决实际业务问题。对于同样面临大量非结构化数据分析挑战的企业而言，Hapag-Lloyd 的实践提供了一个可参考的范式：通过云服务（Amazon Bedrock）降低 AI 门槛，结合开源工具链快速构建定制化解决方案，最终将数据转化为可执行的商业洞察。
Amazon SageMaker AI 今日宣布其 MLflow Apps 现已支持 **MLflow v3.10**，为生成式 AI 工作流带来增强的实验追踪、可观测性和评估能力。本次更新聚焦于生成式 AI 应用与智能体工作流的特殊需求，新增了针对多轮对话的追踪、与主流大模型框架的集成，以及通过 `mlflow.genai.evaluation()` API 实现系统性质量评估。此外，可观测性方面引入了更细粒度的追踪过滤、丰富的元数据捕获和预置性能仪表盘，帮助团队直观监控延迟、质量评分和 Token 用量等指标。结合 SageMaker AI 的企业级基础设施，MLflow v3.10 让数据科学家和 ML 工程师能够更高效地将生成式 AI 从实验推向生产，同时保持治理与可重复性。 ## 新特性亮点 ### 生成式 AI 追踪与集成 MLflow 3.10 显著提升了复杂多轮工作流的追踪能力，与 LangChain、LlamaIndex 等流行 LLM 框架的集成更加紧密，日志记录也针对生成式 AI 交互进行了优化。这意味着开发者可以更清晰地追溯每次推理的完整上下文，便于调试和优化。 ### 系统性评估：`mlflow.genai.evaluation()` 新引入的程序化评估接口支持在开发到生产的全生命周期中，使用内置指标（如**相关性、忠实度、正确性、安全性**）系统衡量生成式 AI 质量。这些指标与 SageMaker AI 工作流无缝集成，为模型迭代提供量化依据。 ### 可观测性升级 - **更精细的追踪过滤与搜索**：快速定位特定请求或异常。 - **丰富的元数据捕获**：辅助根因分析和调试。 - **预置性能仪表盘**：自动展示延迟分布、请求量、质量分数和 Token 用量，无需手动配置图表。 这些改进帮助生产团队一目了然地掌握运营成本与性能状况，而 MLflow 工作空间则支持跨团队和项目组织工件，实现结构化治理。 ## 如何开始 用户可以通过 Amazon SageMaker AI 控制台直接启用支持 MLflow 3.10 的 MLflow Apps，现有工作流可平滑升级。具体步骤可参考 AWS 官方文档。 ## 行业意义 随着生成式 AI 应用进入生产化阶段，实验管理、可观测性和评估成为关键瓶颈。MLflow 3.10 在 SageMaker AI 上的落地，意味着开发者可以在一个统一平台上完成从实验追踪、模型评估到生产监控的全流程，无需切换工具。此举进一步降低了生成式 AI 开发的门槛，尤其适合需要快速迭代和严格治理的企业场景。
亚马逊云科技宣布为 **AgentCore Browser** 引入 **操作系统级操作（OS Level Actions）** 能力。这一新特性通过 `InvokeBrowser API` 暴露直接的操作系统控制，使 AI 代理不仅能与浏览器网页层（DOM）交互，还能操控屏幕上由操作系统渲染的界面元素——包括原生对话框、安全提示、证书选择器、右键菜单、Chrome 设置等。 传统网页自动化工具（如 Playwright、Chrome DevTools Protocol）受限于浏览器 DOM，无法触及操作系统层级的 UI。当应用调用 `window.print()` 弹出系统打印对话框、或遇到 macOS 隐私弹窗、Windows 安全提示时，自动化流程就会中断。对于视觉 AI 代理，问题更突出：截图能捕获原生 UI，模型也能推理出操作意图，但后续执行却无路可走。 OS Level Actions 通过组合 **全桌面截图** 与 **鼠标/键盘操作系统级控制**，让代理在同一个会话中观察、推理并操作原生界面。该能力无需额外配置即可用于现有浏览器环境，支持鼠标点击、键盘输入、快捷键、滚动、拖放等操作。 这一更新对需要处理复杂认证流程、文件上传下载、浏览器设置变更或跨应用交互的自动化场景意义重大。它弥补了网页自动化与系统级操作之间的鸿沟，为构建更鲁棒的企业级 AI 代理铺平道路。开发者现在可以通过 Amazon Bedrock 的 AgentCore 服务体验这一能力。
AI 代理在生产环境中需要安全地访问外部服务。Amazon Bedrock AgentCore Identity 作为一项独立服务，无论代理运行在 Amazon ECS、Amazon EKS、AWS Lambda 还是本地环境，都能为其提供安全保障。本文聚焦于在 Amazon ECS 上实现授权码授权（三腿 OAuth），包括安全的会话绑定和作用域令牌管理。 ## 核心挑战 当 AI 代理运行在 ECS 等计算环境中时，面临两个关键问题： 1. 如何构建应用自有的会话绑定端点？ 2. 如何管理工作负载的访问令牌生命周期？ ## 解决方案概览 该方案基于 **OAuth 2.0**（RFC 6749）和 **OpenID Connect（OIDC）**。OIDC 负责用户身份认证（用户是谁），OAuth 2.0 则授权用户操作（用户能做什么）。重点在于**授权码授权**，用于用户委派访问。 流程如下： - 用户通过身份提供者（IdP）认证并授予同意。 - 应用将授权码交换为作用域访问令牌。 - Amazon Bedrock AgentCore Identity 将令牌安全存储在令牌库中。 由于每个令牌都绑定到特定用户身份并附带明确同意，该方案维护了一条从用户认证到代理操作的可审计链条。 ## 关键特性 - **安全会话绑定**：防止 CSRF 和浏览器交换攻击。 - **作用域令牌**：每个用户会话的令牌遵循最小权限原则。 - **关注点分离**：代理工作负载与会话绑定服务职责清晰。 - **认证与授权**：结合 OAuth 2.0 和 OIDC 实现。 ## 回调 URL vs 会话绑定 URL 在授权码授权流程中，两个 URL 容易混淆： - **回调 URL**：创建 OAuth 客户端时自动生成。 - **会话绑定 URL**：由应用自定义实现，用于绑定用户会话。 ## 适用场景 授权码授权特别适合**代表用户行动的代理工作负载**，原因如下： - 代理行动前需获得用户同意。 - 会话绑定确保发起授权请求的用户与同意授权的用户一致。 - 作用域委派限制代理仅能使用用户批准的权限。 该实现已在 ECS 上完成验证，提供了完整的代码示例和部署指南，帮助开发者快速构建安全的 AI 代理基础设施。
在当今数字化商业环境中，企业每天处理海量用户消息，其中既包含有价值的客户反馈，也潜藏着恶意接触、诈骗甚至品牌攻击。如何在不影响正常客户沟通的前提下，精准识别风险并提取业务洞察，成为一项关键挑战。本文介绍如何借助 **Amazon Bedrock** 上的 **Amazon Nova 基础模型**，构建一套智能消息防御与洞察系统，实现“一箭双雕”：既保护业务安全，又提升客户体验。 ## 核心能力：识别伪装接触与挖掘客户情绪 传统的消息过滤方案通常依赖规则引擎或关键词匹配，面对日益复杂的伪装手段（如变体拼写、语义隐藏、上下文诱导）往往力不从心。而生成式 AI 模型，尤其是 Amazon Nova 系列，具备强大的自然语言理解能力，能够从语义层面识别恶意意图。 通过将用户消息输入 Amazon Bedrock，调用 Nova 模型进行 **意图分类** 和 **情感分析**，系统可以： - **识别直接或伪装的恶意接触**：例如，诈骗者可能使用“客服转接”“账户验证”等看似正常的词汇，但模型能根据上下文判断其真实目的。 - **提取客户真实情感**：在排除恶意消息后，对正常客户消息进行情感打分，识别不满、困惑或赞扬，为服务改进提供数据支撑。 - **发现服务改进机会**：高频出现的投诉关键词、功能请求等，可自动汇总为洞察报告，指导产品迭代。 ## 技术实现：无服务器架构与模型编排 该方案基于 Amazon Bedrock 的无服务器体验，无需自行管理基础设施。开发者只需通过 API 调用 Nova 模型，即可将消息处理流程嵌入现有业务系统。典型架构包括： 1. **消息接入层**：通过 API Gateway 或 SQS 接收用户消息。 2. **智能分析层**：使用 Amazon Bedrock 调用 Nova 模型，进行意图识别与情感分析。 3. **决策与存储层**：根据分析结果，将恶意消息隔离或标记，将正常消息存入数据库供后续分析。 4. **洞察输出层**：通过 QuickSight 或自定义仪表盘，可视化展示客户情感趋势、风险分布等。 Amazon Nova 模型在成本和响应速度上经过优化，适合实时或近实时的消息处理场景。企业还可以结合 **Amazon Bedrock 知识库**，注入行业术语或历史案例，提升模型对特定领域伪装手法的识别准确率。 ## 案例场景：从电商客服到金融风控 该方案的应用范围广泛： - **电商平台**：识别“退款钓鱼”消息，同时收集用户对物流、商品的真实反馈。 - **金融机构**：检测冒充客服的诈骗短信，并分析客户对理财产品的情绪倾向。 - **社交平台**：过滤垃圾信息和恶意链接，同时发现用户对功能更新的普遍态度。 ## 小结：AI 驱动的双向价值 利用 Amazon Bedrock 和 Amazon Nova 模型，企业不再需要在“安全”与“体验”之间做取舍。同一套 AI 能力既能构筑消息防御的护城河，又能打开客户洞察的窗口。这种“防御+洞察”的双重价值，正是生成式 AI 在业务落地中的典型体现——它不只是工具，更是重塑客户关系管理的战略支点。