Agent 评估：不要用一次成功掩盖系统性失败

Agent 的一次成功很有说服力，但没有统计意义。它可能只是碰巧遇到了简单任务，也可能通过了最终断言，却调用了过多工具、花费了很长时间，或者在高风险场景中做出了不可接受的动作。

评估的目标不是给 Agent 一个漂亮分数，而是回答：它在哪些任务上可靠，失败发生在哪个环节，改动带来了什么代价。

一、先定义任务，再定义指标

任务集应该覆盖真实使用中的成功路径、边界条件和已知失败类型。每个任务最好包含输入、可用工具、环境状态和验收标准，而不是只有一段自然语言问题。

可以把指标拆成四层：

单看成功率会隐藏过程问题，单看成本又可能鼓励 Agent 过早停止。实际系统应该同时报告结果和代价。

一条 Agent 轨迹至少可以记录：模型版本、上下文摘要、工具调用序列、每次参数校验、返回状态、人工确认和最终验证。

这些数据能区分两种不同的失败：

如果只保存最后一段答案，后续只能重新猜原因；保存轨迹，才可以针对具体环节做实验。

对于结构化任务，优先使用确定性检查：数据库状态、文件差异、测试结果、schema 校验和引用是否存在。开放式回答可以使用 LLM-as-a-Judge，但要固定评分标准、提供正反例，并检查不同模型或不同提示词是否给出一致结论。

成对比较通常比要求评审者给绝对分数更稳定：给出同一任务的两个结果，让评审者判断哪一个更好以及理由。评审结果仍然是测量值，需要抽样人工复核。

当你改变了模型、提示词、工具描述和检索库，却只比较一次总分，就无法知道提升来自哪里。一个更小的实验可以固定其他条件，逐项做消融：

基线：模型 + 原上下文 + 原工具
实验 A：只改变上下文组织
实验 B：只改变工具 schema
实验 C：只增加验证步骤

每个版本都要使用相同任务集和随机种子范围，报告成功率、P95 延迟、平均步数、成本以及失败类型。差异很小时，还要判断样本量是否足以支持结论，而不是把随机波动当成进步。

离线 benchmark 只能说明预设任务上的表现。上线后还需要采集脱敏后的任务类型、工具错误、上下文长度、重试、人工接管和用户反馈，并把这些信号回流到评估集。

观测系统要保护隐私，同时保留排查所需的关联 ID。对敏感内容可以存哈希、字段摘要或受控采样，而不是无条件保存完整对话。

一个有用的评估循环是：

收集任务 -> 执行并记录轨迹 -> 自动/人工验收 -> 分类失败
    -> 提出一个局部改动 -> 重跑基线与实验 -> 发布或回滚

失败分类应具体到“检索没召回”“工具参数不合法”“缺少验证”“权限决策错误”等可行动的问题。评估不是发布前的一次考试，而是 Agent 工程持续获得反馈的接口。