Author: awschina

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

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

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

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

利用 AWS Serverless架构实现 Kiro 费用的自动化采集、用户级分摊、CSV 报告生成，并通过飞书 Webhook 推送可视化摘要卡片。

WebSearch Interception 是 LiteLLM 的一个功能，允许不原生支持 web search 的 LLM provider（如 AWS Bedrock、Azure、Vertex AI）通过 LiteLLM 代理自动执行网页搜索并返回带有实时信息的回答。

硬件智能体、Amazon Bedrock、 AgentCore、设备助手、设备控制、 Device Assistant、Agent、Telegram 、人机交互。

本文介绍如何在 AWS 上以生产级标准部署 LiteLLM AI Gateway，涵盖 ECS Fargate 和 EKS 两种方案，并结合 LiteLLM 的 Control Plane / Data Plane 分离架构实现多区域高可用部署。

本文搭建了一个云上 VPC 和 模拟IDC 环境的网络环境，通过开启BGP路由传播并手工配置高优先级路由条目，验证 IDC 和云之间的网络流量经 NFW 审查的场景。

本文档介绍如何将 LiteLLM AI Gateway 的请求日志和费用数据接入 Amazon QuickSight，构建运维监控 Dashboard，实现对 LLM 使用量、费用、性能的可视化分析。