Category: Artificial Intelligence

Amazon Bedrock AgentCore Runtime 提供了构建在 OpenTelemetry 之上的可观测性能力，但”自动插桩”并非无条件生效。本文通过多组真实部署对照实验，拆解 AgentCore 可观测性的两层来源。

欢迎 DuckLabs 加入 AWS 团队，代理资源发现（ARD）等

本文是《企业级 EKS 集群生产环境配置最佳实践》系列第二篇，承接第一篇搭建的生产级 EKS 基础，聚焦 GPU 工作负载链路的深度架构实践。文章围绕 GPU 工作负载的三层架构 —— 计算节点、网络邻近性、高性能存储 —— 展开，覆盖 P5 / P5e / P5en / P6(B200 / B300) / G6e / G7e / G7 等 GPU 实例系列的 EFA 多网卡精确摆位(含 p6-b300 非对称拓扑)、四种定价模式的 Launch Template 设计、基于 topology.k8s.aws/network-node-layer-N 的 AWS 原生拓扑感知调度，以及 FSx for Lustre(PERSISTENT_2)与 S3 Express One Zone + Mountpoint CSI Driver 这两类高性能存储按访问模式的选型，并以一套声明式 Terraform 模块完整实现。

新版 Dify 把工作流执行引擎从平台中解耦为一个独立的 Python 库 graphon。迁移一条 workflow 因此只需安装这个库并适配少数几类节点，不必搬整个平台。我们用一个 PoC 验证了这条路径。一条 20 步的 KYB（商户准入尽调）workflow，覆盖调模型、调代码、调知识库和多路判断，业务逻辑一行不改，通过自定义 node factory 部署并运行在 AgentCore Runtime 上，云端 5 条分支路径全部验证通过。同一份 DSL 还能导回 Dify 画布渲染。本文给出这条路径的做法、部署证据，以及版本风险和生产化前需要补齐的边界。

在农业遥感监测、自然资源调查、城市规划、碳汇核算、保险定损等领域，企业客户日益需要对卫星影像进行快速分析。传统工作流要求GIS专业人员编写Python代码处理遥感数据，门槛高、周期长、成本大。亚马逊云科技开源项目 sample-geospatial-code-agent（https://github.com/aws-samples/sample-geospatial-code-agent）提供了一套AI智能体方案，让非技术用户也能通过自然语言完成专业级遥感分析。该方案采用Code Agent架构——LLM直接生成Python脚本执行，中间数据留在内存不回传上下文，相比传统Tool Agent在遥感分析场景中速度更快、成本更低。但原项目基于海外区服务生态构建，其底图方案（Google/CARTO瓦片）和部分托管服务无法在中国区直接运行，需要针对中国区进行适配。

AWS 构建者中心学习激励计划、拉斯维加斯新增本地区域等内容

在智能建筑和物业管理领域，IoT 设备的稳定运行对业务连续性至关重要。物业公司通常通过 IoT 平台管理大楼的设施设备，实时采集并记录设备报送的各类指标数据（如温度、湿度、压力等）。然而，设备离线、网络故障、平台问题等异常情况时有发生，传统的监控方式往往只能提供统计图表，关联分析比较困难，难以快速定位问题根源，影响了问题发现和处理的效率。本文以某客户智能建筑管理场景为例，介绍如何利用亚马逊云科技的无服务器（Serverless）来构建一套近实时（分钟级）的 IoT 设备异常检测系统，实现从数据采集、实时分析到告警的全流程自动化，面对大量 IoT 设备数据能够在数分钟内识别出设备的异常，为物业企业提供可靠的设备监控能力。

EC2 应用程序状态检查、IAM 角色管理器、Bedrock 上的 OpenAI Daybreak 等

本文介绍如何将 NousResearch 开源的 Hermes Agent 部署到 Amazon Bedrock AgentCore 的托管运行时 AgentCore Runtime 上，并使用 AWS Cloud Development Kit (AWS CDK) 以基础设施即代码的方式实现全部资源，支持 Telegram、Slack、Discord、飞书和微信等渠道接入。

Mantle 是 Amazon Bedrock 的新一代推理引擎，OpenAI 的 GPT-5.6（Sol / Terra / Luna）等模型由它提供服务，通过 OpenAI 兼容的 bedrock-mantle 端点对外暴露。它与承载 Claude 的经典 bedrock-runtime 端点在协议上并不一致：前者用 Chat Completions / Responses，后者用 Converse / InvokeModel。本文用一台 EC2 上的 LiteLLM 网关（测试形态，生产化建议见文中）把两个端点收敛到同一个入口，实测供出 9 个模型（GPT-5.6 三变体、GPT-5.5、GPT-5.4、gpt-oss 两款、Claude 两款），客户端只认一个地址、一个 key，网关侧完全用 EC2 实例角色做 SigV4 认证，不落盘任何 API key。文中还给出一个 92 行的 pre-call 钩子，解决 Codex 客户端与 Mantle 的请求体不兼容问题，让 Codex 和 opencode 共用同一套网关。