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

本文与Motorway以及AWS原型设计和AI客户工程（PACE）团队共同撰写。

Motorway是一家总部位于英国的在线汽车市场，每天运行一场拍卖，多达8,000家经销商对多达2,500辆汽车进行竞价。Motorway与AWS 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 S3、Amazon DynamoDB、Amazon EventBridge、Amazon CloudWatch和Amazon SNS权限的AWS账户。

已安装并引导AWS CDK v2。

Python 3.14+。

通过Amazon Bedrock模型访问获得Anthropic Claude模型和Amazon Titan模型的访问权限。

熟悉Python、AWS CDK和代理概念（工具调用、多轮对话）。

完成时间：初始部署30-45分钟，为您的域定制2-3小时。

预估成本：运行示例评估套件大约需要5-10美元的Amazon Bedrock推理费用。生产监控成本因采样率而异。

安全说明：附带存储库实现了最低权限的AWS 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”或“适合家庭、运动且自动挡的车”。

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

为什么代理评估不同

LLM评估侧重于文本生成质量：连贯性、事实准确性、响应相关性。代理评估评估的是根本不同的东西。可以这样理解：LLM评估检查发动机性能。代理评估评估整辆车在交通中、雨天或满载乘客时的驾驶表现。

传统的LLM指标无法告诉您Motorway代理是否为“Grade 1 Suzuki车型”调用了正确的搜索工具。它们无法揭示代理是否向LanceDB传递了正确的过滤参数。它们还错过了经销商从上一轮细化结果时是否得到正确响应。

评估维度 为什么它对代理很重要

任务完成 代理运行多步骤工作流，部分完成很常见

工具使用正确性 错误的工具或错误参数可能破坏整个工作流

推理连贯性 有缺陷的推理导致条件变化时不可预测的失败

可靠性和一致性 非确定性意味着相同输入可能产生不同输出

安全性和合规性 自主代理可能采取有现实世界后果的行动

成本和效率 每个任务需要50次API调用的代理可能在经济上不可行

精确查询如“大众高尔夫7-12年车龄”可能完美工作，但口语化变体如“我在找一辆较旧的大众”可能在语义搜索层未正确评估时失败。

在部署前使用strands-agents-evals捕获问题

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

第1层（工具使用）：验证正确的工具选择和参数传递，阈值大于95%。

第2层（推理）：评估逻辑决策，阈值大于85%。

第3层（输出质量）：测量响应帮助性和准确性，阈值大于90%。所有三层必须通过才能继续部署。

在开发和CI/CD期间，管道使用strands-agents-evals框架在部署前捕获问题。它提供输出验证、轨迹评估、多轮对话模拟和自动实验生成。每个都旨在与基于Strands Agents SDK构建的代理原生工作。该框架提供三个原语：

实验：针对代理运行的测试用例集合。

案例：输入查询、预期输出和预期工具轨迹。

评估器：评分逻辑（确定性或基于LLM）。

将测试组织成层。第1层运行确定性基于代码的评分器，用于工具选择准确性。第2层和第3层使用LLM作为评判评估器（使用LLM对代理输出评分）进行推理和输出质量。

自定义评估器子类处理特定域的问题。对于Motorway代理，这些涵盖数据新鲜度、经销商范围和安全护栏。您的代理会有自己的域约束。

三种类型的评分器

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

评分器类型 层 测量内容 权衡

基于代码的确定性 第1层 工具选择、参数传递、轨迹顺序 快速、廉价、可重复

LLM作为评判（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%阈值）。决策过程是否逻辑？HelpfulnessEvaluator和TrajectoryEvaluator使用LLM作为评判评分来评估代理的推理是否合理。通过不合理推理得到正确响应的代理将在条件变化时不可预测地失败。

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

三层必须在部署前通过。某一层失败会阻塞管道。

处理非确定性

由于LLM输出在不同运行之间变化，单次测试结果可能具有误导性。附带存储库中的run_all_layers()函数接受num_trials参数来解决这个问题。来自代码生成研究社区的两个指标有助于衡量可靠性：

pass@k衡量在k次尝试中至少成功一次的可能性。当找到一个正确解决方案就足够时，此指标很有用。

pass^k衡量在k次连续试验中成功的概率。当用户期望每次行为都可靠时，此指标很有用。

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

在附带代码中，run_all_layers(task_fn, registry, num_trials=5)运行具有多试验支持并基于pass^k门控部署的评估层。请参阅完整实现。

测试用例管理

测试用例按类别组织：

快乐路径：应成功的常见查询。

边界情况：模糊查询、俚语、多轮细化。

安全/护栏：代理应拒绝或重定向的查询。

当生产监控检测到问题时，该交互成为新的测试用例。Motorway的测试套件在三个月内从最初的50个案例增长到150个，每个都基于真实用户行为。从20到50个案例开始，让生产数据增长套件。

包括负面案例，即代理不应调用某些工具的情况。例如，配置文件查询应调用配置文件工具，而不是搜索工具。结构化查询应使用结构化搜索，而不是原始SQL回退。单方面评估会导致单方面优化。

多轮对话测试

单轮评估遗漏了一个关键维度：对话连贯性。经销商自然地在多轮中细化搜索：

第1轮：“找一下柴油SUV。”

第2轮：“现在只显示自动挡的。”

第3轮：“看看旅行版呢？”

（文末因成本控制截断）