一个客服Agent完成了退款，数据库里已经出现退款记录，工单状态也变成“已解决”。但评测系统仍然判它失败，理由是：它没有按照预设顺序先查政策、再查订单、最后调用退款工具。

到底是Agent错了，还是评测错了？

这是很多团队做Agent测评时最容易忽略的问题。大家盯着Agent会不会幻觉、会不会调错工具，却很少测试负责打分的“裁判”是否公平。结果是Agent能力没测准，研发还根据错误分数去改Prompt，最后把原本能解决问题的Agent改得越来越僵。

Anthropic在一篇Agent评测工程文章中，把评测拆成了任务、试运行、评分器、Trace、最终状态、评测Harness和评测套件等组件。它特别强调：一个任务可以同时使用多个评分器，不同评分器负责不同类型的证据。真正可靠的Agent测评，通常不是找一个“最强裁判”，而是让三类裁判各管一段。

一、先把“回答正确”和“任务完成”分开

传统对话模型经常只需要检查一段输出文本。Agent不一样，它会连续调用工具、修改状态，并在多轮对话中根据中间结果调整动作。

比如用户说：“帮我把昨天买错的会员套餐退掉。”Agent最后回复“已经为你完成退款”，只能证明它说了这句话，不能证明退款真的发生了。

至少要检查三份证据：

• 对话记录里，Agent是否理解了用户要退的是哪笔订单；
• 工具调用里，是否使用了正确订单号和退款金额；
• 最终业务状态里，退款记录和工单状态是否真的改变。

Anthropic将完整运行记录称为transcript，也就是我们常说的Trace或trajectory；将任务结束后的真实环境状态称为outcome。文章举的例子很直接：一个订票Agent可以说“机票已经订好”，但真正的结果要看数据库里有没有预订记录。

这意味着Agent评测的第一步不是选模型，而是先回答：这个任务结束后，系统里应该留下什么可验证的事实？

二、三类Grader，不是谁替代谁

Anthropic把Agent评测常用的评分方式分成三类：代码评分器、模型评分器和人工评分。它们不是三选一，而是一套分工。

1. 代码评分器：负责能明确判定的事实

代码评分器适合检查：

• 字符串、正则或结构化字段是否匹配；
• 工具是否被调用、关键参数是否正确；
• 数据库、文件、工单等最终状态是否改变；
• 单元测试、静态扫描、安全扫描是否通过；
• 总轮数、Token、耗时是否超过门槛。

它的优势是便宜、快速、可复现，缺点是容易把合法的不同实现误判为失败。

比如Agent最终完成了退款，但调用顺序和开发者预想不同。如果评测器把“必须先A再B”写死，就可能惩罚一条同样安全、甚至更短的正确路径。

2. 模型评分器：负责开放式质量

LLM-as-a-Judge适合判断：

• Agent是否准确理解用户意图；
• 解释是否清楚；
• 语气是否合适；
• 回答是否忠于工具返回；
• 两个版本哪个更符合业务目标。

它能处理开放答案，但本身也具有非确定性，还可能受到措辞、答案长度和评分标准模糊的影响。因此，不能把“让另一个模型给0—10分”当成完整评测体系。

3. 人工评分：负责校准裁判

人工评审最慢、最贵，却承担一个模型评分器无法自己完成的任务：确认评分标准是否真的代表业务判断。

正确做法不是每条Case都人工看，而是先由领域专家标注一批黄金样本，再检查LLM裁判与人工结果的一致性。出现明显分歧时，优先检查Rubric，而不是立刻认定Agent退化。

三、一个客服Agent，应该怎样组合三种裁判

以“用户要求退款”为例，可以把评分规则拆成三层：

task: refund_frustrated_customer

deterministic_graders:
-refund_record_created:true
-ticket_status:resolved
-refund_amount_equals_order_amount:true
-forbidden_tools_called:false

llm_grader:
rubric:
    -是否准确说明退款结果
    -是否避免承诺工具返回中不存在的到账时间
    -是否回应用户的负面情绪

human_calibration:
sample_rate:0.05
review_when:
    -llm_and_code_disagree
    -low_confidence
    -new_failure_type

这套设计有一个重要顺序：先用确定性证据守住业务事实，再让模型判断表达质量，最后用少量人工样本校准模型裁判。

不能反过来。假如模型裁判认为回答“很有同理心”，但退款记录根本没有生成，这条Case仍然必须失败。表达质量不能抵消业务动作失败。

在发布门禁里，可以把指标分成“硬失败”和“软评分”：

def release_decision(result):
    hard_failures = [
        not result.refund_created,
        not result.amount_correct,
        result.forbidden_tool_called,
    ]
    if any(hard_failures):
        return"BLOCK"

    if result.llm_quality_score < 0.8:
        return"REVIEW"

    return"PASS"

这样，确定性错误直接阻断；开放式质量不足进入复核；只有两层都满足才通过。

四、别忘了测“裁判是否在制造假失败”

Agent测评还有一种反直觉风险：分数低不一定说明Agent差，也可能是题目、环境或评分器坏了。

Anthropic在文章中给出几个非常实用的判断：

• 任务描述必须包含评分器真正检查的条件；
• 应该准备一个能够通过全部评分器的参考答案，证明题目确实可解；
• 如果前沿模型大量运行后仍是0%通过，首先要怀疑任务或评分器配置；
• 每次试运行要从干净环境开始，避免残留文件、缓存、Git历史或资源耗尽影响结果；
• 不要只测“应该调用工具”，也要测“不应该调用工具”，否则可能把Agent优化成遇事就搜索。

这里最值得测试工程师关注的是“参考解”。传统自动化测试会验证用例能否稳定复现，Agent评测也一样。如果连人工准备的已知正确结果都过不了Grader，后面任何分数都没有解释价值。

可以给评测系统增加一组自检：

def validate_eval_task(task, reference_solution, graders):
    result = run_graders(task, reference_solution, graders)
    return {
        "reference_passed": result.all_required_passed,
        "rubric_complete": task.success_criteria == result.checked_criteria,
        "environment_clean": no_shared_state(task.workspace),
        "both_positive_and_negative_cases": task.has_balanced_cases,
    }

只有这四项通过，任务才进入正式评测集。

五、LLM裁判怎样校准，才不是“模型互相吹捧”

最小可行做法是准备一批人工黄金样本，至少包含：明显通过、明显失败和容易争议的边界样本。

然后关注的不只是平均分，而是两类错误：

• 假通过：人工认为失败，模型却给通过；
• 假失败：人工认为通过，模型却给失败。

对退款、支付、权限等高风险Agent，假通过通常比假失败更危险。因此可以对两种错误设置不同容忍度。

如果一个Rubric同时评价事实、语气、完整性、合规和效率，模型裁判很容易顾此失彼。Anthropic建议把不同维度拆开，由独立判断分别评分，并允许模型在证据不足时返回“Unknown”，而不是强迫它猜一个分数。

一个可操作的Rubric应该长这样：

判断目标：回答是否忠于refund_tool的返回结果。

PASS：回答中的退款金额、状态和预计时间均能在工具返回中找到。
FAIL：出现与工具返回矛盾或工具未提供的确定性事实。
UNKNOWN：Trace缺少工具返回，无法判断。

只评估事实忠实度，不评估语气和文字流畅度。

边界越清楚，裁判越稳定。

六、给第一次做Agent测评的团队一个起步顺序

不需要第一天就搭一个庞大的评测平台。可以先做四步：

1. 挑10—20个最重要的真实任务，写清最终业务状态；
2. 每个任务先放一个确定性Grader，验证工具参数或最终状态；
3. 只对无法用代码判断的维度增加一个窄Rubric的LLM Grader；
4. 每周人工复核少量分歧样本，持续修正Rubric和用例。

当这些基础稳定后，再扩展多次运行、对抗样本、成本和时延指标。

Agent测评真正的难点，不只是“怎么测Agent”，而是“怎么证明负责评分的人和系统没有测错”。一个好的评测体系，既要防Agent作弊，也要防Grader僵化，更要能让团队看懂：这次失败究竟是业务没完成、表达不好，还是裁判本身出了问题。

关于我们

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。