用 Strands Evals 和 Amazon Bedrock AgentCore 评估配备技能的智能体

通用型智能体能够处理广泛的任务，但你仍然需要它们遵循支撑业务运转的各项流程：合规检查、文档处理工作流、升级策略、工程规范。把这一切都编码进一个系统提示词或应用逻辑中，会变得难以维护和更新。技能（Skills）是一种模块化的替代方案。技能是一组可复用的指令，通常存储在 SKILL.md 文件中，用于教会智能体执行某项特定领域的任务，例如对合同进行脱敏、核对发票，或遵循团队的拉取请求（pull-request）规范。由于技能遵循开放的 Agent Skills 标准，它们可以在兼容的执行框架（harness）之间移植，并且智能体在运行时只加载它所需的技能，而不必把所有流程都塞进其核心指令中。

一个技能将一个或多个工具与智能体正确使用这些工具所需的上下文打包在一起：

指令：注入智能体上下文的领域特定指导与约束；工具绑定：技能所依赖的 API、Model Context Protocol（MCP）服务器或本地命令；知识：参考资料与示例；工作流：技能所遵循的多步骤流程或决策逻辑；护栏：格式要求、范围限制与校验规则

这种模块化方法帮助团队更快地专精智能体、在多个智能体和工作流之间复用经过验证的流程、保持行为一致，并在无需微调底层模型或重写智能体核心逻辑的情况下更新领域特定指导。

智能体中的这种技能可组合性引入了两种通用输出质量指标可能遗漏的失败模式：智能体调用了不适合该任务的技能，以及智能体调用了正确的技能但跳过或仅部分遵循了其指令。这两种失败都可能产生流畅、看似合理的回复，却并未使用你预先确定的领域知识。因此，评估不能只检查最终回复。

为了让这些失败可度量，Strands Evals SDK 和 Amazon Bedrock AgentCore Evaluations（Amazon Bedrock AgentCore 的一项能力）新增了以技能为中心的评估器：

Skill Selection Accuracy 判断每个被调用的技能对该任务是否是一个合适的选择。它为每个被调用的技能返回一个二元结果；Skill Instruction Following 判断智能体在多大程度上完整遵循了被调用技能的指令。它基于证据为每个规定步骤返回一个五级评分；此外，在 Strands Evals 上，Skill Invoked 是一项确定性检查，用于判断某个具名技能是否已成功加载

在本文中，你将学习如何通过 AgentCore CLI，从 Strands Evals 中记录的轨迹评估技能选择与指令遵循情况、向测试套件添加确定性路由检查、使用 AgentCore Evaluations 从 OpenTelemetry trace 评估技能行为，并解读每个技能的结果以选择正确的修复方案。

了解每个评估器衡量什么

智能体接收一个任务和一份技能目录，选择一个技能、加载它并执行操作。该运行过程在 Strands Evals 中记录为轨迹，或在你的可观测性层中记录为 OpenTelemetry trace。这条记录现在可用于全部三个技能评估器。Skill Selection Accuracy 检查每个被调用的技能是否契合该任务，以及智能体是否调用了正确的技能。下图展示了智能体如何从提供给它的 1:n 个技能中选择一个技能。随后，Skill Selection Accuracy 对该所选技能是否为该任务的正确技能进行评分。你可以在提示词模板文档中找到该评估器的提示词模板和评分标准。

图 1：Skill Selection Accuracy 检查智能体是否为该任务选择了合适的技能

Skill Instruction Following 询问智能体在多大程度上完整遵循了该技能规定的步骤。你可以在提示词模板文档中找到该评估器的提示词模板和评分标准。

图 2：Skill Instruction Following 衡量智能体在多大程度上完整遵循了技能的步骤

SkillInvoked 是确定性的。它不调用任何模型，且仅适用于 Strands Evals。

下图以图解方式展示了这些技能评估器的概览。

图 3：三个技能评估器的概览

设想一个 HR 助理智能体，它具备带薪休假（PTO）规划和讨论员工福利的技能。一名员工询问其牙科和视力福利。如果智能体调用了福利技能，它可能会生成更完善的回复。如果工具调用成功但智能体选错了操作手册，Skill Selection Accuracy 就能定位该路由决策。

现在假设智能体针对一个相关请求正确调用了 PTO 规划技能。该技能指示智能体识别 employee_id、检查 PTO 余额、对照最新 HR 政策检查结转规则，然后在条件允许时提交 PTO 请求。如果智能体检查了 PTO 余额但跳过了结转规则，智能体仍可能返回看似合理的回复，同时违反了规定的流程。Skill Instruction Following 会隔离该执行失败并识别出被跳过的步骤。

这些失败需要不同的修复方式。不恰当的选择通常指向重叠或含糊的技能描述。不完整的指令遵循可能需要更清晰的步骤、不同的技能结构，或能力更强的智能体模型。

由于基于评判器的评估器会返回每个被调用技能的结果，多技能运行仍然可诊断：你可以识别出是哪个选择结果或指令遵循结果拉低了聚合分数。如果没有调用任何技能，基于评判器的评估器不会产生分数。当回归测试具有已知的路由要求时，将它们与 SkillInvoked 搭配使用。

先决条件

Python 3.10 或更高版本；一个具有 Amazon Bedrock 访问权限的 AWS 账户，以及具有评判器模型 InvokeModel 权限的凭证

要跟随 Strands Evals 部分，请安装这些 SDK：

你还需要一次已记录的智能体运行。技能评估器接受 Strands Evals Session 或原始消息列表作为轨迹。在发布时，技能提取可识别来自 Strands AgentSkills 插件、Claude Code、Claude Agent SDK、OpenAI Agents SDK、Codex、Gemini CLI、OpenHands、Google ADK 以及通用 SKILL.md 文件读取的信号。

要跟随 AgentCore Evaluations 部分，你需要：

一个托管在 Amazon Bedrock AgentCore 运行时或其他位置的智能体。我们将使用 HR 助理智能体的示例，你可以将其部署到你的账户中；为该智能体启用可观测性，以便它将遥测数据发送到 Amazon CloudWatch；在 CloudWatch 中启用 Transaction Search

本文中的示例使用 AgentCore CLI：

使用 Strands Evals 评估已记录的轨迹

当你控制测试用例并可以在开发或持续集成期间重新运行智能体时，Strands Evals 很有用。请查看为 HR 助理智能体创建的完整 Strands evals 代码示例，见完整代码示例。

1. 定义用例和评估器

2. 运行智能体并捕获其轨迹

技能评估器读取运行的轨迹。TracedHandler 收集智能体的 span 并将其作为轨迹附加：

3. 解读报告

假设智能体加载了 pdf-table-extraction，运行了 pdftotext -layout，但从未打开提取出的文件，也没有定位表格边界。一个简化报告如下：

Skill Instruction Following 使用五个评级：完全遵循（1.0）、大部分遵循（0.75）、部分遵循（0.5）、最低限度遵循（0.25）和未遵循（0.0）。它在“大部分遵循”或更好时通过。

将检查转化为部署门禁

为特定回归用例必须调用的每个关键技能添加 SkillInvoked。由于它不调用模型，因此是一种快速的路由断言；基于 report.test_passes 对构建设置门禁：if not all(report.test_passes): raise SystemExit(1)；使用聚合分数跟踪更广泛的趋势，但在强制执行阈值之前，请在你自己的用例上校准该阈值

使用 AgentCore Evaluations 评估生产轨迹

AgentCore Evaluations 可直接处理现有的 OpenTelemetry trace，支持按需评估、对已存储会话进行批处理，以及对实时流量进行持续采样。遥测数据按会话、trace 和 span 组织。由于技能评估器在工具调用级别运行，每个结果都包含一个 spanContext，其中带有被识别技能调用的 sessionId、traceId 和 spanId。

技能调用可通过 SKILL.md 文件系统读取（可跨框架工作）或 Strands Agents、LangGraph Deep Agents、Google ADK 或 Claude Agent SDK 中的原生技能加载工具来识别。

自定义评估器的 trace 占位符

AgentCore Evaluations 包含两个内置的基于评判器的技能评估器。要对内置评估器未覆盖的内容进行评分，请在 TOOL_CALL 级别创建自定义评估器。工具级模板可以引用技能占位符：

例如，一个检查技能运行某一特定属性的模板：

你引用的占位符也决定了评估器何时运行。包含 {invoked_skill} 的模板仅在技能调用 span 上运行，而包含 {skill_content} 的模板还要求已加载的技能正文。

以下命令针对单独的启用技能的运行时。请用 skills-evaluation/agent_config.json 中的运行时名称（agent_id 或 agent_arn）替换 。Strands.SkillInvoked 仅限客户端使用，没有 CLI 等效项。

运行按需评估

使用按需评估来调查某个会话、验证最近的更改，或评估暂存流量：

运行批量评估

使用批量评估一次性对许多已存储会话进行评分，例如在技能目录变更前建立基线：

配置持续在线评估

在线评估会对实时流量进行采样，因此你可以发现精心策划的测试集未能预料到的行为：

然后部署以配置在线评估：

持续评估对于检测目录漂移（当新技能与现有描述重叠时）、意外措辞（当真实请求与精心策划的测试提示不同时）以及长会话失败（当指令遵循能力随着上下文增长而下降时）特别有用。

最佳实践

在评估智能体技能时，首先要内化的一点是：路由和执行是两种不同的失败模式，而你的评估策略需要将它们清晰地区分开来。如果你看到高选择分数但低指令遵循分数，这表明路由器选择了正确的技能，但该技能没有被完整执行。相反的模式则意味着，只要该技能被调用，它本可以正常工作。将这两项评估一起运行，而不是将它们合并为一个通过/失败的数字，正是这一点让你能够区分这两种情况。

在构建任何自定义内容之前，先从内置评估器开始建立基线，这样你之后添加的任何自定义逻辑都可以覆盖基线实际遗漏的差距。对于你已经知道正确路由行为的需求，不要依赖评判模型来捕捉它。为每个必须触发的技能添加一个确定性的 SkillInvoked 断言。

在运行评估之后，不要只盯着聚合分数。逐步证据才是真正进行诊断的地方。它会告诉你一条指令是被完全覆盖、部分完成还是被直接跳过，而这种细节程度正是将失败的评估转化为可操作修复的关键。这也是为什么你应该在每个生命周期阶段进行评估，而不是等待最终输出。最终阶段的失败并不能告诉你，是路由器将请求发送到了错误的地方，还是正确的技能执行得很差，而你需要这两个信号才能知道要修复什么。

技能级评估和端到端评估应该配对进行，因为一个技能可以完美执行，但仍然不是当前请求所需的正确技能。通过编写真正具有区分度的技能描述，你可以在上游减少大量这种模糊性。同样的逻辑也适用于技能的范围。一个为处理六个不相关功能而构建的技能没有单一的正确行为定义，这使得几乎不可能一致地评估它。

明确说明只应评估给定运行中实际采用的路径，否则未采用的分支会被错误地计为跳过的步骤，并悄悄破坏你的通过率。而且，在你信任这些分数之前，请验证你的提取管道确实能对实时 trace 正常工作。

当你在各种工具上扩展这一做法时，阈值可能无法干净地迁移。每个评估面都需要按照自身的情况进行校准，因为在 Strands Evals 上通过的分数和在 AgentCore Evaluations 上通过的分数并不保证意味着同一件事。归根结底，这些都不应该存在于你的部署管道之外。技能质量回归需要像失败的单元测试一样阻止发布，否则你到目前为止所做的评估工作实际上并没有保护生产环境。

结论

技能让智能体的专业化变得成本低廉，但一个看似合理的最终答案并不能证明智能体选择了正确的流程或遵循了它。Skill Selection Accuracy 和 Skill Instruction Following 将这些失败模式区分开来，并为每个被调用的技能返回证据。在 Strands Evals 中，SkillInvoked 为已知的路由需求添加了一个确定性的防护。在 AgentCore Evaluations 中，这两个基于评判器的指标可以针对特定会话按需运行、对已存储会话进行批量运行，或对采样流量持续运行。

当你拥有可以重新运行的测试用例和记录的轨迹时，使用 Strands Evals。当你想要评估来自暂存或实时智能体的 OpenTelemetry trace 时，使用 AgentCore Evaluations。许多团队会两者都用：在部署前使用确定性和基于评判器的门禁，然后在生产环境中进行基于 trace 的监控。

Strands Evals 快速入门；Strands Evals 仓库；Amazon Bedrock AgentCore Evaluations 开发者指南；评估 AI 智能体博客文章

致谢

感谢 Ritvika Pillai、Vincent Chen、Qiaoxuan Xue 和 Shoaib Javed 对 AgentCore Evaluations 的实现，感谢 Po-Shin Chen 对 Strands Evals 的评审，感谢 Anwesan Pal 就技能评估进行的早期讨论，感谢 Ben Coombs 的产品指导，也感谢所有其他帮助促成这项工作的人。

关于作者

Sangmin Woo

Sangmin 是 AWS AI Labs 的应用科学家，他在那里开展研究并开发面向智能体 AI 的机器学习解决方案，重点关注评估框架以及提升智能体的行为与性能。他的研究兴趣包括智能体 AI、生成模型和多模态 AI。工作之余，他喜欢旅行和探索新地方。

Bharathi Srinivasan

Bharathi 是 AWS 的生成式 AI 数据科学家。她热衷于负责任 AI，以提高 AI 智能体在真实场景中的可靠性。Bharathi 指导内部团队和 AWS 客户走上负责任 AI 之旅。

Shruthi Rajoli

Shruthi 是 AWS 的解决方案架构师，常驻伊利诺伊州芝加哥。她与美国东部地区的初创公司合作，帮助早期和成长期公司设计并构建可扩展的 AWS 云架构，重点关注生成式 AI、智能体 AI 工作流、数据和迁移工作负载。工作之余，她喜欢散步、瑜伽，以及探索新的美食和咖啡店。

Visakh Madathil

Visakh 是 AWS 的解决方案架构师，与客户和内部团队合作，为生产环境中的人工智能（AI）带来可读性、可信度和可靠性。他在智能体可靠性和 AI 安全方面的工作已在机器学习会议上展示。工作之余，他喜欢音乐、观鸟和运动。

Renu Rozera

Renu 是 Amazon Web Services 的软件开发工程师，从事 Amazon Bedrock AgentCore 相关工作。她此前参与构建了 AgentCore Memory，现在专注于为 AgentCore Evaluations 与优化开发可扩展系统，帮助客户评估并持续改进其智能体应用的质量。

Vinayak Arannil

Vinayak 是 Amazon Web Services 的资深应用科学家。凭借多年经验，他涉足 AI 的多个领域，如计算机视觉、自然语言处理、推荐系统等。目前，Vinayak 帮助在 AgentCore 和 Strands 上构建新能力，使客户能够轻松、准确且高效地评估其智能体应用。

Haibo Ding

Haibo 是 Amazon 的的首席应用科学家兼经理，从事智能体 AI 相关工作。他拥有犹他大学博士学位。他的工作聚焦于大语言模型（LLM）和 AI 智能体，领导智能体评估、智能体工具优化、提示优化和模型路由等领域的研究。他曾担任 AAAI 和 ACL 等会议的区域主席，此前还担任 KDD 2025 提示优化研讨会的程序主席。

Jonathan Buck

Jonathan 是 AWS 的资深软件工程师。他构建智能体环境、评估框架和后训练基础设施，帮助将智能体 AI 的进步转化为可靠的生产系统。