智能体评测基础

传统程序能写"输入-预期输出"的单测，智能体却很难：任务开放、路径多样、结果带概率。评测做不好，改进就是盲人摸象。本章讲清"为什么难、测什么维度、用什么方法、怎么起步"。

为什么评测难

• 任务开放性：同一请求没有唯一正确答案，"写得差不多"算不算对，边界模糊；
• 路径多样：到达正确结果可以走不同的工具与步骤组合；
• 概率性：同一输入多次运行结果不完全一致，难以断言；
• 依赖状态：结果受多轮记忆、外部数据影响，用例难以隔离复现。

因此智能体评测更像"阅卷打分"，而不是"对答案"。

评测维度

维度	考察内容	示例指标
正确性	最终答案对不对	语义相似度、LLM 打分、命中率
工具使用	是否选对工具、参数正确	工具命中率、参数错误率
规划能力	步骤顺序是否合理高效	任务成功率、步数
安全性	是否越权、泄露、被注入	违规调用次数
成本效率	花了多少 token 和时间	单任务 token 数、耗时

只测"答得对"远远不够：一个先乱删文件再答对的智能体，绝不能上线。

评测方法

• 黄金集 + LLM-as-judge：人工准备一批"问题-参考答案"用例，让大模型当裁判打分；也可让智能体自评（self-critique）后给出修正。速度快、覆盖广，是主力方法。
• 轨迹评测（trajectory eval）：不只评最终答案，还检查每一步工具调用序列是否符合预期，能抓住"结果对、过程错"的隐患。
• 回归集：把线上翻车的真实案例沉淀成回归用例，每次改 prompt/模型/工具后重跑，防止"修一个 bug 引入三个 bug"。

# 伪代码：黄金集 + LLM 裁判
golden = load_golden_set()            # 人工标注的参考答案
for case in golden:
    output = agent.run(case.query)
    score = judge_llm(case.answer, output)   # LLM 当裁判打 0~5 分
    trace_ok = check_trace(output)           # 轨迹是否符合预期
    print(case.id, score, trace_ok)
    # 输出：c001 4.5 True

工具与起步建议

DeepEval、Ragas 等开源评测框架提供 LLM 打分、断言、指标汇总等现成能力，可省去自建裁判逻辑（以各自官方文档为准）。新手最易犯的错是"一步到位造上千用例"，正确姿势是：

• 先收 20~50 条高质量用例，覆盖核心功能与已知失败案例，而不是追求数量；
• 先把"正确性 + 安全"两个维度跑通，再加轨迹与成本指标；
• 把评测脚本接进 CI，任何改动都自动回归，防止退化。

小结

智能体评测难在任务开放与结果概率化，需从正确性、工具使用、规划、安全、成本多维度打分。用"黄金集 + LLM 裁判"评结果、轨迹评测管过程、回归集守底线，从 20~50 条用例起步逐步扩展。