一个 Agent 能跑通，只能说明某条执行路径没有中断。它是否回答准确、评分合理、流程可靠，以及运行成本是否可控，需要另一套有明确样本、指标和判定规则的评估体系。
本文以知识问答、试卷批改、简历评审和模拟面试四类任务为例，梳理从单个 Agent 到整个系统的评估方法。文中的数据规模和阈值均属于方案示例，不代表已完成的实验结果。
先区分三类问题
功能测试检查输入输出格式、节点执行、异常处理和状态恢复；质量评估检查结果是否正确、完整且有依据；运行监控检查延迟、失败、降级与成本。三者互相补充，不能用“测试全部通过”替代质量结论。
| 对象 | 核心问题 | 主要指标 |
|---|---|---|
| 知识问答 | 证据是否召回，答案是否正确 | Recall@K、Hit Rate@K、回答正确率 |
| 试卷批改 | 给分与独立教师基准相差多少 | MAE、等级一致性、人工改分率 |
| 简历评审 | 问题是否找全，评分是否合理 | 问题召回率、误报率、评分 MAE |
| 模拟面试 | 流程是否有效推进，报告是否有证据 | 状态转移、重复题、报告质量 |
| 整个系统 | 是否稳定、及时且成本可控 | 成功率、P95、降级率、Token 与费用 |
把三种评估方法组合起来
确定性计算
当输入和标注已经固定时，可以直接计算分数误差、检索召回、接口成功率和延迟分位数。这类指标容易复现，但结论仍受样本覆盖、标注质量和统计口径影响。计算过程确定，不等于测试集天然可靠。
模型裁判
对于答案语义、建议可操作性等难以用规则表达的内容，可以使用 LLM-as-Judge。输入应包含任务、必要证据、待评结果和评分量表，输出应包含评分、理由及证据位置。固定裁判模型、提示词和参数，保留原始输出；解析失败应记录为失败或待复核，不能默认为通过。
模型裁判可以减少人工工作量，但无法替代人工校准。评委也可能偏好较长、较流畅的答案，或被待评文本中的指令影响。需要用人工抽样检查其误判，并明确把待评内容当作数据。
独立人工基准
评分任务应先制定量表，再让评审者独立标注。条件允许时，由多名评审者处理同一批样本，保留分歧和仲裁记录。人工结果是明确规则下的参考基准，不是天然无误的绝对答案。
先固定评估合同，再运行系统
一份最小评估合同需要写清：样本来自哪里、覆盖哪些任务、使用什么版本、怎样定义成功、异常计入哪个分母，以及哪些失败必须人工复核。阈值应由业务容忍度和基线实验共同确定，不能把某个百分比直接命名为“企业级标准”。
评估记录
run_id / dataset_version
model_version / prompt_version / code_revision
sample_id / task_type / input_reference
raw_output / evidence_ids / metric_values
status / error_type / review_status测试集可以先用少量样本打通流程，再逐步扩展。冒烟测试只能发现明显故障；稳定的质量结论需要覆盖常见输入、边界输入和失败场景，并报告样本量、分组表现与不确定性。用于反复调参的开发集，应与最终验收集分开。
读懂分数背后的含义
MAE 回答“平均相差多少分”，解释时必须附带评分尺度。10 分制和 100 分制的 3 分误差不是同一回事。等级一致性关注双方是否作出相同分类；排序相关性关注相对顺序，不能替代绝对分数误差。
同样，平均质量分可能掩盖少数严重失败。除了总体指标，还应查看长文本、信息不足、跨文档问题、外部工具超时等子集，并列出典型错误及对应证据。
让评估形成可追溯的改进闭环
- 冻结数据集与基线配置，保存逐样本结果。
- 把错误归因到输入解析、检索、生成、工具调用或状态管理。
- 针对一个主要变量修改实现或提示词。
- 在相同条件下重跑，并检查质量、延迟和成本的共同变化。
- 对重要变化做人工复核，通过后再纳入发布流程。
评估的价值不在于得到一个漂亮总分，而在于明确指出：系统在哪类输入上失败、失败发生在哪一环，以及下一次修改是否真正解决了问题。