要点
- 2026 年 11 月 10 日，Amazon 在 AWS Machine Learning 博客发表《The agent evaluation playbook: Built-in, DeepEval, and AutoEval on Amazon Bedrock AgentCore Evaluations》，作者是 Bharathi Srinivasan、Manoj Selvakumar、Neha Thakur 和 Visakh Madathil。
- AgentCore Evaluations 提供三类评判器：由 AWS 编写并做质量测试、通过 Builtin.GoalSuccessRate 这类 ID 引用的内置评判器；由 AgentCore 托管代码、评判模型并执行推理的 DeepEval 与 AutoEval 第三方托管评判器；以及以内置或第三方评判器为底，可更换模型、提示词或评分细则的自定义评判器。
- 作者要求团队先用业务语言定义成功，再把它拆成可观察的行为，然后把每一种行为映射到轨迹级或会话级评判器。从听起来正确的指标名称入手，被说成最常见的错误。
- 多维评判器在一次评判调用中给若干标准打分，并按维度各返回一个结果，没有综合分数。文章中的例子是一条必须同时解决问题、遵守政策、并保持专业措辞的客服回复，而这些标准可以分别失败。
- 同一套评判器 ID 可用于按需、在线和批量三种模式。需要参考答案或预期工具路径的指标，包括 Builtin.Correctness 和轨迹匹配检查，只在批量评估中运行。这篇文章没有公布这些评判器的独立可靠性数字。
2026 年 11 月 10 日，Amazon 在 AWS Machine Learning 博客中介绍了如何在 Amazon Bedrock AgentCore 上评估智能体。文章由 Bharathi Srinivasan、Manoj Selvakumar、Neha Thakur 和 Visakh Madathil 署名，并称团队可以在 AgentCore Evaluations 中同时使用 AWS 内置评判器，以及 DeepEval 和 AutoEval 评判器。可核对的主张，并不是 AWS 现在提供了一份更长的指标名称清单。它是：AgentCore 将把 DeepEval 和 AutoEval 作为托管评判器，用同一套 ID 跑在线上流量上；并且单一综合分数被当成设计错误，因为一个很高的数字可能掩盖另一项行为上的失败。
[1]AgentCore Evaluations 实际提供了什么
这份目录分成三层。内置评判器由 AWS 编写并做质量测试。团队用 ID 来引用它们，例如 Builtin.GoalSuccessRate 或 Builtin.Helpfulness，其余由服务执行。文章称它们为可靠性做过基准测试，并覆盖常见维度。除了上述两个 ID，正文还点出另外 13 个内置 ID，但在我们读到的文字里，并没有公布那些基准数字。
第三方托管评判器来自 DeepEval 和 AutoEval。在托管模式中，AgentCore 托管代码，选择评判模型，并用自己的算力做推理，方式与运行内置评判器相同。作者的说法是，如果团队已经在开发中使用其中一座库，就可以在生产环境运行同样的指标，而不必再单独搭一套评估服务。
自定义评判器以内置或第三方评判器为底，因此团队可以换上自己的模型，并修改提示词或评分细则。创建之后，自定义评判器的用法与其他评判器相同。文章还指向 ListEvaluators API，它会一次性返回内置、DeepEval、AutoEval 目录，以及该账户中的自定义评判器；同时又指向 AgentCore 文档中的提示词模板库，用于查看定义、评分尺度和输入要求。
在文章的分组里，内置评判器包括回复质量、任务与目标完成、工具使用、技能使用和安全，外加三项把智能体的工具路径与团队预期路径相比较的轨迹检查。DeepEval 被分成任务与目标完成、对话质量、工具使用和安全，其中包括 ConversationCompleteness、KnowledgeRetention 和 PIILeakage。AutoEval 被说成更专门，包含 Security、Possible 和 Humor。
[1]从业务结果出发，而不是从指标名称出发
作者说，常见错误是打开指标清单，挑选听起来正确的名称。Helpfulness 听起来不错，于是团队就用它。运行会产生数字，却几乎给不出有用的判断，因为指标符合的是它自己的标签，而不是该智能体意义上的成功。
他们给出的是三个步骤。第一，用业务语言定义成功。对客服智能体来说，这可能是一次接触就解决问题。对研究型智能体来说，这可能是一份完整、有出处、并且完全依据检索文档的回答。第二，把这一结果拆成可以在轨迹或会话中观察到的行为：智能体是否完成了用户的任务，是否在多轮中保持连贯，是否守住政策，或是否调用了正确的工具。第三，把每一种行为映射到恰当层级的评判器。轨迹级指标覆盖每一轮或每一次工具调用。会话级指标覆盖只有看完整段对话才说得通的结果。
文章对隐蔽失败的提醒，就放在这里。一个客服智能体可以解决每一张工单，却仍然在回复里泄露个人信息。在这种情况下，即使完成率很高，这个智能体也已经失败。DeepEval 集合里的 ConversationCompleteness，被用来抓住只回答最新一句、却丢掉更早请求的智能体。KnowledgeRetention 被用来抓住忘掉用户三轮之前说过的话的智能体。
[1]为什么单一综合分数被当成设计错误
大多数评判器为每条轨迹或每个会话返回一个分数。这在你只测量一种行为时成立。作者说，当一条回复必须同时满足几项可能分别失败的标准时，它就不成立了：要解决问题，要遵守退款和数据政策，还要保持专业措辞。一个把三项一起权衡的评判器只返回一个数字，你无法分辨是哪一项在起作用。
他们的答案是多维评判器。它是一种自定义评判器，用一份维度列表，而不是单一尺度。每个维度有自己的名称、说明，以及数值或类别尺度。评判器把轨迹读一遍，并在同一次调用中给每个维度打分。AgentCore 按维度各返回一个结果，没有综合分数。文章写到，一次改进了语气、却让政策合规变差的发布应当被判定为失败，而单一综合分数会把这一点藏起来。
他们也写了什么时候不要把这些标准塞进同一个评判器。如果已有的内置或第三方指标已经覆盖该行为，例如 Builtin.Correctness 或 ThirdParty.DeepEval.PIILeakage，就应分开。如果它们需要不同的层级或不同的评判模型，也应分开，因为同一个评判器里的各个维度共用同一层级和同一模型。当部分标准需要标准答案，例如预期回复时，同样应分开。把不需要参照的标准放在自己的评判器里，意味着这个评判器仍可以跑在线上流量上。
最后这项区分，关系到产品主张。按需评估是在开发或排错时，把一个会话直接交给 client.evaluate()。在线评估挂到实时的智能体运行时上，并按设定比例抽样真实流量。批量评估是用固定的评判器组合，跑一套作为黄金集的会话。三种模式使用同一套评判器 ID。需要参考答案或预期轨迹的指标，仍然只在批量模式中运行，因为线上流量没有参考答案，也没有预期路径。
[1]这篇文章没有说明什么
这是一篇 AWS 产品博客，作者来自 AWS，其中一位的职责被写成 Trustworthy AI 的技术市场专家。文章称内置评判器经过质量测试，并为可靠性做过基准，但没有给出那些基准数字、样本量，或与人工评分者的比较。DeepEval 和 AutoEval 是已有的开源库，但托管版本跑在 AWS 选择的评判模型和算力上。文章没有报告，这些托管评判器与团队现有的库用法，或与人工审看，相符的频率有多高。
目录和 API 名称可以作为产品描述来核对。综合分数可能掩盖失败，这是一项用例子说明的论点，而不是这篇文章里来自生产机群的测量结果。我们没有调用 ListEvaluators，也没有自己跑一次评估。
[1]更公允的读法
更公允的读法是：许多团队已经有指标看板，却仍然回答不了智能体有没有完成业务真正关心的工作。把 DeepEval 和 AutoEval 放在与内置评判器相同的 ID 后面，并让这些 ID 在开发、在线抽样和批量回归中都能用，是一种具体办法，避免评估变成另外一堆离线脚本。当两项标准可能分别失败时，拒绝综合分数，也是正确的默认做法。
同样公允的是，应把这看成一份目录和一套方法，而不是评判器已经准确的证据。团队仍然必须选择，哪两三种行为真正表明业务结果已经发生；也仍然必须接受，最精确的那些检查，也就是需要参考答案或预期工具路径的检查，看不到线上流量。文章本身也告诉读者，先用一个很短的组合开始，只有发现当前集合没抓住的失败时，再增加一项指标。
[1]谁该在意，接下来看什么
已经在 AgentCore 上运行智能体的团队，尤其是做客服、研究或受监管内容的团队，应当关心。已经在开发中使用 DeepEval 或 AutoEval、并希望生产环境沿用同一套名称的评估工程师应当关心。今天只能看到完成率或延迟的合规审阅者，同样应当关心。
未来六个月里，真正的检验是：团队是否真的把 DeepEval 或 AutoEval 评判器放到在线、抽样的实时流量上；是否采用多维评判器，并且不再把综合分数塞回来；以及 AWS 是否公布关于评判器可靠性的可核对材料。还有一项更窄的检验：需要标准答案的指标是否仍然只在批量模式中运行，或者团队是否找到一种可行办法，在没有参考答案的情况下为线上流量打分。
[1]收束
就这篇文章中的证据而言，AgentCore Evaluations 是一种办法，让 AWS、DeepEval 和 AutoEval 评判器在同一套 ID 下运行，包括跑在线上流量上，并在一个很高的数字会掩盖另一项失败时，分开为各项行为打分。在这些页面里，它并不是这些评判器已经可靠的测量证明。未来六个月里要看的主张是：这套共享 ID 的安排，以及对综合分数的拒绝，是否会成为 AWS 托管智能体的默认评分方式，而那些精确的、需要参照的检查，在有人证明它们也能用于线上之前，仍然留在批量模式中。
[1]