用 Strands 与 AgentCore 做生产级智能体评估

#用 Strands 与 AgentCore 做生产级智能体评估

2026 年 7 月 23 日

本文与 Motorway 以及 AWS 原型与 AI 客户工程团队（Prototyping and AI Customer Engineering，PACE）共同撰写。

Motorway 是一家总部位于英国的在线汽车市场，每天举办拍卖，最多有 8,000 名经销商对最多 2,500 辆车出价。Motorway 与 AWS 原型与 AI 客户工程团队（PACE）合作，构建了一个由 AI 驱动的经销商库存搜索智能体（Agent），改变经销商找车的方式，用自然语言查询取代数小时的手工筛选。

挑战

智能体给出的回答听起来很有把握，但当真实的钱压在线上时，你如何证明它可靠地工作？

• 工具选择错误（Tool selection errors） 会导致错误的搜索结果，侵蚀经销商的信任。
• 语义搜索误读（Semantic search misinterpretations） 会返回不相关的结果。像“5 年以内的汽油、混动和电动汽车（Petrol, Hybrid and electric cars up to 5 years old）”这样的查询，要求智能体正确解析多项约束。
• 多轮对话中的上下文漂移（Context drift） 会丢掉经销商的细化条件。
• 非确定输出（Non-deterministic outputs） 使单次试验不可靠。

解决方案

Motorway 与 AWS 一起构建了一条端到端评估流水线，把错误结果从每 8 次查询 1 次降到每 50 次查询 1 次，并把发现问题的时间从数小时缩短到数分钟。

这条流水线把 Strands Agents SDK 与 Amazon Bedrock AgentCore 结合起来。AgentCore 是一项用于大规模部署和运行 AI 智能体的全托管服务。在本文中，你将学会如何为自己的智能体构建这条流水线：

• 两阶段评估策略（two-phase evaluation strategy）：覆盖用 strands-agents-evals（Strands Agents 的开源评估库）做的构建期测试，以及用 Amazon Bedrock AgentCore Evaluations 做的生产监控。
• 三层框架（three-layer framework）：用于评估工具使用、推理和输出质量。
• 五阶段部署流水线（five-stage deployment pipeline）：带有质量门禁，指标低于阈值时阻止发布。

配套仓库提供一份可部署的蓝图，你可以改成适配自己的智能体。虽然蓝图使用 AWS 服务，其核心原则是任何生产级 AI 智能体都必要、且与具体系统无关的要求。这些原则包括三层评估框架，以及用连续通过率（pass^k）衡量一致性。

前提条件

要跟着本文操作，你必须具备以下前提。

• 一个AWS 账户，并拥有 Amazon Bedrock、AWS Lambda、Amazon Simple Storage Service（Amazon S3）、Amazon DynamoDB、Amazon EventBridge、Amazon CloudWatch 和 Amazon Simple Notification Service（Amazon SNS） 的权限。
• 已安装并完成引导的 AWS Cloud Development Kit（AWS CDK） v2。
• Python 3.14+。
• 通过 Amazon Bedrock 模型访问 使用 Anthropic Claude 模型和 Amazon Titan 模型。
• 熟悉 Python、AWS CDK 和智能体概念（工具调用、多轮对话）。

完成时间： 初次部署 30–45 分钟，按你的领域定制再加 2–3 小时。

估计成本： 运行示例评估套件大约产生 5–10 美元的 Amazon Bedrock 推理费用。生产监控成本随采样率变化。

安全说明： 配套仓库实现了最小权限的 AWS 身份与访问管理（Identity and Access Management，IAM）角色，把 API 密钥存在 AWS Systems Manager Parameter Store（而不是环境变量）里，并使用带类型的参数来帮助防止注入攻击。细节见仓库 README。

实例：经销商库存搜索智能体

Motorway 在 Strands Agents SDK 和 Amazon Bedrock AgentCore 上构建了经销商库存搜索智能体。该智能体暴露八个工具，把对 89 项以上车辆属性的结构化筛选，与由 LanceDB 和 Amazon Titan Text Embeddings V2 驱动的向量相似度搜索结合起来。

经销商过去通常要用 CSV 和僵硬的筛选条件，花数小时浏览挂牌。引入对话式 AI 智能体后，经销商现在可以这样对智能体说：“在我的经销店附近找 2.5 万以下的柴油 SUV（Find me diesel SUVs under 25k near my dealership）”，或“适合家庭的、运动一点的自动挡（something sporty and automatic for a family）”。

高峰时段大约有 1,500 个并发用户，把智能体行为做对不是可选项。一次工具选择错误或语义搜索误读会直接影响用户信任。图 1 展示端到端请求流：经销商通过 Web 界面提交自然语言查询，请求被路由到 Amazon Bedrock AgentCore Runtime。运行时编排对八个不同工具的调用，同时使用 Amazon Bedrock 模型（Claude 负责推理，Amazon Titan 负责嵌入）。工具响应再经运行时流回，生成最终面向经销商的结果。

为什么智能体评估不一样

大语言模型（Large language model，LLM）评估关注文本生成质量：连贯性、事实准确性、回答相关性。智能体评估衡量的是根本不同的东西。可以这样看：LLM 评估检查的是发动机性能。智能体评估衡量的是整辆车在车流里、在雨中、或后座坐满乘客时怎么开。

传统 LLM 指标不会告诉你，Motorway 的智能体对“一级铃木车型（Grade 1 Suzuki models）”有没有调用正确的搜索工具。它们不会揭示智能体有没有把正确的筛选参数传给 LanceDB。它们也会漏掉：经销商在上一轮基础上细化结果时，是否得到了正确回答。

像“7–12 年车龄的大众高尔夫（Volkswagen Golf 7-12 years old）”这样精确的查询可能完美工作，但像“我想找一辆老一点的大众（I’m looking for an older VW）”这样的口语变体，如果语义搜索层没有被正确评估，就可能失败。

用 strands-agents-evals 在部署前抓住问题

蓝图在两个阶段实施评估，这两个阶段对应 GenAIOps 生命周期。构建期评估在部署前抓住问题，生产评估抓住合成测试漏掉的东西。下面的图（图 2）展示工具使用、推理和输出质量这几层如何必须在部署前通过。该框架从三层评估智能体：

• 第 1 层（工具使用）以高于 95% 的阈值验证正确的工具选择和参数传递。
• 第 2 层（推理）以高于 85% 的阈值评估逻辑决策。
• 第 3 层（输出质量）以高于 90% 的阈值衡量回答是否有帮助、是否准确。三层都必须通过，部署才会继续。

在开发和持续集成与持续部署（continuous integration and continuous deployment，CI/CD）期间，流水线使用 strands-agents-evals 框架在部署前抓住问题。它提供输出校验、轨迹评估、多轮对话模拟和自动实验生成。每一项都被设计为与构建在 Strands Agents SDK 上的智能体原生配合。该框架提供三个原语：

• Experiment：针对智能体运行的一组测试用例。
• Case：输入查询、期望输出和期望的工具轨迹。
• Evaluator：评分逻辑（确定性的，或基于 LLM 的）。

把测试按层组织。第 1 层运行基于代码的确定性评分器，检查工具选择准确率。第 2 层和第 3 层使用 LLM 充当裁判的评估器（用一个 LLM 给智能体输出打分），评估推理和输出质量。

自定义的 Evaluator 子类处理领域特有问题。对 Motorway 的智能体，这些覆盖数据新鲜度、经销商范围和安全护栏。你的智能体会有自己的领域约束。

三类评分器

评估框架使用三类评分器，每一类适合不同的评估需要。

实践中，给智能体产出的结果打分，比给它走过的路径打分能抓住更多问题。你在意的是用户得到了相关结果，而不是智能体先调用了哪个工具。

三层评估框架

构建期评估在三个不同的层上运行，每一层有具体的通过/失败阈值。

第 1 层：工具使用（阈值 > 95%）。 智能体是否用正确参数调用了正确的工具？

• “7,000 英镑到 20,000 英镑的柴油车（Diesel vehicles from £7,000 to £20,000）”应当使用 search_vehicles，并带上带类型的筛选条件

（fuel_type=diesel，min_price=7000，max_price=20000）。

• “低里程的现代掀背车（Modern hatchback with low mileage）”应当触发 hybrid_search，把语义嵌入和结构化筛选结合起来。

你用确定性方式衡量这一点：ToolSelectionGrader 检查调用了哪些工具，TrajectoryOrderGrader 验证调用顺序。

第 2 层：推理（阈值 > 85%）。 决策过程是否合乎逻辑？来自 strands-agents-evals 的 HelpfulnessEvaluator 和 TrajectoryEvaluator 使用 LLM 充当裁判的评分，评估智能体的推理是否站得住。一个通过不合逻辑的推理得到正确回答的智能体，会在条件变化时不可预测地失败。

第 3 层：输出质量（阈值 > 90%）。 回答是否有帮助、准确、可执行？来自 strands-agents-evals 的 OutputEvaluator 和 GoalSuccessRateEvaluator 使用 LLM 充当裁判的评估，判断用户是否得到了有用、格式良好的回答。

三层都必须在部署前通过。某一层失败会阻断流水线。

处理非确定性

因为 LLM 输出在不同运行之间会变化，单次试验结果可能有误导性。配套仓库里的 run_all_layers() 函数接受 num_trials 参数来处理这一点。来自代码生成研究社区的两个指标帮助衡量可靠性：

• pass@k 衡量在 k 次尝试中至少成功一次的可能性。当找到一个正确解就够用时，这个指标有用。
• pass^k（pass 的 k 次方）衡量连续 k 次试验都成功的概率。当用户期望每次都可靠时，这个指标有用。

对面向客户的智能体，pass^k 最重要。单次试验成功率 75% 的智能体，连续三次试验都通过的机会只有 42%（0.75³）。用户期望每一次交互都有一致的质量。

在配套代码中，run_all_layers(task_fn, registry, num_trials=5) 以多次试验支持运行评估层，并以 pass^k 作为部署门禁。见完整实现。

测试用例管理

测试用例按类别组织：

• 顺利路径（Happy path）：应当成功的常见查询。
• 边界情况（Edge cases）：含糊查询、俚语、多轮细化。
• 安全/护栏（Safety/Guardrails）：智能体应当拒绝或改道的查询。

当生产监控发现问题，那次交互就变成一条新测试用例。Motorway 的套件在三个月里从最初的 50 条增长到 150 条，每一条都扎根于真实用户行为。从 20 到 50 条开始，让生产数据把套件养大。

要包含负例，也就是智能体不应当调用某些工具的情况。例如，资料查询应当调用资料工具，而不是搜索工具。结构化查询应当使用结构化搜索，而不是退回原始 SQL。片面的评估会造成片面的优化。

多轮对话测试

单轮评估会漏掉一个关键维度：对话连贯性。经销商自然会跨多轮细化搜索：

• 第 1 轮：“给我找柴油 SUV（Find me diesel SUVs.）。”
• 第 2 轮：“现在只给我看自动挡（Now show me only the automatics.）。”
• 第 3 轮：“那旅行车呢（What about estates instead?）？”

strands-agents-evals 框架提供 ActorSimulator 来生成逼真的多轮交互，并提供 InteractionsEvaluator 来给跨轮的上下文保持打分。多轮测试能抓住单轮测试漏掉的上下文漂移、筛选条件累积错误和代词解析失败。

用 AgentCore Evaluations 监控生产行为

在你把 Strands Agent 部署到 Amazon Bedrock AgentCore Runtime 之后，AgentCore Evaluations 提供持续监控。它通过 OpenTelemetry 插桩（业界标准的可观测性框架）与 Strands Agents 集成。图 3 展示生产中的架构：可观测性追踪按 1–5% 采样，指标汇聚到 Amazon CloudWatch。

两种监控方式

AgentCore Evaluations 提供两种互补模式：

按需评估（On-demand evaluation） 通过分析从 Amazon CloudWatch 日志中选出的跨度（span），检查特定的智能体交互。这对调试问题或验证修复有用。

在线评估（Online evaluation） 自动采样线上流量，并在后台应用评估器。配置一个采样率（建议 1–5%），最多选择 10 个评估器，然后让它运行。

内置评估器与自定义评估器

AgentCore 为常见场景提供预配置的评估器。下表展示内置评估器以及它们衡量什么。

对领域特有要求，你可以用 LLM 充当裁判的配置创建自定义评估器。每个智能体都有内置评估器覆盖不到的领域约束，包括数据新鲜度、访问范围、禁止的动作、延迟预算和成本上限。

配套仓库包含五个可改编的自定义 Evaluator 子类：

LatencyEvaluator 和 CostEvaluator 的例子见配套仓库。

要跟踪的关键指标

配套仓库包含一个 AWS CDK 栈，用于配置 CloudWatch 仪表盘和告警。跟踪这些指标以监控智能体健康。

把质量检查做成部署门禁

评估应当是部署流水线里的质量门禁，而不是事后补上的想法。图 4 展示带评估门禁的部署流水线，覆盖构建期评估、预发验证、影子模式、A/B 测试和生产放量，失败会阻止部署。

部署流水线遵循五个阶段：

1. 构建期评估：单元测试、工具正确性（ToolSelectionGrader >95%）、轨迹测试，以及 LLM 充当裁判的评分（HelpfulnessEvaluator >85%）。
2. 预发验证：用合成流量对预发数据做按需 AgentCore 评估。
3. 影子模式（Shadow mode）：真实生产流量并行处理，不影响用户。至少运行 4 小时，偏差阈值为 2%。
4. A/B 测试：5% 的线上流量路由到候选智能体，以测量真实结果。
5. 生产放量：100% 流量，并持续做在线评估和监控。

你为每个阶段定义阈值：工具选择准确率低于 95%，或任务完成率低于 80%，就会阻止部署。对重大发布，使用 num_trials=5 的多次试验评估，以 pass^k 作为门禁，抓住非确定性失败。

影子模式

在预发和生产之间，让候选智能体对着真实查询运行，但不影响用户。影子模式接收一份生产流量的副本，并行地让候选版本处理，并比较结果。在进入 A/B 测试之前，影子模式至少运行 4 小时。定义一个偏差阈值（2% 是一个好的起点），让部署自动暂停。

影子模式能抓住其他阶段漏掉的问题：

• 并发负载下的超时处理。
• 合成测试里缺少的领域术语。
• 在真实流量模式下造成延迟尖峰的工具调用顺序。

起步：分阶段做法

阶段 1：建立测试套件。 从真实用户查询中抽出 20–50 条测试用例开始。包含正例和负例。既测试智能体应当做什么，也测试它应当拒绝什么。

阶段 2：配置构建期评估。 让评分器类型匹配你在衡量的东西：工具选择用确定性评分，推理和输出质量用 LLM 充当裁判。

阶段 3：启用生产监控。 以 1–5% 的采样率配置 AgentCore Evaluations。先从低采样开始，确认评估器成本可接受后再提高。

阶段 4：闭合反馈回路。 把生产失败变成测试用例。当失败变成回归测试时，这条反馈回路在各团队中持续提高了评估质量。

结果与影响

在实施这条评估流水线之前，智能体的工具选择准确率是 87%，这意味着每 8 次经销商查询就有 1 次返回错误结果。团队每月看到 12 起生产事件，而且问题开始影响经销商之后，平均要 4 小时才能发现。

实施流水线之后：

业务影响：经销商现在用数分钟而不是数小时完成车辆搜索，并且确信结果准确、是当前的。

故障排查

常见问题的解决办法见配套仓库 README，包括轨迹评分器失败、LLM 充当裁判的方差、空的评估结果，以及成本阈值调优。

要点

构建评估流水线时记住这些原则。

• 把评估分层：工具使用（>95%）、推理（>85%）和输出质量（>90%）抓住不同的失败模式。
• 用 pass^k 做门禁，而不是单次试验：单次试验成功率 75%，意味着连续三次运行的可靠性只有 42%。
• 把生产失败变成测试用例：让真实用户行为把评估套件养大。
• 影子模式抓住合成测试漏掉的东西：真实流量会暴露超时处理、罕见术语和延迟模式。
• 监控从 1% 采样开始：逐步放大，以管理评估器成本。

结论

你现在已经看到如何在 AWS 上为生产 AI 智能体构建评估流水线，并以 Motorway 的经销商库存搜索智能体作为实例。

核心教训：回答流畅并不意味着智能体做对了。你必须核验工具选择、参数正确性、推理连贯性，以及重复运行之间的一致性。把 strands-agents-evals 的构建期测试和 AgentCore Evaluations 的生产监控结合起来，你就可以带着“它们按设计工作”的证据去部署智能体。

这些模式适用于大多数多工具、面向客户的智能体：无论你在构建查询知识库和工单系统的客服智能体，拉取组合数据和市场信息流的财务顾问智能体，还是访问患者记录和排班工具的医疗分诊智能体。

开始步骤：

1. 克隆配套仓库：

git clone https://github.com/aws-samples/sample-evaluating-agents-on-aws-with-strands-and-agentcore

2. 进入 CDK 项目目录：

cd sample-evaluating-agents-on-aws-with-strands-and-agentcore/examples/vehicle-auction-agent/cdk

3. 部署示例基础设施：

按照仓库的 README 部署步骤 部署示例基础设施。部署完成后，在 AWS CloudFormation 控制台检查所有 AWS CloudFormation 栈都显示 CREATE_COMPLETE 状态，以验证基础设施。你应当在各自的控制台里看到 CloudWatch 仪表盘和 Lambda 函数。

4. 运行示例评估套件，对着包含的测试用例运行，以看到三层框架如何工作。通过确认以下各项来验证成功：第 1 层（工具使用）显示高于 95% 的通过率，第 2 层（推理）显示高于 85% 的通过率，第 3 层（输出质量）显示高于 90% 的通过率。如果某一层失败，查看 CloudWatch 日志中的详细错误信息。

5. 为你的领域定制评估器。从 DataFreshnessEvaluator 和 SafetyGuardrailEvaluator 作为模板开始。

若要深入，请查看 Amazon Bedrock AgentCore 文档 以及 GitHub 上的 Strands Agents SDK。

清理资源

为避免持续产生费用，删除本次演练中创建的资源：

1. 进入 CDK 项目目录：

cd sample-evaluating-agents-on-aws-with-strands-and-agentcore/examples/vehicle-auction-agent/cdk

2. 销毁所有已部署的栈：

cdk destroy --all

3. 在提示时确认删除。
4. 在 AWS 管理控制台中验证清理过程已移除全部资源，包括 Lambda 函数、S3 存储桶、DynamoDB 表、CloudWatch 日志组和仪表盘、EventBridge 规则以及 SNS 主题。

注意： 含有对象的 S3 存储桶可能需要手工删除。在运行清理之前，导出任何你需要保留的评估数据或日志。

PRIMARY_SOURCE: https://aws.amazon.com/blogs/machine-learning/evaluating-ai-agents-a-production-blueprint-with-strands-and-agentcore