亚马逊AWS官方博客

Category: Artificial Intelligence

从AI辅助编程到AI-DLC:紫讯落地 AI 原生研发新范式的实践

当 AI 从”写一段代码”走向”参与完整研发流程”时,真正的瓶颈不再只是模型能力,而是团队有没有一套能让 AI 稳定工作的工程体系。紫讯围绕 AI-DLC(AI-Driven Development Life Cycle)方法,在与 亚马逊云科技团队的持续交流、Workshop 共创和工具实践中,逐步建立了从知识沉淀、需求塑形、方案收敛、开发协同、测试验证到经验回流的端到端研发闭环,让 AI 的产出可追溯、可复用、可验证、可纠偏,并持续沉淀为组织级研发资产(zixun-github-ai-dlc)。

中国用户安全高性能访问海外 Bedrock

优先走私网、尽量不走公网:固定办公采用专线(DX / SD-WAN)直连,远程用户先通过 Client VPN 接回数据中心、复用同一条私网链路,确无 VPN 时才使用海外 EC2 代理做 TLS 透传兜底——三条路径最终都经 VPC Interface Endpoint 走 AWS PrivateLink,进入 AWS 后全程私有、不暴露于公网。

AWS DevOps Agent 接入 AWS 中国区(二):多账号扩展、跨云接入与无长期 AK/SK 认证

本文是 AWS DevOps Agent 接入 AWS 中国区系列的第二篇。前一篇介绍了为什么需要 MCP(Model Context Protocol)桥,以及单账号部署的端到端流程。本文承接上文,聚焦三件事:第一,如何用一个 Helm Chart 管理 N 个 AWS 中国区账号;第二,跨云接入(以阿里云为例)的工程取舍;第三,长期 Access Key 的 90 天轮换实践。

基于 Application Inference Profile 为 Amazon Bedrock 构建分业务单元的近实时成本告警

本文介绍一种轻量、旁路、近实时的方案:调用方直连 Amazon Bedrock,链路上没有代理;用 Application Inference Profile 做分 BU 的用量归因;直接在 Amazon CloudWatch metric math 告警里把 token 数换算成估算成本;再通过一个通用的通知 Lambda 函数把告警状态变更转发到协作工具(本文以飞书为例,同样适用于weixin、dingtalk、Slack、Microsoft Teams 或邮件)。

Zenjoy 基于 Amazon Bedrock 和 EKS 构建 AIOps Agent:打通 Prometheus、ES 与夜莺的智能化告警实战

随着微服务架构的规模化演进,传统基于静态阈值的监控告警体系面临误报率高、漏报频发、人工排查效率低等瓶颈。本文介绍了一种将确定性数学算法与大语言模型深度解耦的 AIOps Agent 方案——由 Z-Score、IQR、线性回归等统计算法完成全量监控数据的确定性分析与过滤,再由 Amazon Bedrock 上的LLM模型对精简后的结论进行智能总结与报告生成,最终通过夜莺平台实现告警的统一管理与多渠道通知。该方案运行在 Amazon EKS 之上,使用 AWS 开源的 Strands Agents 框架构建 Agent,实现了告警信噪比的大幅提升和运维效率的显著改善。

企业智能体之旅:为什么评估(Evaluation)是一切的起点

当企业把 AI Agent 从“演示惊艳的原型”推向“生产可信赖的系统”时,评估(Evaluation)就成了决定成败的关键一环——它既不同于传统软件的单元测试,也不同于单模型 benchmark。本文基于 Amazon 内部构建数千个生产级 Agent 的实战经验,系统拆解 AWS 的 Agent 评估方法论,并给出一套从原型验证到生产就绪的工程实践路径。

评估企业级智能体:从原型验证到生产就绪

Agent 与传统软件有本质不同——非确定性、Prompt 即源代码、依赖会自己动——因此传统 QA 框架在它身上系统性失效,需要一套新的开发生命周期 ADLC。在那个六环节的飞轮里,“定义‘好’”排在动手构建之前,而 Evaluation 后续工程实践的重要基础:没有它,你不知道自己在哪里,也不知道改了之后有没有变好。上一篇结尾留下了三个问题:Agent Evaluation 究竟要评什么维度?有哪些方法?如何从零构建一套在企业规模下真正可用的评估体系? 本篇就来回答它们。

如何在亚马逊云科技上构建企业级智能体

前面两部分我们讨论了 Agent 的开发生命周期,以及评估为什么是一个全新的问题——它既不同于传统软件的单元测试(输入到输出不再是确定性映射),也不同于大模型 benchmark。本章的主线是六个递进的问题:评估框架长什么样 → 该看哪些指标 → 评估流程怎么跑 → 数据集和人怎么进来 → 怎么把它变成工程纪律 → 有什么工具支撑。

750B MoE 模型从自建 RoCE 集群迁移至 AWS EFA:Prefill-Decode 分离推理的通信架构验证

客户在自建机房使用基于 ConnectX 系列网卡的 RoCE 集群运行 GLM-5.1-FP8(750B MoE)模型推理服务,采用 Prefill-Decode (PD) 分离架构:2 台 Prefill 节点 + 2 台 Decode 节点,每台 8×H200 GPU。期望利用 AWS 弹性算力扩展本地 GPU 计算资源,同时获得更快的硬件迭代能力,从而降低硬件采购和折旧风险。AWS EFA 能否在这种极端复杂的通信负载下,达到 ConnectX 系列 + RoCE 方案的性能水平?我们基于客户的实际部署需求进行了完整的理论分析和实际验证