评估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开源评估库
strands-agents-evals）和生产监控（使用Amazon Bedrock AgentCore Evaluations）。 - 三层评估框架：用于评估工具使用、推理和输出质量。
- 五阶段部署流水线：包含质量门禁，当指标低于阈值时会阻止发布。
我们还提供了一个配套仓库，包含可部署的蓝图，你可以根据自己的代理进行适配。虽然该蓝图使用了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 小时。
预估费用：运行示例评估套件在 Amazon Bedrock 推理上的费用约为 5–10 美元。生产环境的监控费用取决于采样率。
安全说明：随附仓库实现了最小权限的 AWS Identity and Access Management (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 代理后，经销商现在可以直接向代理提问：“帮我找找经销商附近 2.5 万美元以下的柴油 SUV”或“适合家庭、运动风格、自动挡的车”。高峰时段约有 1500 个并发用户，因此代理的行为准确与否至关重要——一次工具选择错误或语义搜索的误判，都会直接影响用户的信任度。
图 1 展示了端到端请求流程：经销商通过 Web 界面提交自然语言查询，该查询会路由到 Amazon Bedrock AgentCore Runtime。
运行时编排了对八个不同工具的调用，同时使用 Amazon Bedrock 模型（Claude 负责推理，Amazon Titan 负责嵌入）。工具响应流回运行时，生成最终面向经销商的结果。
为什么智能体评估不同
大语言模型（LLM）评估关注文本生成质量：连贯性、事实准确性、回答相关性。而智能体（Agent）评估要判断的东西完全不同。可以这样理解：LLM 评估好比检测引擎的性能，智能体评估则是看整车在交通拥堵、下雨天或者后排坐满乘客时，开起来怎么样。
传统的 LLM 指标不会告诉你：Motorway 智能体是否为“Grade 1 Suzuki models”调用了正确的搜索工具。它们不会揭示智能体是否向 LanceDB 传递了正确的过滤参数。它们也发现不了：如果一位经销商在上轮查询基础上细化结果，智能体是否给出了正确的回应。
| 评估维度 | 为什么对智能体重要 |
|---|---|
| 任务完成度 | 智能体运行多步工作流，部分完成是常见情况 |
| 工具使用正确性 | 用错工具或参数可能让整个工作流跑偏 |
| 推理连贯性 | 思路一乱，条件一变就容易出不可预见的故障 |
| 可靠性与一致性 | 非确定性意味着相同输入可能产生不同结果 |
| 安全与合规 | 自主智能体可能采取有实际后果的行动 |
| 成本与效率 | 某个任务如果智能体调用 50 次 API，经济上可能不划算 |
一个精确的查询如“Volkswagen Golf 车龄7-12年”可能完美工作，但口语化变体如“我想找一辆老款大众”可能因为语义搜索层未充分评估而失败。
在部署前用 strands-agents-evals 发现问题
这份蓝图在 GenAIOps 生命周期的两个阶段中实施评估：构建时评估在部署前发现隐患，生产评估则捕获合成测试遗漏的问题。下图（图2）展示了工具使用、推理和输出质量层必须在部署前通过检查。
）
因此，继续翻译：
以下图示（图2）展示了工具使用、推理和输出质量层如何必须在部署前通过检查。
评估 AI 代理：基于 Strands 和 AgentCore 的生产级蓝本
该框架从三个层面评估代理：第一层（工具使用） 验证工具选择和参数传递是否正确，通过阈值为大于 95%。第二层（推理） 评估逻辑决策能力，通过阈值为大于 85%。第三层（输出质量） 衡量回复的实用性和准确性，通过阈值为大于 90%。三个层面全部通过后，代理才能部署上线。在开发及持续集成/持续部署（CI/CD）流程中，该管道借助 strands-agents-evals 框架在部署前捕捉问题。它提供输出验证、轨迹评估、多轮对话模拟以及自动化实验生成等功能，每个功能都原生适配基于 Strands Agents SDK 构建的代理。
框架提供了三个基础组件：
- 实验（Experiment）：针对代理运行的一组测试用例集合。
- 用例（Case）：包含输入查询、预期输出和预期工具轨迹。
- 评估器（Evaluator）：评分逻辑（可以是确定性规则，也可以基于大语言模型）。
测试应按层级组织：第一层使用基于代码的确定性评分器来评估工具选择的准确性；第二和第三层则采用“大语言模型作为裁判”（LLM-as-judge）的评估器（即用一个大语言模型给代理的输出打分），来评估推理和输出质量。自定义的评估器子类可以处理领域特定的需求。以高速公路（Motorway）代理为例，这些涵盖了数据新鲜度、经销商范围和安全护栏——你的代理也会有自己领域的约束条件。
三种评分器
评估框架使用三种评分器，每种适用于不同的评估场景。
| 评分器类型 | 适用层级 | 衡量内容 | 权衡 |
|---|---|---|---|
| 基于代码的确定性评分 | 第一层 | 工具选择、参数传递、轨迹顺序 | 速度快、成本低、可复现 |
| 大语言模型作为裁判（Claude Sonnet 4.6） | 第二至三层 | 推理质量、输出有用性、目标达成度 | 灵活；非确定性（通过 pass^k 控制） |
| 人工审核 | 校准 | 边界情况和安全性 | 成本高；用于校准大语言模型裁判的提示词 |
在实践中，对代理产出的内容进行评分，比评分代理走过的路径能捕捉到更多问题。你真正关心的是用户是否得到了相关的结果，而不是代理先调用了哪个工具。
评估AI代理：基于Strands和AgentCore的生产蓝图
三层评估框架
构建时评估分为三个不同层次，每层都有明确的通过/失败阈值。
第1层：工具使用（阈值 > 95%）
代理是否调用了正确的工具并传入了正确的参数？例如，“7000到20000英镑的柴油车”应当调用 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 使用“大语言模型作为裁判”评估，判断用户是否得到了有用且格式良好的回答。
三个层次都必须在部署前通过。任何一层失败都会阻断管道。
处理非确定性
由于大语言模型的输出在不同运行之间会有差异，单次试验的结果可能具有误导性。配套仓库中的 run_all_layers() 函数接受 num_trials 参数来解决这一问题。来自代码生成研究社区的两个指标有助于衡量可靠性：
- pass@k：衡量在 k 次尝试中至少成功一次的概率。当找到一个正确解答就足够时，这个指标很有用。
- pass^k（pass的k次方）：衡量连续 k 次试验都成功的概率。当用户期望每次行为都可靠时，这个指标更有意义。
对于面向用户的代理，pass^k 最为重要。一次试验成功率75%的代理，连续三次试验都成功的概率只有42%（0.75³）。用户期望每次交互都获得一致的质量。
评估 AI 智能体：基于 Strands 和 AgentCore 的生产级测试方案
在配套代码中，run_all_layers(task_fn, registry, num_trials=5) 会执行多层评估，支持多次试验，并在通过 pass^k 标准后才允许上线。完整实现可查看源代码。
测试用例管理
测试用例按类别组织：
- Happy path（正常路径）：常见的、应该能正常处理的查询。
- Edge cases（边界情况）：模糊查询、俚语、多轮修改等。
- Safety/Guardrails（安全/护栏）：智能体应该拒绝或引导的查询。
当生产监控发现问题时，那次交互就会变成一个新增的测试用例。Motorway 的测试集在三个月内从最初的 50 个用例增长到 150 个，每个用例都基于真实用户行为。建议从 20 到 50 个用例起步，然后让生产数据驱动测试集增长。
务必包含负例用例——即智能体不应该调用某些工具的情况。例如，查询用户资料应该调用 profile 工具，而不是 search 工具；结构化的查询应该使用结构化搜索，而不是回退到原始 SQL。单方面的评估会导致单方面的优化。
多轮对话测试
单轮评估会漏掉一个关键维度：对话连贯性。汽车经销商的用户自然会跨多轮细化搜索：
- 第1轮：“帮我找柴油SUV。”
- 第2轮：“现在只看自动挡的。”
- 第3轮：“那旅行车呢？”
strands-agents-evals 框架提供了 ActorSimulator（角色模拟器），用来生成逼真的多轮交互，还有 InteractionsEvaluator（交互评估器），用来评估跨轮次的上下文保持能力。多轮测试能捕捉到单轮测试发现不了的问题：上下文漂移、筛选条件累积错误、代词指代失败等。
用 AgentCore 评估监控生产行为
当你把 Strands Agent 部署到 Amazon Bedrock AgentCore Runtime 后，AgentCore Evaluations 会提供持续监控。它通过 OpenTelemetry 工具（行业标准的可观测性框架）与 Strands Agents 集成。图3展示了生产环境下的架构：可观测性跟踪以 1–5% 的采样率抽取，指标汇总到 Amazon CloudWatch。
两种监控模式
AgentCore Evaluations 提供两种互补的模式：
- 按需评估：从 Amazon CloudWatch 日志中选择相应的 span，分析特定的智能体交互。
- ...（后续内容可能包含第二种模式，但本段只到这里，按要求不补充）