Agent 评估体系：先定义什么叫好，再决定怎么打分

很多团队一提到“评估 Agent”，第一反应就是去找公开 benchmark。但对真实系统来说，这通常不是最先该做的事。

因为公开 benchmark 解决的是“横向比较模型或系统”，而你真正需要回答的问题通常是：

• •这版改动有没有把我们的系统变差
• •哪类任务最容易失败
• •工具选择是不是退化了
• •线上坏例子能不能被尽快抓出来

所以评估体系真正的起点，不是 benchmark 名字，而是先定义：

对你的 Agent 来说，什么叫“好”。

LangSmith 的 evaluation concepts 文档也把这件事讲得很清楚：先识别系统的关键组件，再为它们准备少量高质量“好例子”，然后再设计评估方式。

对 Agent 来说，可评估的对象通常至少有三层：

1. 最终结果

例如：

• •答案是否正确
• •任务是否完成
• •输出是否满足格式要求

2. 中间轨迹

例如：

• •是否选对工具
• •参数是否格式正确
• •是否调用了不该调用的工具
• •步数是否明显失控

3. 生产表现

例如：

• •成功率
• •用户反馈
• •延迟和成本
• •人工接管率

如果只盯最终文本，很多 Agent 退化根本看不出来。真正有价值的评估体系，通常会把结果、轨迹和生产表现一起看。

LangSmith 当前官方文档对 offline evaluation 和 online evaluation 的划分非常实用。

离线评估做什么

离线评估运行在数据集上，适合：

• •benchmark 比较
• •单元级评估
• •回归测试
• •历史数据回放

它的好处是：

• •可重复
• •可比较
• •可作为上线门槛

在线评估做什么

在线评估运行在生产 runs / threads 上，适合：

• •监控线上质量
• •发现异常模式
• •识别边界坏例子
• •建立生产反馈回路

它没有参考答案，所以更偏向：

• •reference-free 质量检查
• •安全检查
• •异常检测
• •用户反馈对齐

把这两类混在一起，会让评估目标变得模糊。

LangSmith 文档很明确地建议，从 5 到 10 个、或者 10 到 20 个高质量人工样本开始，而不是一上来就追求几千条数据。

这非常符合工程现实。

一个更合理的起步方式通常是：

• •常见任务样本
• •高风险任务样本
• •边界输入样本
• •历史坏例子

这类数据集虽然不大，但更能代表系统真实风险。

在 LangSmith 的术语里，离线评估的核心对象包括：

• •dataset
• •example
• •experiment

这三个概念非常重要：

• •dataset 是一组评估样本
• •example 是其中一个输入和参考输出
• •experiment 是某个系统版本在这组样本上的一次完整评测结果

只要这三个对象组织清楚，后面做版本对比就会顺很多。

很多人会把注意力放在“用哪个 judge 模型”，但 evaluator 的真正价值在于定义评分逻辑。

LangSmith 文档把 evaluator 大致分成几类：

• •human
• •code
• •LLM-as-judge
• •pairwise

这几类没有谁天然更高级，关键看你在测什么。

用 code evaluator 的场景

• •输出是否为空
• •JSON 是否符合 schema
• •是否调用了特定工具
• •是否满足硬性规则

用 LLM-as-judge 的场景

• •回答是否有帮助
• •总结是否完整
• •语气是否符合要求
• •多个候选输出谁更好

用 human review 的场景

• •高风险任务
• •主观性很强的输出
• •新系统冷启动阶段

经验上，不要把所有问题都交给 LLM judge。只要能规则化，就优先规则化。

LangSmith evaluation concepts 文档专门区分了这两个概念，这一点非常值得保留到团队共识里。

• •test 更像硬门槛
• •eval 更像质量度量

换成更工程化的话说：

• •test 是“不过不能发”
• •eval 是“要持续比较和优化”

一个健康的 Agent 项目，最好同时有这两类东西：

• •tests 保证关键功能不坏
• •evals 帮你知道系统是变好还是变差

这也是为什么很多评估指标最后会被转成测试门槛，例如：

• •新版本离线评估分数不得低于基线
• •高风险数据集上的工具误用率不得上升

这是 LangSmith 文档里非常重要的一条主线：在线评估和离线评估应该形成持续改进飞轮。

一个典型闭环是：

• •线下用小数据集做离线评估
• •上线后对生产 traces 做在线评估
• •从线上坏例子里挑选代表样本
• •把这些样本加入离线数据集
• •用新数据集验证修复是否有效

这个循环一旦建立起来，评估就不再只是“上线前做一次”，而会真正成为产品迭代的一部分。

OpenAI 当前的 agent evals 和 evaluation best practices 文档也强调了几个很重要的方向：

• •用 datasets 先快速搭起评估
• •把 workflow-level errors 纳入评估
• •在生产环境持续运行 evals
• •用 graders 明确定义评分标准

这和 LangSmith 的思路其实是一致的：不要只测模型输出，要评估整个系统行为。

所以如果你在做 Agent，最值得借鉴的不是某个平台的具体按钮，而是这种共同的方法论：

• •先定义质量标准
• •再准备数据
• •再建立可重复实验
• •最后用线上反馈持续补数据

如果你现在要给自己的 Agent 建立评估体系，我会建议从下面这套最小配置开始：

第一步：建一个小而精的数据集

• •10 到 20 条人工挑选样本
• •覆盖常见任务和高风险边界

第二步：先写两类 evaluator

• •code evaluator：结构、schema、工具调用、规则检查
• •LLM-as-judge：帮助性、完整性、正确性

第三步：跑 experiment 做版本对比

• •prompt 变更
• •工具变更
• •模型变更
• •工作流变更

第四步：把线上坏例子回流

• •差评 runs
• •成本异常 runs
• •高风险失败 runs

这套流程不花哨，但非常实用。

Agent 评估体系的重点，不是继续收集更多 benchmark 名称，而是建立一条持续有效的质量飞轮：

• •离线评估帮你在上线前比较和回归
• •在线评估帮你在生产中发现问题
• •evaluator 帮你把“好”变成可衡量标准
• •线上坏例子回流，帮你不断补齐数据集

只要这条飞轮跑起来，评估就会从“偶尔做一次的报告”，变成 Agent 工程化里最重要的基础设施之一。

• •LangSmith Evaluation
• •LangSmith Evaluation Concepts
• •LangSmith Evaluation Types
• •OpenAI Agent Evals
• •OpenAI Evaluation Best Practices