Evaluating AI Agents: A production blueprint with Strands and AgentCore

评估AI代理：使用Strands和AgentCore的生产蓝图 | 人工智能

评估AI代理：使用Strands和AgentCore的生产蓝图

本文由Motorway和AWS原型设计及AI客户工程（PACE）团队联合撰写。

Motorway是一家基于英国的在线汽车市场平台，每天举办拍卖会，最多有8,000家经销商竞标最多2,500辆汽车。Motorway与AWS原型设计及AI客户工程（PACE）团队合作，构建了一个由AI驱动的经销商库存搜索代理，彻底改变了经销商查找车辆的方式，将原本需要数小时的手动筛选过程替换为自然语言查询。

挑战

该代理能够给出自信的回应，但如何证明它在涉及真实资金时能可靠运行？

• 工具选择错误会导致搜索结果错误，损害经销商信任。
• 语义搜索误解会返回不相关的结果。像“汽油、混合动力和电动汽车，车龄不超过5年”这样的查询要求代理正确解析多个约束条件。
• 多轮对话中的上下文漂移会丢失经销商的细化要求。
• 非确定性输出使单次试验测试不可靠。

解决方案

Motorway与AWS共同构建了一个端到端的评估流水线，将错误结果率从每8个查询中有1个降低到每50个查询中有1个，并将问题检测时间从数小时缩短到数分钟。

该流水线结合了Strands Agents SDK与Amazon Bedrock AgentCore（一个用于大规模部署和运行AI代理的全托管服务）。在本文中，您将学习如何为自己的代理构建此流水线：

• 一个分两阶段的评估策略，涵盖使用strands-agents-evals（Strands Agents的开源评估库）进行构建时测试，以及使用Amazon Bedrock AgentCore Evaluations进行生产监控。
• 一个三层框架，用于评估工具使用情况、推理能力和输出质量。
• 一个包含质量门禁的五阶段部署流水线，当指标低于阈值时会阻止发布。

配套仓库提供了一个可部署的蓝图，您可以根据自己的代理进行调整。尽管该蓝图使用AWS服务，但核心原则对于任何生产就绪的AI代理都是关键且系统无关的。这些原则包括三层评估框架和使用pass^k指标来衡量一致性。

先决条件

要跟随本文内容，您必须具备以下先决条件：

• 具有访问Amazon Bedrock、AWS Lambda、Amazon Simple Storage Service（Amazon S3）、Amazon DynamoDB、Amazon EventBridge、Amazon CloudWatch和Amazon Simple Notification Service（Amazon SNS）权限的AWS账户。
• 安装并配置了AWS Cloud Development Kit（AWS CDK）v2。
• Python 3.14+。
• 通过Amazon Bedrock模型访问服务访问Anthropic Claude模型和Amazon Titan模型。
• 熟悉Python、AWS CDK和代理概念（工具调用、多轮对话）。

完成时间：初始部署需要30–45分钟，根据自己的领域进行定制需要2–3小时。

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

安全注意事项：配套仓库实现了最小权限AWS身份和访问管理（IAM）角色，将API密钥存储在AWS Systems Manager Parameter Store（而非环境变量），并使用类型化参数帮助防止注入攻击。详见仓库的README文件。

实例说明：经销商库存搜索代理

Motorway基于Strands Agents SDK和Amazon Bedrock AgentCore构建了经销商库存搜索代理。该代理暴露了8个工具，结合超过89个车辆属性的结构化过滤，以及由LanceDB和Amazon Titan Text Embeddings V2支持的向量相似度搜索。

经销商通常需要花费数小时通过CSV文件和固定过滤器浏览列表。通过引入对话式AI代理，经销商现在可以与代理对话："帮我找附近经销商25k以下的柴油SUV"或"找一辆适合家庭的运动型自动挡车"。

在高峰时段约有1500个并发用户，确保代理行为正确并非可选。工具选择错误或语义搜索误解会直接影响用户信任。图1展示了端到端请求流程：经销商通过网页界面提交自然语言查询，路由至Amazon Bedrock AgentCore Runtime。Runtime协调调用8个不同工具，同时使用Amazon Bedrock模型（Claude用于推理，Amazon Titan用于嵌入）。工具响应通过Runtime回传以生成最终面向经销商的结果。

为什么代理评估有所不同

大型语言模型（LLM）评估关注文本生成质量：连贯性、事实准确性、响应相关性。代理评估则评估本质上不同的内容。可以这样理解：LLM评估检查引擎性能，代理评估则评估整辆车在交通、雨天或后座满员时的驾驶表现。

传统LLM指标无法告诉你Motorway代理是否为"Grade 1 Suzuki车型"调用了正确的搜索工具。它们不会揭示代理是否向LanceDB传递了正确的过滤参数。也无法发现经销商在精炼前一轮结果时是否得到了正确响应。

评估维度 | 为什么对代理重要 ---|--- 任务完成 | 代理执行多步骤工作流，部分完成很常见 工具使用正确性 | 错误工具或不良参数可能导致整个工作流失败 推理连贯性 | 有缺陷的推理会导致条件变化时出现不可预测的故障 可靠性和一致性 | 非确定性意味着相同输入可能产生不同结果 安全与合规 | 自主代理可能采取具有现实世界后果的行动 成本与效率 | 每个任务需要50次API调用的代理可能不具备经济可行性

像"Volkswagen Golf 7-12年"这样精确的查询可能完美运行，但如果语义搜索层未经过适当评估，"我在找一辆更老的VW"这样的口语化变体可能会失败。

使用strands-agents-evals在部署前发现问题

该蓝图实现了映射到GenAIOps生命周期的两个阶段的评估。构建时评估可在部署前发现问题，生产评估则能捕捉合成测试遗漏的问题。下图（图2）展示了工具使用、推理和输出质量层必须通过的部署前流程。框架从三个层面评估代理：

• 第1层（工具使用）通过超过95%的阈值验证工具选择和参数传递的正确性。

• 第2层（推理）通过超过85%的阈值评估逻辑决策能力。

• 第3层（输出质量）通过超过90%的阈值衡量响应的有用性和准确性。只有三个层次全部通过后才能继续部署。

在开发和持续集成/持续部署（CI/CD）过程中，流水线使用strands-agents-evals框架在部署前捕获问题。该框架提供输出验证、轨迹评估、多轮对话模拟和自动化实验生成功能。所有功能均原生支持基于Strands Agents SDK构建的智能体。框架包含以下三种基本组件：

• 实验（Experiment）：对智能体执行的一组测试用例。
• 用例（Case）：输入查询、预期输出和预期工具调用轨迹。
• 评估器（Evaluator）：评分逻辑（确定性或基于LLM）。

将测试按层次结构组织。第1层运行确定性代码评分器以验证工具选择准确性。第2层和第3层使用LLM-as-judge评估器（通过LLM对智能体输出进行评分）评估推理质量和输出质量。

自定义Evaluator子类处理领域特定需求。对于Motorway智能体，这些需求包括数据新鲜度、经销商范围限定和安全防护措施。您的智能体将具有自己的领域约束。

三种评分器类型

评估框架使用三种评分器类型，分别适用于不同的评估需求。

| 评分器类型 | 层次 | 评估内容 | 折衷点 | |----------------------|--------|----------------------|--------------------------| | 基于代码的确定性评分器 | 第1层 | 工具选择、参数传递、轨迹顺序 | 快速、低成本、可复现 | | LLM-as-judge（Claude Sonnet 4.6） | 第2-3层 | 推理质量、输出有用性、目标达成 | 灵活；非确定性（通过pass^k控制） | | 人工审核 | 校准 | 边界情况和安全性 | 成本高；用于校准LLM评判提示 |

实践中，评估智能体生成的输出比评估其执行路径能发现更多问题。您关注的是用户是否获得相关结果，而非智能体首先调用了哪个工具。

三层评估框架

构建时评估在三个不同层次上运行，每个层次都有特定的通过/失败阈值。

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

• “£7,000至£20,000的柴油车”应使用search_vehicles工具并带类型化过滤器（fuel_type=diesel, min_price=7000, max_price=20000）。
• “现代低里程掀背车”应触发hybrid_search，结合语义嵌入和结构化过滤器。

您通过确定性方式衡量：ToolSelectionGrader检查调用的工具，TrajectoryOrderGrader验证调用顺序。

第2层：推理（>85%阈值） 决策过程是否符合逻辑？来自strands-agents-evals的HelpfulnessEvaluator和TrajectoryEvaluator使用LLM-as-judge评分评估智能体的推理是否自洽。通过非逻辑推理得出正确响应的智能体在条件变化时会不可预测地失败。

第3层：输出质量（>90%阈值） 响应是否具有帮助性、准确性和可操作性？来自strands-agents-evals的OutputEvaluator和GoalSuccessRateEvaluator使用LLM-as-judge评估用户是否获得有用且格式良好的响应。

三个层级必须在部署前通过。任一层级失败都会阻断整个流程。

处理非确定性

由于大语言模型输出在不同运行中存在差异，单次试验结果可能具有误导性。配套仓库中的 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。"

• 第2轮："现在只显示自动挡的。"

• 第3轮："那换成MPV呢？"

strands-agents-evals 框架提供 ActorSimulator 生成真实多轮交互，以及 InteractionsEvaluator 评估跨轮次上下文保持能力。多轮测试能捕捉单轮测试遗漏的上下文漂移、过滤累积错误和代词解析失败。

使用 AgentCore 评估监控生产行为

将 Strands Agent 部署到 Amazon Bedrock AgentCore Runtime 后，AgentCore 评估提供持续监控。它通过 OpenTelemetry（行业标准可观测性框架）与 Strands Agents 集成。图3展示了生产环境中的架构，可观测性追踪采样率为1-5%，指标聚合到 Amazon CloudWatch。

两种监控方式

AgentCore 评估提供两种互补模式：

按需评估通过从 Amazon CloudWatch 日志中选择跨度分析特定代理交互。这适用于调试问题或验证修复。

在线评估自动采样实时流量并在后台应用评估器。配置采样率（建议 1-5%），选择最多 10 个评估器后即可运行。

内置与自定义评估器

AgentCore 提供了针对常见场景预配置的评估器。下表展示了内置评估器及其评估内容。

评估器

级别

Builtin.Helpfulness

TRACE

衡量代理响应的有用性（0-1 分，共 7 个等级）

Builtin.GoalSuccessRate

SESSION

用户整体目标是否达成

Builtin.ToolSelection

TOOL_CALL

代理是否选择了适当的工具

Builtin.Correctness

响应的事实准确性

对于特定领域需求，可通过 LLM-as-a-judge 配置创建自定义评估器。每个代理都有内置评估器无法覆盖的领域约束，包括数据新鲜度、访问范围、禁止操作、延迟预算和成本限制。

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

验证内容

DataFreshnessEvaluator

验证拍卖周期时间戳，防止代理展示过时库存

SafetyGuardrailEvaluator

阻止代理执行自动化竞价操作

DealerDataScopingEvaluator

强制执行经销商范围查询以实现数据隔离

配套仓库包含 LatencyEvaluator 和 CostEvaluator 示例。

需要跟踪的关键指标

配套仓库包含一个 AWS CDK 堆栈，用于部署 CloudWatch 仪表板和告警。跟踪以下指标以监控代理健康状况。

指标

目标

告警阈值

任务完成率

95%

<80%

工具选择准确率

<90%

有用性评分（0-1）

0.83

<0.58

响应延迟 P50 / P99

<2s / <10s

5s / >15s

幻觉率

<2%

5%

每次交互成本

监控趋势

2倍基线值

将质量检查设为部署门禁

评估应作为部署流水线中的质量门禁，而非事后考虑。图 4 展示了包含评估门禁的部署流水线，涵盖构建时评估、预发布验证、影子模式、A/B 测试和生产发布，失败将阻止部署。

部署流水线包含五个阶段：

• 构建时评估：单元测试、工具正确性（ToolSelectionGrader >95%）、轨迹测试和 LLM-as-judge 评分（HelpfulnessEvaluator >85%）。

• 预发布验证：通过合成流量对预发布数据进行 AgentCore 评估。

• 影子模式：并行处理真实生产流量且不影响用户。至少运行 4 小时，偏差阈值设为 2%。

• A/B 测试：5% 的实时流量路由到候选代理以进行真实结果测量。

• 生产发布：100% 流量，持续在线评估和监控。

为每个阶段定义阈值：工具选择准确率低于 95% 或任务完成率低于 80% 将阻止部署。对于重大发布，使用 num_trials=5 的多轮评估通过 pass^k 检测非确定性故障。

影子模式

在预发布和生产之间，运行候选代理处理真实查询且不影响用户。影子模式接收生产流量的副本，通过候选代理并行处理并比较结果。在进入 A/B 测试前至少运行 4 小时。定义偏差阈值（2% 是良好起点），达到阈值时自动暂停部署。

影子模式能发现其他阶段遗漏的问题：

• 并发负载下的超时处理。

• 合成测试中缺少领域术语。

• 工具调用顺序在真实流量模式下导致延迟峰值。

入门：分阶段方法

阶段1：构建测试套件。从真实用户查询中选取20-50个测试用例。包含正向和负向案例。测试代理应执行的操作和应拒绝的操作。

阶段2：配置构建时评估。根据测量目标匹配评分器类型：工具选择使用确定性评分器，推理和输出质量使用LLM作为裁判。

阶段3：启用生产监控。使用1-5%的采样率配置AgentCore评估。从低采样率开始，确认评估器成本可接受后再逐步增加。

阶段4：闭环反馈。将生产故障转化为测试用例。当故障演变为回归测试时，这种反馈机制已持续提升团队评估质量。

结果与影响

实施评估流水线前，代理工具选择准确率为87%——这意味着每8个经销商查询中就有1个返回错误结果。团队每月遇到12起生产事故，问题影响经销商后平均需要4小时才能发现。

实施流水线后：

| 指标 | 实施前 | 实施后 | |------|--------|--------| | 工具选择准确率 | 87% | 98% | | 推理准确率 | 82% | 96% | | 上下文保留率（多轮对话） | 71% | 94% | | 生产事故（每月） | 12 | 2 | | 问题发现时间 | 数小时 | 数分钟 |

业务影响：经销商现在只需几分钟就能完成车辆搜索，而非数小时，且对结果的准确性和时效性充满信心。

故障排除

请参阅配套仓库的README文件，获取解决常见问题的方案，包括轨迹评分器失败、LLM作为裁判的方差、空评估结果和成本阈值调整等。

关键要点

构建评估流水线时请牢记这些原则：

• 分层评估：工具使用（>95%）、推理（>85%）和输出质量（>90%）可捕捉不同类型的故障模式。

• 以连续k次通过为标准，而非单次试验：每次试验75%的成功率意味着连续三次运行仅有42%的可靠性。

• 将生产故障转化为测试用例：让真实用户行为扩展你的评估套件。

• 阴影模式可捕捉合成测试遗漏的问题：真实流量可揭示超时处理、罕见术语和延迟模式。

• 从1%采样率开始监控：逐步扩展以控制评估器成本。

结论

您现在已了解如何在AWS上为生产AI代理构建评估流水线，Motorway的经销商库存搜索代理作为示例进行了演示。

核心要点：流畅的响应并不意味着代理做了正确的事。您必须验证工具选择、参数正确性、推理连贯性以及多次运行之间的一致性。通过结合构建时测试（strands-agents-evals）和生产监控（AgentCore评估），您可以部署有证据证明其按设计工作的代理。

这些模式适用于大多数多工具、面向客户的代理：无论您是在构建查询知识库和工单系统的客服代理，还是获取投资组合数据和市场行情的财务顾问代理，或是访问患者记录和排班工具的医疗分诊代理。

要开始：

• 克隆配套仓库：git clone https://github.com/aws-samples/sample-evaluating-agents-on-aws-with-strands-and-agentcore

• 导航到 CDK 项目目录：cd sample-evaluating-agents-on-aws-with-strands-and-agentcore/examples/vehicle-auction-agent/cdk

• 部署示例基础设施：按照仓库的 README 部署步骤部署示例基础设施。部署完成后，通过检查 AWS CloudFormation 控制台中所有 AWS CloudFormation 堆栈是否显示 CREATE_COMPLETE 状态来验证基础设施。你应该在各自的控制台中看到 CloudWatch 仪表板和 Lambda 函数列表。

• 运行包含的测试用例的示例评估套件，以查看三层框架的实际运行情况。通过确认以下内容验证成功：第 1 层（工具使用）的通过率高于 95%，第 2 层（推理）的通过率高于 85%，第 3 层（输出质量）的通过率高于 90%。如果某一层失败，请检查 CloudWatch 日志以获取详细的错误信息。

• 为你的领域自定义评估器。可以从 DataFreshnessEvaluator 和 SafetyGuardrailEvaluator 开始作为模板。

要深入了解，请查阅 Amazon Bedrock AgentCore 文档和 GitHub 上的 Strands Agents SDK。

清理资源

为了避免产生持续费用，请删除本教程中创建的资源：

• 销毁所有已部署的堆栈：cdk destroy --all

• 在提示时确认删除操作。

• 在 AWS 管理控制台中验证清理过程是否删除了所有资源，包括 Lambda 函数、S3 存储桶、DynamoDB 表、CloudWatch 日志组和仪表板、EventBridge 规则以及 SNS 主题。

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

资源

• 《为生产环境评估 AI 代理：Strands Evals 实践指南》

• Strands Agents SDK

• strands-agents-evals

• Amazon Bedrock AgentCore 评估

• 《评估 AI 代理：亚马逊的实战经验》

关于作者

'\"