用三类评估器检查 Bedrock 智能体行为

Agent 上线后，能回复、延迟正常、用户没投诉，都不足以证明它完成了任务。AWS 这篇文章给出的办法是：先定义业务成功，再找到可观察的行为，最后用 Amazon Bedrock AgentCore Evaluations 里的评估器逐项检查。

它值得读的地方，不是又列了一批指标，而是解释了如何组合 Built-in、DeepEval 和 AutoEval，以及哪些检查适合线上抽样、哪些必须留在发布前。对正在做多轮助手、工具调用或知识问答的程序员，这比单看一个「回答质量分」更实用。

先定义任务成功，再挑评估指标

作者反对从指标名称出发。「Helpfulness 看起来不错」并不能回答客服 Agent 有没有解决问题。一个助手可能每次都热情回复，却漏掉退款申请；也可能完成了任务，同时把用户个人信息带进回答。

任务完成率高，不能抵消隐私泄露。

文章建议分三步建立评估方案。

第一步，用业务语言描述成功。客服可以看首次联系是否解决问题；研究助手要给出完整、有来源、完全依据检索文档的答案；内容审核助手既要找出该拦截的内容，也不能误伤正常内容。

第二步，把成功拆成可观察行为。客服完成一次服务，可能同时要求它理解用户目标、在多轮澄清中保持连贯、遵守数据政策，并正确调用查订单或创建工单的工具。

第三步，选对观察范围。Trace-level 检查看单轮回答或某次工具调用；Session-level 检查看整段会话。用户开头提出两个要求，助手最后只完成一个，这类遗漏通常需要结合整个会话才能判断。

这个顺序决定了分数有没有解释力。业务目标是「办完退款」，只评回答是否礼貌，就算分数持续上涨，也未必接近真正的成功。

现成评估器很多，先补最关键的缺口

AgentCore 提供三类来源。Built-in 由 AWS 编写并做质量测试，直接通过 ID 使用，例如 Builtin.GoalSuccessRate、Builtin.Helpfulness。DeepEval 和 AutoEval 则提供托管的第三方评估器：AgentCore 托管代码、选择裁判模型，并使用服务自身的容量执行推理。

对开发阶段已经使用这两个开源库的团队，这提供了把对应指标带到生产环境的路径。但文章没有给出开源本地运行与托管运行的分数一致性对照，不能仅凭指标同名就认定结果完全可比。

选型时，可以按故障类型理解这份目录：

• 回答是否正确、忠于依据、相关且连贯，可以看 Correctness、Faithfulness、ResponseRelevance、Coherence 等 Built-in 指标。
• 工具有没有选对、参数有没有传对，可以看 ToolSelectionAccuracy 和 ToolParameterAccuracy；加载技能的 Agent 还有 SkillSelectionAccuracy、SkillInstructionFollowing。
• 多轮任务有没有遗漏、用户说过的信息有没有忘记，可以看 DeepEval 的 ConversationCompleteness、KnowledgeRetention。
• 隐私和安全需要单独检查，例如 DeepEval 的 PIILeakage、Toxicity、Bias，以及 AutoEval 的 Security。

其中，ConversationCompleteness 和 KnowledgeRetention 很容易混淆。前者关注「之前答应做的事有没有做完」，后者关注「之前提供的信息有没有记住」。助手记得订单号，却忘了用户还要求修改地址，仍然可能失败。

AutoEval 还提供 Possible，用来发现把有效任务误判为无法完成的过度谨慎行为；Humor 则面向把幽默感作为产品体验一部分的助手。这些指标是否必要，取决于业务，并非目录里有就应该全开。

如果业务要求规定工具路径，还可以使用 TrajectoryExactOrderMatch、TrajectoryInOrderMatch、TrajectoryAnyOrderMatch，对照预期轨迹检查实际工具调用过程。它们检查的是执行路径，不只是最终答案。

完整目录可以通过 ListEvaluators API 获取，也会包含账户中的自定义评估器。具体评分定义、量表、输入要求及裁判提示词，需要查对应的 prompt template library。尤其要确认是否依赖参考答案或预期轨迹，避免选好了指标才发现线上缺少输入。

多维评分拆开看，三种运行模式接起来

现成指标不够时，可以创建自定义评估器，调整裁判模型、提示词或评分准则。文章还介绍了多维评估器：裁判读取一次 trace，在同一次调用中分别评价多个维度，每个维度有自己的名称、指令和数值或分类量表。

例如客服回复可以分别检查解决程度、退款政策合规性、专业程度。AgentCore 为每个维度返回结果，不生成混合总分。

能够独立失败的标准，也应该能够独立阻止发布。

语气改善了，但政策合规退步了，不能靠平均分把问题盖过去。不过，多维评估器有明确前提：各维度必须能使用同一份证据，并共享评估层级和裁判模型。

已有成熟指标覆盖的检查，例如 Builtin.Correctness、ThirdParty.DeepEval.PIILeakage，作者建议保留为独立评估器。需要 {expected_response} 或 {assertions} 等参考数据的标准，也应与无需参考数据的标准分开，让后者仍能运行在真实流量上。

执行层面有三种模式。开发调试用按需评估，直接把 session 传给 client.evaluate()：

import boto3

client = boto3.client('bedrock-agentcore')

response = client.evaluate(
    evaluatorId="ThirdParty.DeepEval.TaskCompletion",
    evaluationInput={"sessionSpans": session_span_logs}
)

for result in response["evaluationResults"]:
    print(f"Value: {result.get('value')}")
    print(f"Explanation: {result.get('explanation', '')}")

要看清的是 evaluationInput={"sessionSpans": session_span_logs}：这里提交的是会话 span 日志，不是一段孤立的最终回答。代码展示了调用方式，但没有解释 session_span_logs 的采集与构造，接入工作仍需补齐。

线上评估按配置比例抽样真实流量，适合持续观察生产行为；批量评估针对固定会话集运行，适合在修改 prompt、升级模型前做回归。三种模式共享评估器 ID，切换方式主要是配置变化。

需要标准答案或预期路径的指标只能用于批量评估。文章明确标注了 Builtin.Correctness 和 Builtin.TrajectoryAnyOrderMatch 这类例子，不能把它们直接当成无需参考数据的线上健康指标。

我的判断

我认同这套方法的核心取舍：先用两三个最能证明业务成功的指标起步，发现漏检的失败类型后再增加。相比一次性打开全部指标，这更容易解释分数变化，也更容易决定某次发布是否应该被拦下。

但这是一篇平台使用指南，不是评估效果实验报告。原文声称 Built-in 做过可靠性基准测试，却没有提供测试集、误判率或与人工判断的一致性数据；也没有证明多维裁判在准确性、成本或延迟上优于多个独立裁判。这些地方只能视为产品设计说明和经验建议。

LLM-as-a-judge，即让模型充当评分裁判，也仍然需要校准。我的建议是用人工确认的成功与失败案例检查裁判是否判对，而不是把裁判解释当作事实。涉及个人信息、关键参数或固定流程时，确定性断言和人工抽查仍有价值。

一般团队还有一个前提要补：日志是否足够完整。工具输入输出、历史消息、技能调用缺失时，再合适的指标也可能缺少判断依据。文章强调了选指标，却没有展开数据接入和裁判校准的具体成本。

能拿来做什么

• 给多轮客服或业务助手写一句明确的成功定义，再选两三个对应检查，例如用 Builtin.GoalSuccessRate 看目标是否完成，用 ThirdParty.DeepEval.ConversationCompleteness 查遗漏，并单独检查 PIILeakage。
• 给会调用后端工具的 Agent 同时检查工具选择和参数正确性；只有业务确实要求指定路径时，再准备预期轨迹，放进批量回归。
• 修改 prompt 或升级模型前，用同一组固定会话比较各维度结果，并为隐私、合规等关键项设置独立门槛，避免总分掩盖退步。
• 把无需参考答案的指标接入线上抽样，把需要标准答案的指标留在批量评估；对真实流量发现的新失败案例，补充人工确认后再纳入回归集。