## 从单次调用到整体行为：AgentCore 的治理升级 随着 AI 智能体（Agent）自主性增强，企业部署规模扩大，信任与安全成为规模化落地的关键瓶颈。麦肯锡报告指出，约 **80% 的组织已遭遇智能体风险行为**，安全与风险顾虑是扩展智能体 AI 的首要障碍。传统防护机制多针对可预测的软件行为设计，而智能体自主决策路径，导致“单步合法、整体失控”的困境：例如，智能体查询客户账户后转移资金，或连续下多个低于审批阈值的订单，或对失败工具无限重试耗尽预算。 针对这一挑战，**Amazon Bedrock AgentCore** 推出新能力，将安全控制下沉至基础设施层，实现跨智能体的一致治理。新功能包括： - **基于 Dogwood 的时序策略（Temporal Policies）**：Dogwood 是专为 AI 智能体设计的开源策略语言，支持定义动作序列的约束规则，例如“禁止在未授权情况下连续执行转账”或“订单总额不得超过预算”，从而在整体行为层面实施控制。 - **网关速率限制（Rate Limiting）**：AgentCore 网关作为全托管、无服务器的 AI 流量入口，统一路由至 MCP 服务器、LLM、智能体及知识库。通过网关施加速率限制，可设定成本上限，无论智能体如何行为，都能确保消费不超预算。 这些能力让企业获得确定性的控制力：不仅管控单个动作，还能约束动作序列和整体成本。AgentCore 的核心理念是：**安全控制应内置在基础设施层**，而非依赖各团队的应用代码实现，从而避免实现差异和漏洞。 ## 为什么这很重要？ 智能体应用正从实验走向生产，但信任问题阻碍了规模化。当防护机制可靠时，审批新智能体不再是逐案谈判，而成为平台层面的标准化流程。AgentCore 的更新将治理能力前置，使企业能够放心部署更多自主智能体，同时保持预算和安全底线。 对于开发者而言，这意味着无需自行构建复杂的策略引擎或限流系统，即可获得企业级控制。未来，随着智能体承担更关键任务，这类基础设施级的安全能力将成为标配。 **小结**：AgentCore 的新功能直击智能体治理痛点，通过时序策略和网关限流，为自主行为提供确定性约束，是迈向可信赖 AI 的重要一步。
随着工程团队从尝试编码代理（如 Codex）转向全面采用，领导者关注的焦点从“这个工具能否帮助开发者？”转变为“我们如何理解采用情况、管理消耗、维护可靠性并负责任地扩展访问？”。Codex 能够输出关于其活动的 OpenTelemetry（OTel）指标。当本地 Codex 客户端通过 Amazon Bedrock 使用 OpenAI 模型，并使用 AWS IAM Identity Center 进行身份验证时，你可以通过本地 OTel 收集器将这些指标路由到 Amazon CloudWatch，从而获得按用户、团队、部门、组织或成本中心组织的 AWS 原生视图。这种方法不会在模型请求路径中引入集中式代理。开发者继续在本地使用 Codex，每个开发者工作站上运行的收集器接收本地主机上的指标，并为其补充组织上下文，然后使用 AWS 签名版本 4（SigV4）将其发送到区域 CloudWatch OpenTelemetry 协议（OTLP）端点。参考部署创建了 CloudWatch 仪表板，而不是 Amazon ECS 服务、负载均衡器、VPC 或公共摄取端点。本文解释了这种模式如何支持受治理的采用，审查其架构，并总结了 Codex on AWS 指南仓库中的实现。 ## 将遥测转化为业务决策 遥测只有在回答决策问题时才最有用，而不仅仅是生成另一个仪表板。捆绑的 CodexOnBedrock 仪表板包含活跃用户数、对话轮次、API 请求数和令牌使用量的滚动 24 小时总计。它还提供按模型、令牌类型、用户、部门、团队、成本中心、组织和会话来源的视图。这些信号可以帮助技术领导者区分广泛采用与孤立实验。例如，活跃用户数在多个团队中的增加表明需要不同的赋能支持，而消耗集中在少数用户则提示不同的关注点。工具调用活动可以帮助团队了解代理工作流在哪些地方扎根。请求和持续时间指标可以支持对体验降级的调查。 | 高管问题 | 可用信号 | 可辅助的决策 | |---------|--------|------------| | Codex 采用是否在扩大？ | 活跃用户、线程、轮次和 API 请求 | 是否扩大试点或专注于入职培训 | ## 架构概览 该架构的关键在于本地收集器。每个开发者的工作站上运行一个 OTel 收集器，它从本地 Codex 客户端接收指标，并添加组织属性（如用户、团队、成本中心），然后通过 SigV4 认证发送到 CloudWatch。这种设计避免了集中式代理，保持开发者的本地体验不变，同时提供集中的可见性。 ## 实施要点 参考实现位于 Codex on AWS 指南仓库中。它提供了 CloudFormation 模板和配置，用于设置仪表板、IAM 角色和本地收集器配置。实施步骤包括： 1. 配置 Codex 以使用 Bedrock 作为模型提供方，并设置 IAM Identity Center 认证。 2. 在开发者工作站上安装并配置 OTel 收集器，指定 CloudWatch OTLP 端点。 3. 部署 CloudFormation 模板以创建仪表板和必要的 IAM 权限。 4. 验证指标是否正确到达 CloudWatch。 这种模式使组织能够以 AWS 原生的方式监控编码代理的使用，同时保持开发者的工作流程不变。对于希望负责任地扩展 AI 编码工具的企业，这是一个实用的解决方案。
**数据驻留需求** 一家总部位于美国的全球性组织最近向 AWS 提出了一个看似简单的数据驻留请求：让他们的工程师使用 Claude Code，但要求所有 Amazon Bedrock 模型推理必须在伦敦（eu-west-2 区域）处理，而不仅仅是调用。合规团队划出了一条硬性红线：提示词、补全内容和中间处理过程必须留在单个 AWS 区域内，近似合规不可接受。 **两种实现路径** AWS 团队首先尝试了最新路径——Anthropic 的 Mantle 端点，但遇到了限制。随后，他们采用了经典的 Amazon Bedrock Invoke API 配合应用程序推理配置文件，并结合 IAM 区域条件，最终满足了要求。本文介绍了这两种路径： - **路径 1：Mantle 端点**——需要 Claude Code v2.1.94 或更高版本，使用 `bedrock-mantle:CreateInference` 等权限。 - **路径 2：经典 Invoke API**——使用 `bedrock:CreateInferenceProfile` 和 `bedrock:InvokeModel` 权限。 **关键考虑** 对于大多数 Amazon Bedrock 工作负载，跨区域推理（CRIS）是默认推荐，因为它能平滑吞吐量、增加可用容量并优先提供新模型。但若合规要求是特定区域而非地理区域，则应使用单区域模式。如果“在欧盟境内”即可满足需求，使用欧盟跨区域配置文件更为直接。 **验证合规性** 部署后，可通过 AWS CloudTrail 验证推理是否确实在指定区域进行，确保所有 API 调用记录都指向 eu-west-2。 **总结** 该模式适用于目标为 Amazon Bedrock 模型 ID 的工具。选择哪种路径取决于你的区域可用性：Mantle 端点目前可能不支持所有区域，而经典路径则广泛可用。无论选择哪种，IAM 区域条件都是强制约束，确保仅允许在指定区域调用模型。
采用 Amazon Bedrock 自动化推理检查的团队，往往希望将策略生命周期管理迁移到代码中。这样做不仅能确保工作流程的可重复性和可审查性，还能与团队现有的编码智能体无缝集成。然而，编写高质量的自动化推理策略并非易事，其生命周期中的诸多约束常让人困扰。策略规则需使用 SMT-LIB 的子集编写，并需精细调整变量描述，以确保服务能准确理解用户的自然语言。此外，策略还需经历构建、测试和优化的迭代循环，每一步都涉及特定的 API 和约束。 自动化推理检查的价值在于，它通过形式逻辑验证 AI 输出，而非依赖统计抽样，从而提供数学上的确定性，确保 AI 响应符合既定规则。在上一篇文章中，我们介绍了如何在 Amazon Bedrock 控制台中执行此循环，控制台是入门和与领域专家协作的理想起点。而本文则聚焦于如何利用一套 Agent Skills，从编码智能体端到端地构建、测试、部署和验证自动化推理策略，并分享运行过程中对服务行为的观察。 **什么是 Agent Skills？** Agent Skills 是 Anthropic 推出的轻量级开放格式，旨在为编码智能体扩展专业知识和流程。每个技能包含经过验证的模式、常见错误规避指南和分步工作流，使智能体不再依赖可能过时或不完整的通用训练数据。由于格式开放，技能可安装到任何支持该格式的智能体中，如 Kiro、Claude Code、Cursor 和 Codex，并在相关任务出现时自动激活。 **为何智能体适合自动化推理生命周期？** 自动化推理检查分两步运行：首先，一组基础模型将问题和答案转换为形式逻辑，将自然语言映射到策略变量；随后，SMT 求解器（可满足性模理论求解器）验证这些逻辑。理解这一分离是有效使用该服务的关键。Agent Skills 能够指导智能体正确调用服务，避免常见错误，从而显著提高开发效率。 **实践中的发现** 在运行该技能套件时，我们观察到 Amazon Bedrock 服务的一些行为特点。例如，策略的变量描述对翻译质量影响显著，细致的描述能大幅提升准确率。此外，测试阶段需注意边界情况，确保策略在极端输入下也能正确执行。这些经验已整理到技能中，帮助用户规避潜在陷阱。 通过将控制台任务转化为可重复的工程工作流，Agent Skills 不仅降低了自动化推理策略的入门门槛，还让团队能够更高效地维护和迭代策略，最终构建更可靠的 AI 系统。
在大型企业中，总有一长串永远无法排期开发的小工具需求：一个运费计算器、一个简单的表单、一个基于电子表格的小型仪表盘。这些需求太小，不值得占用开发资源，但又太多，无法忽视。PDI Technologies 为便利店零售和石油批发行业提供服务，拥有 40 年经验，约 4000 名员工，服务覆盖 200 多个国家和地区的超过 20 万个客户地点。PDI 意识到传统的部署流程阻碍了非技术团队快速交付所需工具，因此构建了 **PDI Brew**——一个智能体平台，让非技术员工用自然语言描述需求，几秒钟内即可获得一个完全配置好的多租户 Web 应用，支持单点登录（SSO），运行在 AWS 上，全程无需 Git、终端或 DevOps 知识。 ## 核心架构：规划器与执行器分离 PDI Brew 的核心是一个 **智能体式部署模式**，分为两个关键部分： - **规划智能体**：在 AI 助手（如 Claude、ChatGPT 或 Claude Code）中通过技能捕获用户意图，生成结构化的清单（manifest），或者作为 AWS 信任边界内的 Amazon Bedrock 模型调用。 - **执行智能体**：运行在 AWS Lambda 上，负责解析清单，对工作负载进行分类，选择工具，并协调创建所有下游 AWS 资源。 这种分离设计使得意图捕获与资源部署解耦，既灵活又安全。 ## 安全与治理：最小权限与预算控制 每个生成的应用程序都继承相同的平台安全基线，并可以选择启用由 Amazon Bedrock 支持的治理 AI 能力（如聊天、摘要、分类），而无需作者接触模型端点或 API 密钥。平台通过 **最小权限原则** 设计 AI 网关，确保每个应用只能访问其所需的模型和数据。同时，系统内置了 **AI 护栏与预算管理**，防止超支和滥用。 ## 长期运行步骤与成本考量 在 AWS Lambda 中处理长时间运行的部署任务是一大挑战。PDI 采用了异步任务编排，将部署过程分解为多个步骤，并通过状态机或队列进行管理，确保 Lambda 函数的执行时间限制被有效规避。在成本方面，PDI Brew 利用按需付费的 AWS 服务，使得每个内部工具的边际成本极低，同时通过多租户架构共享基础设施，进一步优化了成本。 ## 价值与启示 PDI Brew 展示了 **智能体如何将企业内部的“长尾工具”开发民主化**。它让业务人员直接成为工具的创造者，大幅缩短了从需求到交付的周期。对于其他企业而言，这一模式提供了可复用的参考架构：结合 Bedrock 的自然语言理解能力和 Lambda 的无服务器计算，可以构建安全、可治理的内部工具平台。 随着 AI 智能体技术的成熟，类似 PDI Brew 的系统有望成为企业数字化转型的标配，打破 IT 资源瓶颈，释放业务团队的创造力。
**亚马逊云科技近日宣布，Amazon SageMaker Python SDK v3 现已集成生成式 AI 推理推荐功能，用户可以直接在 Notebook 中完成端点基准测试、部署推荐生成和配置部署，无需切换工具。** 这一更新将原本需要 SageMaker Studio 或 Boto3 API 的复杂流程简化为 SDK 操作，大幅提升了开发效率。 ## 核心功能与优势 生成式 AI 推理推荐功能通过以下方式自动化优化推理部署： - **基准测试**：对实时端点施加合成或真实流量负载，测量吞吐量、首 token 延迟（TTFT）和端到端延迟等关键指标。 - **推荐生成**：基于实际使用模式，按成本性能权衡生成排序的部署建议。 - **一键部署**：直接将排名最高的配置部署到 SageMaker 实时端点。 此前，这些操作需要依赖 SageMaker Studio 或手动构造 Boto3 API 调用，现在已成为 SDK 原生操作，自然融入现有的 Notebook 和管道工作流。 ## 新增 SDK 接口 新功能位于 `sagemaker.serve.ai_inference_recommender` 包中，自 **SDK v3.17.0** 起可用，主要操作包括： - `ModelBuilder.from_jumpstart_config(...)`：从 JumpStart 模型 ID 和计算配置构建 ModelBuilder。 - `start_benchmark(endpoint, ...)`：使用可配置的合成工作负载对已部署端点执行负载测试。 - `generate_deployment_recommendations(...)`：根据工作负载探索实例和框架配置，返回排序推荐。 - `deploy(...)`：将最佳推荐部署到实时端点。 - `ModelBuilder.from_recommendation_job(job_name)`：从已完成的推荐作业中恢复 ModelBuilder，支持跨会话部署。 ## 快速上手 要使用这些功能，只需升级 SDK 到最新版本： ```bash pip install --upgrade sagemaker ``` 然后按照官方文档中的示例，即可在 Notebook 中完成从基准测试到部署的完整流程。 ## 行业意义 随着生成式 AI 应用日益普及，推理部署的成本和性能优化成为关键挑战。此次更新将优化过程从复杂的 API 调用简化为直观的 SDK 操作，降低了技术门槛，有助于企业更快地迭代和部署 LLM 服务。同时，与 JumpStart 的集成使得模型部署和调优更加一体化，预计将加速 AI 应用在生产环境的落地。 对于数据科学家和 ML 工程师而言，这意味着更高效的实验循环和更快的生产部署，是 SageMaker 生态在生成式 AI 时代的一次重要升级。
LendingTree 利用 Amazon Bedrock 构建了一个生产级多智能体抵押贷款助手，通过三个协同工作的智能体，结合 LangGraph、模型上下文协议（MCP）和 Amazon Nova 模型，提供全天候个性化抵押贷款指导，同时满足严格的金融服务合规要求。 ## 背景与挑战 作为在线贷款市场，LendingTree 面临着用户咨询量大、需求个性化强的挑战。传统的单一模型难以同时处理复杂的贷款流程、产品比较和合规要求。因此，他们转向多智能体架构，以提高响应速度和准确性。 ## 多智能体架构 该助手由三个智能体组成，每个智能体负责不同的任务： - **贷款产品智能体**：负责解释贷款类型、利率和条款，帮助用户理解不同选项。 - **资格评估智能体**：根据用户输入（如信用评分、收入）评估贷款资格。 - **合规智能体**：确保所有对话内容符合金融法规，避免不当建议。 这些智能体通过 LangGraph 进行协调，使用模型上下文协议（MCP）进行通信，确保信息流畅传递。 ## 技术实现 - **基础模型**：使用 Amazon Nova 模型，该模型在自然语言理解和生成方面表现出色，且支持微调以适应金融领域。 - **内置防护栏**：利用 Amazon Bedrock 的 Guardrails 功能，实时过滤敏感信息，确保合规。 - **工作流管理**：LangGraph 允许定义复杂的对话流程，支持条件分支和状态管理。 ## 效果与启示 该助手已投入生产，显著提升了客户服务效率，减少了人工客服压力。LendingTree 的技术团队强调，多智能体架构的灵活性使得他们能够快速迭代，适应不断变化的贷款产品线和监管要求。 此案例展示了云服务与开源工具结合的可能性，为金融行业构建合规的 AI 助手提供了参考。
**Mobileye**，这家拥有超过2.3亿颗EyeQ芯片、部署于全球约1200款车型的自动驾驶先驱，正面临一个典型的规模化难题：随着数据采集管道每天处理数千个驾驶记录会话，工程师和数据团队产生了大量关于内部工单状态的查询，这些查询曾需要手动跨多个系统操作才能回复，严重拖累了效率。 如今，Mobileye利用**Amazon Bedrock AgentCore**部署了一个AI支持代理，将响应时间缩短了**90%**，准确率超过**95%**，且无需管理任何基础设施。这一成功不仅解决了眼前的瓶颈，还促使Mobileye将AgentCore转化为公司内部的自助服务平台，让各团队都能部署自己的AI代理。 ## 从手动瓶颈到AI驱动的支持 在Mobileye的数据采集管道扩展过程中，**66%**的支持工单变成了常规状态查询，工程师需要手动在多个后端系统间进行多达**15次点击**才能完成回复。这不仅耗时，还让熟练工程师无法专注于复杂问题。传统的自动化方法，如脚本、静态工作流和基于规则的决策树，虽然能处理可预测的查询，但缺乏理解真实世界请求多变性的上下文能力。因此，Mobileye决定构建一个能理解上下文并适应多样化查询模式的AI代理。 ## 验证方法：概念验证 在全面生产部署之前，Mobileye团队进行了概念验证（PoC），以验证AI代理的可行性和效果。PoC的成功为后续的架构设计提供了信心。 ## 混合架构：桥接本地与云 Mobileye的解决方案采用混合架构，将本地系统与AWS云服务无缝连接。AgentCore作为核心，提供了企业级的可观测性和治理能力，同时支持与现有本地系统的集成。这种架构让Mobileye无需管理底层基础设施，即可实现生产级AI代理的部署。 ## 对企业的启示 Mobileye的实践表明，借助AgentCore，企业可以在保持企业级治理和安全标准的同时，快速扩展AI代理。这一案例对于那些在扩展AI代理时面临基础设施管理、可观测性挑战的企业，具有重要的参考价值。
在AI应用开发中，一个常见挑战是云端运行的AI代理如何访问用户本地环境中的工具和数据。亚马逊云科技（AWS）团队通过构建一个基于Model Context Protocol（MCP）的桥梁解决了这一难题，使得部署在Amazon Bedrock AgentCore上的AI代理能够安全地调用用户笔记本上的本地MCP服务器。 该方案的核心是一个四部分架构：AgentCore运行时（作为MCP客户端）、浏览器扩展（提供聊天界面并双向转发消息）、MCP Bridge（本地组件，通过Chrome原生消息与浏览器扩展通信）以及本地MCP服务器。消息通过现有的WebSocket连接进行隧道传输，无需开放端口或VPN，从而保证了安全性。 作者在文中详细解释了MCP协议（由Anthropic于2024年11月推出的开源标准）及其两种传输机制：stdio（用于本地进程间通信）和流式HTTP（用于远程通信）。而该方案填补了MCP服务器在本地、客户端在云端的空白。 这一模式对金融分析师等重度依赖Excel和本地文件的用户尤为重要，他们可以使用集中部署的AI代理处理本地文件，同时从浏览器获取上下文。AWS内部已将该方案应用于生产环境，其财务AI助手在一年内处理了超过41,000次对话。 本文以简化形式重现了内部实现，并提供了完整的源代码（GitHub）。文章最后还讨论了生产环境下的进一步加固措施，为开发者提供了实用参考。 这种云-本地桥接模式展示了MCP的灵活性和扩展潜力，为AI代理的落地应用开辟了新的路径。
Amazon Bedrock AgentCore harness 现已全面可用，并推出新的开源社区节点，将其集成到 n8n 可视化编辑器中。该节点允许用户在 n8n 工作流中直接构建具有持久记忆、真实工具、代码执行和 VPC 隔离的生产级 AI 代理，无需编写基础设施或代理代码。本文介绍如何安装和使用该节点，从记忆对话到添加代码解释器、赋予技能，再到私有 VPC 中运行，逐步构建代理。该节点基于 MIT 许可证开源，并由 AWS 的开源代理框架 Strands Agents 提供支持。
**亚马逊云科技在纽约峰会上宣布，Amazon Bedrock 的 Web Search 功能正式全面可用（GA）**，这是继 AgentCore 之后，将网页搜索能力直接集成到模型推理服务中的又一重要举措。该功能作为服务端内置工具，使基础模型能够基于最新的网络信息进行回答，无需再依赖第三方搜索服务，从而简化了开发流程并降低了运维成本。 ## 解决模型知识时效性的痛点 基础模型虽然强大，但其知识仅限于训练数据，无法回答关于上周财报、昨天法规变更或今早天气预报等问题。传统上，开发者需要自行集成第三方搜索 API，这不仅延长了项目周期，还引入了数据驻留和安全隐患。Web Search on Amazon Bedrock 将这一能力原生内置，开发者无需额外对接外部服务，也无需进行额外的安全审查。 ## 核心特性：多源接地与上下文高效检索 该功能具备两大差异化优势： - **多源接地**：依托亚马逊自营的网页索引，覆盖数十亿文档并持续更新，同时结合内置的知识图谱。当面对事实性问题（如某本书的作者或某事件发生的年份）时，知识图谱能直接提供高置信度答案，减少模型从碎片文本中推断时产生的小错误。 - **上下文高效检索**：采用语义片段提取技术，从网页中精准抽取与查询相关的段落，并以模型优化的形式返回，避免将整页内容交给模型处理，提高了信息利用效率。 ## 启用方式与开放生态 开发者可通过 OpenAI Responses API 轻松启用该功能，这意味着无论是构建聊天机器人、编码助手、CLI 工具还是企业应用，都能快速获得实时知识支持。亚马逊云科技强调，这一能力将有助于减少模型幻觉，提升回答的准确性和可靠性。 ## 行业影响与展望 Web Search 的全面可用标志着模型接地技术从“附加组件”走向“平台原生能力”，降低了企业采用生成式 AI 的门槛。随着更多组织将基础模型应用于动态知识场景，这一功能有望成为标准配置。未来，我们或许会看到更多云端 AI 服务将类似能力内置，推动行业向更高效、更安全的智能应用演进。
手动从数十个网站提取洞察信息往往令人应接不暇。设计团队需要跟踪竞争对手产品，营销团队希望监控内容趋势，产品经理则需掌握市场情报。但人工操作意味着必须有人访问网站、复制内容并整理信息，之后才能开始真正的分析。基于规则的爬虫虽能提供一定自动化，但其与页面结构紧密耦合，一旦网站改版或迁移至 JavaScript 渲染前端，管道可能悄然中断数日而无人察觉。 Amazon Bedrock AgentCore 是一个用于大规模构建、连接和优化智能体的平台，支持任意框架或模型。本文介绍的解决方案利用了 AgentCore 浏览器（Amazon Bedrock AgentCore 的一项能力），该全托管浏览器服务能够可靠渲染 JavaScript 密集型页面，从而增强管道对网站变化的韧性。 ## 架构与核心组件 该解决方案结合了以下 AWS 服务： - **Amazon Bedrock AgentCore Browser**：负责检索网页内容，可靠渲染动态页面。 - **Amazon Bedrock**：用于 AI 驱动的分析，提取关键洞察。 - **Amazon OpenSearch Serverless**：提供向量嵌入与语义搜索能力。 - **AWS Lambda**：负责编排整个工作流。 系统通过监控 RSS 源，利用 AgentCore 托管浏览器获取网页内容，借助 AI 提取洞察，并通过 Web 界面实现全内容可搜索。 ## 适用场景 该架构不仅适用于设计或产品团队，还可扩展至更广泛的场景： - **竞争情报**：跟踪竞争对手博客、产品公告和新闻稿，AI 可识别新功能、定价变化或战略调整。 - **市场研究**：监控行业新闻、分析师报告和贸易出版物，搜索新兴趋势或相关技术。 - **内容策展**：聚合多源内容，由 AI 筛选出对受众最相关的部分。 - **合规监控**：关注监管网站和新闻源，及时获取可能影响业务的变更。 ## 事件驱动设计的优势 本方案采用事件驱动架构，将内容收集与 AI 处理解耦。这种设计带来以下好处： - **高韧性**：浏览器自动化服务确保 JavaScript 密集型页面可靠渲染，降低因网站改版导致的管道中断风险。 - **可扩展性**：各组件独立扩展，适应数据量增长。 - **成本优化**：按需调用 Lambda 和 OpenSearch Serverless，避免闲置资源浪费。 ## 总结 通过 Amazon Bedrock AgentCore Browser 与 Bedrock 的 AI 能力相结合，团队可以构建一个自动化、可搜索的洞察提取管道，大幅减少人工监控成本，并提升对网站变化的适应能力。该方案尤其适合需要持续追踪行业动态的团队，助力快速响应市场变化。
Formula 1®（F1）与AWS合作，利用Amazon Bedrock AgentCore上的智能体AI构建了Data Accelerator，将其MarTech数据平台从手动维护转变为自我管理、可观测且统一的数据资产。该方案将数据源接入时间从最多8周缩短至约40分钟的代码生成加数小时部署，实现了架构自动演进，并为整个粉丝互动数据资产提供了端到端的可观测性。 ## 背景：数据增长与工程瓶颈 F1在全球拥有超过8亿粉丝，通过数字平台、F1 TV、社交媒体、票务和商品等渠道全年互动。比赛每两周举行一次，粉丝互动窗口以分钟计算，商业决策需以赛道速度推进。F1的MarTech平台Customer 360捕捉所有触点的互动，以支持个性化、细分和商业策略。然而，该平台面临重大运营挑战：每个新数据源需要6至8周的手动工程时间，导致18个月的积压，仅整合12个新源就需如此。业务数据产生速度远超工程团队整合速度，造成数据质量问题。 ## 解决方案：Data Accelerator 为应对挑战，F1数据运营主管Matt Kemp寻求可重复、稳健且可靠的解决方案。F1与AWS合作，在2026年初构建了Data Accelerator，利用Amazon Bedrock AgentCore上的智能体AI，将MarTech数据平台转变为自我管理、可观测且统一的数据资产。该方案显著提升了效率： - **数据源接入时间**：从最多8周缩短至约40分钟代码生成加数小时部署。 - **架构自动演进**：自动处理数据源变更，减少手动干预。 - **端到端可观测性**：在单一窗口中追踪数据平台操作和智能体血缘，支持根因分析。 ## 价值与展望 Data Accelerator不仅解决了数据集成瓶颈，还为分析师、工程师和科学家打开了协作大门。F1 IT总监Chris Roberts表示：“我们首次在整个MarTech平台实现了端到端可见性，包括数据血缘和根因分析，而不仅仅是充满警报的仪表板。”这一创新展示了智能体AI在复杂数据运营中的潜力，为其他行业提供了借鉴。
在 AI 安全领域，确保模型输出符合预期是一个持续挑战。今天，亚马逊云科技宣布在 Amazon Bedrock 中推出 **Automated Reasoning 策略的自动细化功能**，旨在简化安全策略的调试流程。此前，开发者需要手动进行诊断、编辑、重测的循环，这一过程繁琐且耗时。现在，新的细化引擎可以自动诊断失败的测试，并提出基于形式逻辑的修复建议，但所有变更都需要人工批准后才会生效。 Automated Reasoning 检查是 Amazon Bedrock Guardrails 的一部分，它通过形式验证来证明答案的正确性。在从自然语言到形式逻辑的明确转换中，其验证准确率据称可达 **99%**（根据 GA 公告）。其工作流程包括两步：首先，将自然语言输入/输出转换为变量；然后，将策略中的形式规则应用于这些变量。当测试失败时，根本原因通常出在这两个步骤之一，而新的细化模式正是针对这些不同环节设计的。 此次发布引入了两种细化模式： - **迭代细化（Iterative Refinement）**：针对规则问题，自动调整形式逻辑规则。 - **模糊变量细化（Ambiguous Variable Refinement）**：针对语言问题，解决变量描述或翻译中的歧义。 该功能提供了完整的 API 工作流，支持启动、轮询和检索结果，同时也在控制台中提供了可重复的操作流程，帮助用户将失败的策略转化为通过的策略。 这一更新显著降低了策略调优的技术门槛，使得开发者可以更高效地构建和验证 AI 应用的安全边界。值得注意的是，虽然自动细化能够提出修复建议，但最终的控制权仍掌握在开发者手中，每一次修改都需要人工确认，这确保了安全策略的变更始终是审慎和可追溯的。对于依赖 AI 生成内容的企业而言，这无疑是一个提升安全性和合规性的重要工具。
Amazon Quick 近日宣布推出 **Agentic Catalog Experience** 预览版，这是一项专为数据策展人设计的 AI 驱动工作流，旨在解决企业级分析中“最后一公里”的语义鸿沟问题。该功能目前支持 **AWS Glue Data Catalog** 和 **Databricks Unity Catalog**，未来将扩展至更多平台。 ## 痛点：元数据孤岛与手动重建 企业数据团队在数据目录（如 AWS Glue、Databricks Unity Catalog、Snowflake Horizon、Collibra 和 dbt）中投入大量精力，定义了详细的表描述、列语义、主外键关系、术语表和指标定义。然而，当业务用户（如销售经理、市场总监）需要基于这些数据获得 AI 驱动的洞察时，却面临三大挑战： - **发现困难**：在数千张表中找到经过策展且适用于报告的资源，如同大海捞针。 - **语义碎片化**：上游已有的丰富元数据无法自动流入 Amazon Quick，策展人必须手动重建资源、重新定义描述，导致“收入”是毛额还是净额、“活跃客户”是 30 天还是 90 天等定义无法统一。 - **时间延迟**：手动发现和重建导致从数据到洞察的时间从几小时拉长到数周。 ## 解决方案：自然语言驱动的目录体验 Agentic Catalog Experience 通过 AI 代理，让数据策展人能够用自然语言描述需求，系统自动发现上游目录资产，并自动创建带有继承语义的 Dataset 和 Topic。例如，策展人只需输入“查找与销售相关的所有表”，系统即可返回相关资产，并自动映射表间关系。 这一功能的核心价值在于，它打通了上游目录与 Amazon Quick 之间的语义连接，使企业能够复用已有的数据治理投入，避免重复劳动，并确保业务用户获得一致、可信的定义。 ## 行业意义：从孤立到连接 这一发布反映了 AI 分析领域的一个重要趋势：**目录感知的 AI**。随着 Text2SQL 等自然语言查询技术的普及，AI 的答案质量取决于底层语义上下文的丰富程度。Amazon Quick 不再作为孤立产品运作，而是原生消费上游数据目录中的定义、关系和治理元数据，从而为企业提供规模化、可信赖的智能分析。 ## 未来展望 目前该功能处于预览阶段，仅支持 AWS Glue 和 Databricks Unity Catalog，但 Amazon 表示将逐步扩展对其他目录的支持，如 Snowflake Horizon 和 Collibra。对于已在这些平台上投入大量资源的企业而言，Agentic Catalog Experience 有望显著缩短数据到洞察的周期，释放 AI 驱动的业务价值。
Amazon Quick 近日宣布推出 **Agentic Catalog Experience**，这是一款面向数据管理者的 AI 驱动工作流，旨在解决企业数据目录与 AI 分析工具之间的“最后一公里”衔接问题。该功能目前处于预览阶段，支持 **AWS Glue Data Catalog** 和 **Databricks Unity Catalog**。 ## 背景：从孤立元数据到目录感知的 AI 随着企业拥抱 AI 驱动的分析，自然语言查询（Text2SQL）的答案质量高度依赖于背后的业务上下文。过去，数据团队在 AWS Glue、Databricks Unity Catalog、Snowflake Horizon、Collibra 和 dbt 等平台投入大量精力定义表描述、列语义、主外键关系、术语表和指标定义。然而，这些丰富的语义信息往往无法顺畅传递到终端用户使用的 AI 工具中，导致数据孤岛和重复劳动。 ## 三大核心挑战 数据管理者在 Amazon Quick 中为业务用户（如销售经理、市场总监和财务主管）准备数据时，常面临三大挑战： - **可发现性有限**：企业目录中包含数千张表，找到经过整理并批准用于报告的上游资产如同大海捞针，无法通过自然语言描述来定位。 - **语义碎片化与手动重建**：上游已有的丰富元数据（如表和列的业务描述、主外键关系）无法自动流转，管理者必须从头重建资产，重新定义描述，并手动协调定义——例如“收入”指毛收入还是净收入？“活跃客户”是 30 天内购买还是 90 天内购买？这些定义虽已存在于上游，却需要手动重新录入。 - **洞察时间过长**：手动发现和重建导致从数据到可操作洞察的时间从几小时延长到几周。 ## Agentic Catalog Experience 的解决方案 Agentic Catalog Experience 通过 AI 代理（Agent）自动化上述流程，让数据管理者能够用自然语言发现上游目录资产，并自动创建带有继承语义的 Dataset 和 Topic。这意味着： - 管理者可以直接描述需求，系统自动匹配并推荐合适的表和相关资产。 - 表描述、列含义、关系等语义信息自动从上游目录继承，无需手动重建。 - 生成的分析资产（Dataset 和 Topic）直接包含正确的业务定义，确保分析结果的一致性和可信度。 ## 行业意义与展望 这一功能标志着数据分析工具正从“孤立元数据”向“连接目录的 AI”转变，使企业能够更高效地利用已有的数据治理投资。通过减少手动工作，数据团队可以更快地响应业务需求，同时确保数据语义的准确性和一致性。目前该功能处于预览阶段，未来有望扩展支持更多目录平台，如 Snowflake Horizon 和 Collibra。 对于正在构建企业级 AI 分析能力的企业而言，Agentic Catalog Experience 提供了一个重要的范例：如何将数据目录作为 AI 的语义基础，实现真正的智能化分析。
当 AI Agent 从原型走向生产，挑战从“让它工作”变成“让它又快又稳”。本文介绍如何利用 Amazon Bedrock AgentCore Observability 与 Amazon CloudWatch，定位性能瓶颈并诊断长时间运行会话中的内存问题。
2026年7月27日，Moonshot AI发布了**Kimi K3**，这是首个达到3万亿参数级别的开源MoE模型，拥有**2.8万亿总参数**和**896个专家模块**（每token激活16个）。本文详细介绍了在AWS上部署Kimi K3的两种方案：**Amazon SageMaker HyperPod**和**Amazon Elastic Kubernetes Service (Amazon EKS)**。 ## Kimi K3的核心特性 Kimi K3采用了创新的架构，包括**Kimi Delta Attention (KDA)**、**Gated Multi Head Latent Attention (MLA)**和**Stable LatentMoE框架**。其关键参数如下： | 属性 | 值 | |------|-----| | 总参数 | 2.8万亿 | | 每token活跃参数 | 1040亿 | | 架构 | MoE | | 专家数 | 896（每token激活16个） | | 上下文窗口 | 100万token | | 模态 | 原生多模态（文本+视觉） | | 发布日期 | 2026年7月27日 | 该模型在长周期编码、智能体工作流和复杂推理方面表现出色，支持原生工具调用、结构化输出和持续思考模式。 ## 模型权重与格式 Kimi K3的开放权重以**MXFP4**（Microscaling Floating Point 4-bit）格式发布在Hugging Face上，标识为`moonshotai/Kimi-K3`。这种格式在模型质量和内存效率之间取得了平衡。由于模型规模庞大，部署需要**vLLM day-0推理容器**（当前为`vllm/vllm-openai:kimi-k3`），未来将合并到主vLLM容器中。 ## AWS部署方案 ### 1. Amazon SageMaker HyperPod SageMaker HyperPod提供托管基础设施，专为大规模分布式训练和推理设计。部署步骤包括： 1. **创建HyperPod集群**：配置GPU实例（如p5.48xlarge），确保足够显存。 2. **加载模型权重**：从Hugging Face下载MXFP4格式权重。 3. **配置推理容器**：使用vLLM容器启动服务。 4. **设置自动缩放**：根据负载动态调整资源。 ### 2. Amazon EKS 对于熟悉Kubernetes的团队，EKS提供了更高的灵活性： 1. **创建EKS集群**：部署GPU节点组（如g5或p4d实例）。 2. **部署vLLM推理服务**：编写Kubernetes清单，使用vLLM镜像。 3. **配置持久卷**：存储模型权重。 4. **暴露服务**：通过LoadBalancer或Ingress对外提供API。 ## 性能与优化 由于Kimi K3的活跃参数仅占总量约3.7%，推理时的计算效率较高。优化建议包括： - 使用**FP4量化**减少显存占用。 - 启用**连续批处理**提高吞吐量。 - 利用**KV缓存**加速长序列推理。 ## 总结 Kimi K3的开源发布标志着开源模型在规模上迈入3万亿参数时代。AWS提供的SageMaker HyperPod和EKS两种方案，分别适合不同技术栈的团队。随着vLLM的正式支持，部署门槛将进一步降低，推动更多组织探索前沿AI能力。
随着开源权重模型在复杂任务中的表现日益强大，如何高效部署这些动辄数万亿参数的大模型成为企业关注的焦点。Moonshot AI 于 2026 年 7 月 27 日发布的 Kimi K3，作为首个达到 3 万亿参数级别的开源权重模型，凭借其创新的架构和卓越的性能，为自托管大模型树立了新标杆。本文基于 AWS 官方博客，详细介绍如何在 Amazon SageMaker HyperPod 和 Amazon EKS 上部署 Kimi K3，涵盖模型特性、部署步骤及关键技术要点。 ## Kimi K3 模型概览 Kimi K3 拥有 **2.8 万亿参数**，采用 Mixture of Experts（MoE）架构，包含 **896 个专家**，每次推理仅激活其中 16 个，因此每次前向传播仅需计算约 **1040 亿参数**，相比前代 Kimi K2，扩展效率提升了 **2.5 倍**。该模型支持 **100 万 token 的上下文窗口**，并原生支持文本与视觉的多模态输入。其独特的设计包括 Kimi Delta Attention（KDA）、Gated Multi Head Latent Attention（MLA）以及 Stable LatentMoE 框架，使其在长时程编码、智能体工作流和复杂推理任务中表现出色。 ## 模型获取与格式 Kimi K3 的开源权重已在 Hugging Face 上发布，模型标识为 `moonshotai/Kimi-K3`，采用 **MXFP4（Microscaling Floating Point 4-bit）** 格式，在模型质量与内存效率之间取得了良好平衡。由于模型体量庞大，服务 Kimi K3 需要专用的 vLLM 推理容器，目前相关提交位于 `vllm/vllm-openai:kimi-k3`，预计未来将合并至主 vLLM 容器。 ## 部署方案一：Amazon SageMaker HyperPod SageMaker HyperPod 为大规模分布式训练和推理提供了托管基础设施，简化了集群管理。在 HyperPod 上部署 Kimi K3 的典型步骤包括： 1. **创建 HyperPod 集群**：选择合适的实例类型（如 p5.48xlarge，配备 8 张 H100 GPU），并配置必要的存储和网络。 2. **构建自定义容器**：基于 vLLM 的 Kimi K3 分支构建推理镜像，并推送至 Amazon ECR。 3. **配置推理端点**：通过 SageMaker SDK 或 CLI 创建端点，指定实例数量和容器参数。 4. **测试与监控**：使用示例请求验证模型输出，并利用 CloudWatch 监控资源利用率。 ## 部署方案二：Amazon EKS 对于已有 Kubernetes 经验的企业，EKS 提供了更灵活的部署方式。核心步骤包括： 1. **创建 EKS 集群**：使用 `eksctl` 或 AWS 控制台创建集群，并配置节点组，建议使用 GPU 实例类型。 2. **部署 NVIDIA 设备插件**：确保 Pod 能够访问 GPU 资源。 3. **部署 vLLM 推理服务**：编写 Kubernetes Deployment 和 Service 清单，指定镜像和资源请求。 4. **配置自动伸缩**：利用 HPA（Horizontal Pod Autoscaler）或 KEDA 根据负载调整副本数。 ## 总结与展望 在 AWS 上部署 Kimi K3 无论是通过 SageMaker HyperPod 还是 EKS，都为企业提供了灵活的选择。HyperPod 适合希望减少运维负担的团队，而 EKS 则适合已有 Kubernetes 基础设施的组织。随着 Moonshot AI 和 AWS 的持续合作，未来大模型部署的效率和易用性将进一步提升。
## 概述 在数字广告领域，将用户的搜索意图与跨渠道的相关广告体验精准连接，始终是一大难题。雅虎（Yahoo）需求方平台（DSP）通过引入 **Amazon Bedrock**，对其搜索重定向（SRT）能力进行了全面升级，为广告主提供了更智能的受众定向方案。 ## 传统方案的困境 雅虎原有的 SRT 架构基于 **Word2Vec 嵌入模型** 结合 **局部敏感哈希（LSH）** 来扩展广告主的关键词。这一流程包括关键词规范化、生成嵌入向量、索引、LSH 搜索、过滤敏感词和排序结果等多个步骤。然而，该方案存在明显局限： - **词汇库陈旧**：无法及时反映当下的流行词汇和新兴术语。 - **短语级搜索**：侧重于短语匹配，而非具体的实体或概念。 - **句法相似性**：扩展结果依赖句法相似度，难以捕捉深层语义。 这些缺陷导致广告主无法有效触达那些通过搜索行为表达真实意图的用户，尤其是在用户搜索词与广告主预设关键词存在语义差异时，传统方法往往失效。 ## Amazon Bedrock 带来的变革 为了突破上述瓶颈，雅虎选择 **Amazon Bedrock** 作为底层 AI 能力支撑。Amazon Bedrock 提供了对多种基础模型的便捷访问，使得雅虎能够快速构建和部署先进的语义理解模型。 新方案的核心转变在于：从基于关键词的句法匹配升级为 **基于语义的意图理解**。具体而言，雅虎利用 Amazon Bedrock 上的大语言模型（LLM）对用户搜索查询进行深度语义分析，识别出查询背后的真实意图和实体，而非仅仅匹配字面关键词。 例如，当用户搜索“最佳跑步鞋评测”时，传统系统可能只会匹配“跑步鞋”或“评测”等关键词，而新系统能够理解这是一种 **购买意向信号**，并关联到运动装备、跑步爱好者等更广泛的受众特征。 ## 落地效果与行业价值 通过采用 Amazon Bedrock，雅虎的 SRT 能力实现了以下提升： - **更精准的受众识别**：语义理解能够捕捉同义、近义乃至上下文相关的查询，将搜索意图与广告主的目标受众更紧密地绑定。 - **动态词汇扩展**：大语言模型可以实时理解新兴词汇和短语，确保广告活动始终与当前用户用语同步。 - **跨渠道一致性**：SRT 将搜索意图延伸到展示广告、视频广告和原生广告中，实现真正的全渠道覆盖。 这一升级对数字广告行业具有重要意义。随着用户隐私保护加强和第三方 Cookie 逐步淘汰，基于 **第一方搜索数据** 的定向方法变得愈发关键。雅虎的实践表明，通过生成式 AI 强化搜索信号的利用，广告主可以在不依赖用户身份标识的情况下，依然实现高效的人群触达。 ## 小结 雅虎借助 Amazon Bedrock 改造搜索重定向功能，是广告技术领域利用生成式 AI 提升精准营销的典型案例。它不仅解决了传统关键词扩展的语义短板，更展示了云服务平台在赋能广告系统智能化方面的巨大潜力。对于其他 DSP 和广告技术提供商而言，这一思路值得借鉴——**用语义理解取代句法匹配，用意图识别取代关键词盲扩**，将是未来受众定向技术演进的重要方向。