Agent 评测入门：怎么知道你的智能体到底行不行

为什么 Agent 比 LLM 更难评

评一个纯 LLM，多数时候是「一段输入、一次输出、对个答案」：分类对不对、摘要像不像，判定是即时的。Agent 完全不同，难评在四个地方：

• 多步：一个任务拆成十几次工具调用，错在哪一步都需要定位
• 依赖环境：要读文件、查数据库、开浏览器，环境状态直接影响结果
• 路径不唯一：同一个目标有多条合法解法，不能拿单一「标准轨迹」去卡
• 随机性：同样的输入跑两遍，轨迹与耗时都可能不同

所以评 Agent，评的不是一句话，而是「一段过程 + 一个最终状态」，方法论要从头建。

评测分层

把「行不行」拆成四层，逐层看：

只看端到端成功率会掩盖问题：分数低可能是规划弱，也可能只是某个工具的描述写得含糊。分层归因才谈得上改进。

构建评测集

三条要点：

• 从真实任务里抽样。评测集要长在自己的业务上，公开 benchmark 只能当参考系。专挑真实发生过的任务，包括当时失败的那些——失败案例的信息量最大。
• 固定环境快照。同一用例每次评测的初始环境必须一致：同一份仓库状态、同一批测试数据、同一个容器镜像。环境漂移，分数就失去可比性。
• 每条用例两要素：初始状态 + 判分标准。前者说清「世界现在是什么样」，后者说清「怎样算完成」。

三种判分方式

• 精确匹配：能用程序客观判定的优先用程序。文件是否生成、测试是否通过、命令退出码是否为零、数据库里那行是否更新。最可靠，也最便宜。
• LLM-as-judge：让另一个模型按评分标准（rubric，即明确写出的评分细则）打分。适合没有唯一正确答案的任务，比如总结质量、回复语气。
• 人工抽检：定期抽样人来看。无法规模化，但它是前两种方式的校准基准。

实践中的优先级：能精确匹配的绝不交给 judge，judge 只兜「软指标」，人工抽检定期校准前两者。

LLM-as-judge 的已知偏差

用模型评模型，要清楚它的系统性毛病：

• 位置偏差：对比两个答案时偏袒固定位置的答案。缓解：交换顺序各评一遍，取结论一致的结果。
• 长度偏好：倾向给更长的答案高分。缓解：rubric 里写明「冗长不加分」，按要点逐项计分而非整体印象分。
• 标准漂移：同一个 rubric，换个措辞或换个 judge 模型，分数分布就变。缓解：rubric 当代码管理、版本化，judge 模型与提示词冻结不动，定期用人工标注过的样本校准分数。

在线指标

离线评测之外，线上还有一组便宜且诚实的信号：

• 任务放弃率：用户中途放弃对话的比例
• 人工接管率：Agent 干到一半人接手的比例
• 回滚/纠错率：结果被撤销或被要求重做的比例
• 每任务 token 成本与轮数

这些指标不完美——放弃可能只是用户没耐心——但量大、真实、连续，适合看趋势与报警。

评测即 CI

最后一步工程化：

1. 评测集入库、版本化，改动跟代码一样走评审
2. 每次改提示词、换模型、改工具描述，都跑一遍回归评测
3. 关键指标显著下降就挡住合并，和单测红了不许合是同一个逻辑

Agent 的行为由提示词、模型、工具三个变量共同决定，任何一处改动都可能让某类任务悄悄变差。没有回归评测，这些问题只能靠用户替你发现。

小结

• Agent 评测的难点在多步、环境依赖、路径不唯一与随机性，思路是「过程 + 终态」一起评
• 分层评测用来归因，评测集要来自真实任务、环境要冻结、每条用例要有明确判分标准
• 判分优先精确匹配，LLM-as-judge 处理软指标，但要管住位置偏差、长度偏好与标准漂移
• 把评测集当代码版本化，每次改动跑回归——评测即 CI