Amazon Bedrock AgentCore 技能评估揭示流畅型智能体掩盖的问题
Amazon 于 9 月 22 日推出 Amazon Bedrock AgentCore 技能评估，新增三项检查，用于审视智能体在给出精致最终答案之外的行为。此次发布瞄准了测试中的一个长期盲区：智能体即使选错技能、跳过必需步骤，或围绕业务流程临场发挥，依然可能表现得言之有理。
这些新评估器将团队常常合并为一个分数的两个问题区分开来：智能体是否选择了合适的技能，以及加载该技能后是否遵循了它？对于已经明确知道测试应调用哪个命名技能的团队，Strands Evals 还增加了第三项确定性检查。
这一差异对那些仅以响应质量为核心的评估体系提出了挑战。帮助性、相关性和正确性依然重要，但它们无法揭示所有路由或执行失败。如今真正的较量，是最终答案评分与智能体如何得出答案这一过程层面证据之间的较量。
Amazon Bedrock AgentCore 技能评估将一次失败拆分为三类
AWS 正将技能使用转化为可衡量的序列，而非将最终响应视为成功的充分证据。
技能是一套可复用的指令包，用于教会智能体执行专业流程。它通常包含一个 SKILL.md 文件，说明其用途、激活指引和必需步骤。运行框架会提供可用技能，而智能体则决定应为某项请求加载哪一个。
这一结构让开发者能将详细流程从不断膨胀的系统提示词中移出。一家公司可以为发票对账、合同脱敏、事件升级或拉取请求审查分别创建技能。智能体在需要时加载相关指令，而不必在每一次交互中都携带全部流程。
可移植性也是其吸引力所在。开放的 Agent Skills 格式为兼容的智能体环境提供了统一的专业指令打包方式。因此，技能可以成为一种运营资产，而不只是绑定于某一次模型调用的提示词片段。
不过，模块化指令也引入了一连串决策。智能体必须识别用户意图、找到合适技能、调用该技能、阅读其内容，并完成规定步骤。一段出色的最终文字并不能证明这一链条运作正常。
根据 9 月 22 日发布的技能评估公告，AWS 与 Strands 团队现在将这条链路拆分为三种评估器。
技能选择准确率会询问每个被调用的技能是否适合该任务。它会为每个被调用技能返回二元结果。当智能体加载了原本用于另一工作流的指令时，这让路由错误变得可见。
技能指令遵循度考察智能体完成被调用技能规定步骤的完整程度。它提供五个评级：完全遵循、大部分遵循、部分遵循、最低限度遵循和未遵循。文档中对应的数值从 1.0 到 0.0，以 0.25 为增量递减。
技能调用则是 Strands Evals 中一项更窄、确定性的断言。它检查智能体是否成功加载了某个命名技能。与前两项评估器不同，它不会要求模型判断适切性或遵循程度。
这些指标回答的是不同问题。一个必需的薪资处理技能可能从未被加载，形成路由失败；它可能因无关的差旅请求而被加载，形成选择失败；它也可能被正确加载，却遗漏审批步骤，形成指令遵循失败。
这种拆分是核心变化。团队不再需要将每个不佳结果都解读为模糊的智能体质量问题，而是可以将每种模式关联到不同组件，并采取更有针对性的修复措施。
未调用技能意味着应检查发现规则、描述或路由逻辑。不恰当的调用则表明技能范围存在重叠。已正确选择的技能却有较低遵循度，则应将注意力转向其步骤、结构、可用工具或底层模型。
此次发布并未取代现有的质量评估。它为行为依赖动态加载流程的智能体增加了一层评估。输出准确性依然必不可少，但它成为更完整测试记录的一部分。
流畅的答案不再是充分证据
过程轨迹评估最有力的论点很简单：不同的内部失败都可能产出同样令人信服的文字。
设想一名员工要求智能体在对外共享前对合同进行脱敏。智能体可能删除明显的人名，并返回一份看起来干净的文档。然而，获批准的技能还可能要求检查元数据、隐藏评论、修订痕迹和附件引用。
只看到最终文档的审阅者可能会忽略这些被跳过的检查。响应看似专业，却违反了组织实际的数据处理流程。技能指令遵循度正是为将记录下来的行为与各项规定步骤进行比对而设计。
同样的问题也会出现在财务运营中。一个发票对账智能体可能通过非正式推理得出正确总额。如果技能要求验证供应商身份和采购授权，这一结果在流程上依然不完整。
合规要求使这种差异尤其重要。组织通常不只关心某个答案是否恰好可接受，还需要证据证明可重复的控制措施已在规定的顺序和场景下执行。
传统软件测试为确定性函数提供精确预期。智能体则不同，因为相同提示词可能引出不同的语言、工具调用和推理路径。AWS 此前曾指出，一次通过的运行只说明可能发生什么，而不能说明通常会发生什么。
这种可变性使汇总响应分数颇具诱惑力。团队可以在数据集上平均正确性或帮助性，并追踪数字是否上升。然而，平均值会掩盖工作流在哪个环节失败，以及同一步骤是否持续消失。
按技能划分的结果提供了更有用的诊断单位。当智能体在一次会话中调用多个技能时，评估器会为每次调用返回结果。因此，较弱的汇总结果可以追溯到拉低分数的具体技能。
这一方法也会改变团队编写技能的方式。一段模糊的文字可能便于人类作者理解，却难以被稳定评估。编号清晰、可观察的步骤能为评判模型提供更明确证据，也更容易识别遗漏。
这并不意味着每一个内部思考过程都会变得可见。评估依赖于记录下来的轨迹和追踪信息，包括可见消息、技能加载操作和工具调用。私有的模型推理既不需要，也不会被暴露。
相关证据是运营层面的：智能体是否加载了技能？它选择了哪个技能？记录的操作是否显示它完成了规定检查？这些证据比对隐藏推理的猜测更具可操作性。
这种转变类似于检查一项完成的计算与审计其周围控制措施之间的区别。两种视角都重要，但它们回答不同的问题：一个衡量产物，另一个衡量产生该产物的过程。
对于构建内部智能体的团队而言，流程往往承载着更大的组织风险。流畅的答案或许能一次性满足用户；被跳过的审批、披露或验证步骤，却可能在相同条件反复出现时每次都损害工作流。
新评估器让这种流程缺口更容易被清晰界定。它们也会推动其他智能体平台暴露兼容的轨迹信息。没有可观察的技能事件，团队便无法有把握地区分未调用技能与提取失败。
Strands Evals 将检查带入开发阶段
Strands Evals 为开发者提供本地测试层，用于在生产流量成为测试套件之前验证技能路由和执行。
Strands Evals 是一个用于评估智能体和语言模型应用的开源框架。其已发布的能力包括输出评分、轨迹分析、工具评估、模拟、实验和基于追踪的评估。
该项目的评估仓库现已记录全部三项技能检查。开发者可以针对已记录的会话或原始消息轨迹运行技能选择准确率和技能指令遵循度。
基于评判模型的评估器读取轨迹，而不是重新运行智能体。这支持在失败后开展调查，并对保存的会话进行比较。它也将成本较高的智能体执行，与对同一记录进行的重复分析分离开来。
技能调用服务于另一种测试需求。如果一个回归用例有已知的单一路由要求，开发者可以断言预期技能已被加载。这项检查具有确定性，不需要评判模型。
这使其适合作为发布门槛。涉及账户关闭的客户支持请求应稳定地加载经批准的关闭技能。如果修订后的描述阻止了调用，回归测试便可在部署前失败。
当多个技能都可能合理适用时，选择准确率仍然很有价值。它询问被调用的技能是否适合任务，而非只与一个固定名称比较。这种灵活性适用于包含相关流程和合理路由变化的技能目录。
随后，指令遵循度会测试下一阶段。评估器识别已加载技能中的规定步骤，并将每一步标记为已覆盖、部分完成或跳过。它利用这些判断生成五级总体评级。
这种组合形成了一个紧凑的测试矩阵。
高选择分数但指令遵循度较弱，意味着路由正常但执行不佳。智能体找到了正确流程，却跳过或只部分完成了其要求。
选择较弱但指令遵循度较强，意味着智能体遵循了已加载流程，但该流程并不适用于这项请求。改进技能内部措辞无法解决这一路由错误。
未调用技能需要特别处理。AWS 指出，当没有任何技能被调用时，两个基于评判模型的评估器不会返回分数。若某个命名技能是强制要求，团队应将它们与技能调用检查结合使用。
这种行为避免了误导性的成功。评估器无法判断从未加载的指令是否被遵循。然而，除非测试套件明确将未调用视为失败，否则空结果可能消失在仪表盘中。
Strands 也为运行框架带来了埋点负担。其提取器必须能从轨迹中识别可用技能和已选技能。该项目支持多种已知环境，以及读取 SKILL.md 文件这一通用模式。
开发者应在信任分数前验证提取过程。技能信号无法被识别的运行框架，即使智能体使用了技能，也可能产生空结果。这是可观测性缺口，而非行为正确的证据。
这一注意事项对集成自定义编排层的团队很重要。评估质量取决于对事件的忠实记录。在团队先验证遥测契约之前，一个缺失的追踪属性可能看起来与智能体遗漏操作无异。
因此，开发工作流包含两个阶段。首先，确认评估器能够看到技能目录、调用情况、技能内容及后续操作。其次，衡量这些操作是否符合任务要求并满足指令。
对于维护本地技术工作流的工程团队而言，这项变化也进一步凸显了可搜索的工程知识库的价值。技能可以编码流程，而持续维护的源材料则提供这些流程所依赖的事实。
AgentCore 将技能评估引入生产追踪
AgentCore 将同样的路由与遵循问题，从精选测试扩展到分阶段会话和抽样的实时流量。
Amazon Bedrock AgentCore Evaluations 是一项托管服务，用于评估智能体在开发和生产环境中的行为。它会使用 OpenTelemetry 追踪记录，其中包含模型调用、工具使用和智能体操作等结构化事件。
OpenTelemetry 很重要，因为它降低了对单一智能体框架的依赖。AgentCore 文档指出，该服务通过 OpenTelemetry 和 OpenInference 插桩，支持包括 Strands 和 LangGraph 在内的集成。
这一架构使该功能的角色超越了仅适用于 Strands 的特性。Strands Evals 负责处理测试用例和已记录的开发轨迹。AgentCore 则能够评估来自已部署智能体的兼容追踪记录，包括在 Strands 框架之外生成的会话。
AWS 提供三种评估模式。按需评估可调查选定会话，或验证最近的变更。批量评估则处理多个已存储会话，以建立基线或比较目录修订版本。
在线评估会持续抽样生产流量。团队可选择评估器、数据源、筛选条件和采样率。随后，AgentCore 会在匹配的追踪记录到达时应用这些评估。
这些评估模式支持不同的运营问题。开发者可以检查一次失败会话，为已存储的群体评分，或监控只会在真实用户中出现的行为。
这一演进弥补了智能体测试中的一个常见缺口。精选提示词反映的是设计者预期用户会提出的问题；而生产请求则包含缩写、缺失上下文、非典型表述，以及测试编写者未曾预见的组合。
技能目录也会随时间变化。新技能可能与旧描述重叠，即使两项技能的内部步骤都没有改变，也会改变路由结果。AWS 将这种情况称为目录漂移。
在线评估可以通过选择评分下降揭示这种漂移。团队随后可以检查是哪项技能开始吸引不适合的请求。修复方式可能是收窄某一描述，或明确相邻技能之间的边界。
长会话带来了另一项担忧。智能体可能在对话开始时可靠地遵循某项技能，但随着上下文不断累积而忽略步骤。与孤立的测试提示词相比，生产追踪记录能更自然地暴露这些情况。
该托管服务还支持定向采样。AWS 文档表示，团队可以评估一定比例的会话，或应用条件筛选。这样，运营人员就能聚焦敏感工作流，而无需处理每一次交互。
不过，采样会改变仪表板数据的含义。低流量或筛选条件过窄的评估可能遗漏罕见故障。团队需要记录哪些流量符合条件，并避免将抽样得分表述为完整覆盖。
生产路径也依赖正确的遥测数据。AgentCore 将交互组织为会话、追踪和跨度。一个会话包含一次对话，一条追踪覆盖一次交互，而跨度则代表单个操作。
技能评估需要足够的信息，才能重建当时有哪些技能可用、哪些已加载，以及随后发生了什么。如果插桩遗漏了技能内容或调用信号，评审模型就缺少形成可靠结论所需的证据。
AWS 的 AgentCore 指南介绍了一种由基于模型的评估器评分的统一追踪格式。这种标准化简化了运营，但无法恢复应用程序从未记录的事件。
安全团队也需要审查追踪内容。技能文本可能包含内部流程，而对话记录可能包含敏感用户数据。评估提高了遥测数据的价值，同时也增加了访问控制和保留策略的重要性。
最终形成的是一种生命周期模型，而非单一测试。开发者可以在本地建立确定性门槛，在发布前比较已存储会话，并在部署后观察抽样行为。每一层都会捕捉不同类型的故障。
新评分仍需要自身的评估
基于模型的评审器增加了诊断细节，但不会将流程遵循转化为客观事实。
技能选择准确率和技能指令遵循依赖于评审模型。评审模型会在给出评分前阅读任务、可用证据和技能指令。其输出仍然是对已记录轨迹的一种解读。
这种解读可能会因步骤含糊而有所不同。例如，一项技能可能写道：“在继续之前验证客户状态”，却没有定义可接受的验证证据。一位评审器可能认为数据库查询已经足够，而另一位则期待明确确认。
五级遵循量表提供了细致程度，但也可能制造虚假的精确性。即使“基本遵循”和“部分遵循”之间的差异依赖判断，0.75 的评分看起来仍十分精确。
因此，团队应依据经过人工审查的示例来校准评估器。目标并不是在每一个边界案例上实现完美一致，而是建立能够反映组织实际流程优先级的稳定标准。
技能应让重要步骤可被观察。“考虑相关政策”很难验证；而“检索现行政策，将请求与三项资格条件进行比较，并记录结果”则会形成更清晰的证据。
负面案例与正面案例同样重要。选择基准应包含那些看似属于某项技能领域、但不应调用该技能的请求。否则，宽泛的描述可能因在每个邻近任务上都被激活而获得高分。
目录级测试也至关重要。孤立评估一项技能，几乎无法说明当十个相似选项同时出现时的路由表现。相关测试环境必须接近智能体实际会看到的目录。
确定性的“技能已调用”检查也有其局限性。它只能证明某个指定技能已加载，而不能证明加载是否恰当或有用。团队即使实现了完美调用，仍可能为错误的请求选择技能。
同样，强劲的指令遵循并不能保证答案正确。有缺陷的技能可能规定了错误步骤。智能体可以忠实执行这些步骤，却仍然产出不安全或不准确的结果。
这就是为什么响应层面的评估必须与技能评估并行存在。团队仍需要正确性、忠实性、有害性、工具参数检查以及特定领域验证。流程遵循只是可靠性的一个维度。
官方提示词模板使评分逻辑可被审查。它们展示了遵循评审器如何识别步骤、标记支持证据，并将结果映射到五个评级。
透明度有助于团队理解评估器，但不能替代验证。在将评分用于敏感发布决策之前，组织应将评审结果与专家审查进行比较。
成本和延迟同样影响生产环境中的使用。基于评审模型的评估需要在原始智能体运行后进行额外的模型处理。采样和筛选可以控制这类负载，但也会降低覆盖范围。
团队应避免将所有评估器压缩为一个标题式评分。单一综合数字会重现本次发布意在消除的模糊性。选择、调用、遵循和输出质量应继续作为独立信号呈现。
此次发布也将治理问题留在其范围之外。它并不决定谁可以编写技能、批准修订，或定义必需流程。只有当组织建立了权威基线后，评估才能揭示偏离情况。
成熟的工作流会将技能与测试和评分标准的变更一同版本化。否则，团队无法判断分数变化是因为智能体改变、指令改变，还是评估器改变。
Amazon 将这些检查定位为诊断工具，而非独立的合规证明。这是恰当的边界。它们让智能体行为更容易审查，但责任仍由定义和验证工作流的人承担。
三项信号将表明技能评估是否奏效
下一项考验在于，团队能否将逐技能证据转化为更安全的发布、更快的诊断和更好的技能目录。
第一项信号是开发阶段确定性路由门槛的采用情况。团队应识别其中某个指定技能必须调用的工作流，并在回归套件中加入“技能已调用”断言。
如果这些门槛能在部署前捕获目录变更，那么面向技能的测试价值将更具说服力。如果提取问题频繁产生空结果，插桩仍将是眼前的主要障碍。
第二项信号是生产环境中的选择得分是否能揭示目录漂移。新技能往往带着宽泛描述上线，因为作者希望它们能够可靠触发。这些描述可能会从现有流程中夺走请求。
一个有用的生产系统应能显示，在目录更新后哪些调用变得不恰当。团队随后应能够将得分下降关联到特定描述、重叠问题或请求模式。
可重复诊断的证据将强化 AWS 的核心主张。如果仪表板只显示较低的总体得分，却无法指出受影响的技能，就会削弱这一主张。
第三项信号是技能指令遵循与专家审查之间的一致性。组织需要将评审模型的步骤级标签与理解该流程的人员所作判断进行比较。
持续一致将证明其可更广泛用于发布门槛和在线监控。频繁不一致则表明，技能步骤、追踪证据或评估器标准仍需进一步完善。
团队应从小型目录和刻意多样化的测试集开始。应包括明确匹配、近似不匹配、无需技能的请求以及多技能工作流。每个场景都应多次运行，因为智能体行为仍具有非确定性。
分别记录四种结果：预期技能是否已加载、每次调用是否恰当、必需步骤是否得到遵循，以及最终结果是否正确。这一结构保留了新评估器的诊断价值。
然后应检查分歧，而不是通过平均值将其掩盖。跳过步骤却得到正确答案，可能暴露潜在的运营风险；忠实执行后却得到糟糕答案，则可能揭示技能本身存在缺陷，而非模型能力不足。
生产监控应从敏感或高流量工作流开始。应有意识地使用筛选和采样，并记录评分群体排除了哪些内容。对于严重故障和存在争议的评分，应保留专家审查机制。
Amazon Bedrock AgentCore 的技能评估之所以重要，是因为它改变了何为证据。流畅的输出依然有价值，但它已不再能单独证明智能体是否遵循了组织规定的流程。
现在轮到你来回答这个实际问题：你的团队能否说明代理选择了哪项技能、为何这一选择合适，以及追踪记录证明它完成了哪些必需步骤？如果不能，请在添加更多技能之前，先在下一轮测试中建立这方面的证据。
