用 Strands Evals 和 Amazon Bedrock AgentCore 测 Agent 技能调用到底准不准

把所有业务逻辑、合规检查、文档处理流程全塞进 System Prompt 简直是自虐，维护起来想死。现在比较舒服的方案是把这些 domain-specific 的任务做成模块化的 Skill，存成 SKILL.md。这样 Agent 运行的时候按需加载，不用每次都背着一坨沉重的指令集。

但这种模块化方案有个大坑：Agent 很容易在调用环节掉链子。最典型的就是两种失败模式：要么它选错了 Skill，要么它选对了但没完全按照 SKILL.md 里的步骤走。最恶心的是，它给出的最终答案看起来非常流畅，如果你只看最终输出（Final Response），你根本发现不了它其实跳过了关键的合规步骤。

为了量化这种失败，我尝试用 Strands Evals SDK 和 Amazon Bedrock AgentCore 的评估能力来跑测试，这套组合提供了三个关键的衡量维度：

• Skill Selection Accuracy：这是一个二值结果（0 或 1），直接判定 Agent 选的这个 Skill 到底对不对。
• Skill Instruction Following：这个比较细，它会对指令里的每个步骤进行证据核对，给出一个五级评分，看 Agent 到底执行了多少。
• Skill Invoked（仅限 Strands Evals）：一个确定性检查，确认某个命名的 Skill 是否真的加载成功了。

在实际操作中，这些评估不是看最终结果，而是分析轨迹（Trajectory）或 OpenTelemetry 追踪记录。

具体怎么落地这套评估，我总结了几个关键点：

怎么通过轨迹记录排查调用错误

如果你在 Strands Evals 里记录了 Agent 的运行轨迹，可以通过 AgentCore CLI 来分析。最核心的逻辑是把运行记录作为输入，让评估器去对比 SKILL.md 里的预期步骤和实际执行的 Trace。

如果发现 Skill Selection Accuracy 分数低，通常是 Skill 的描述（Description）写得不够清晰，导致模型在路由阶段产生了歧义。如果 Selection 对了但 Instruction Following 分数低，那就是指令写得太模糊，或者模型在多步执行时产生了漂移。

利用 AgentCore Evaluations 处理 OpenTelemetry Trace

对于已经在生产环境下跑的 Agent，直接对接 OpenTelemetry trace 是最高效的。Amazon Bedrock AgentCore Evaluations 可以直接解析这些 trace。

具体的评估流程是：
1. 收集包含 Skill 调用信息的 OpenTelemetry trace。
2. 使用 AgentCore CLI 运行对应的评估命令。
3. 查看每项 Skill 的详细评分。

这种方式能让你快速定位到是哪个具体的 Skill 在哪个环节掉链子，而不是对着一个模糊的“质量下降”结论发呆。

确定性路由检查的配置

为了防止 Agent 在关键业务路径上乱跑，可以在测试套件中加入确定性路由检查。这意味着你预先定义好：对于输入 A，必须触发 Skill B。

如果在这个环节报错，你可以直接核对：

• 检查 SKILL.md 是否被正确加载（通过 Skill Invoked 检查）。
• 确认工具绑定（Tool bindings）是否生效，包括 API、MCP 服务器或本地命令是否响应。
• 核对 Knowledge 引用材料是否在上下文中被正确检索。

这种从“结果评估”转向“过程评估”的思路，比单纯跑个 Benchmark 要实用得多。