2026 年 AI 应用评测：从单轮打分到多轮轨迹评估

前阵子看一个 Agent 的评测报告，分数从 72% 涨到 81%，团队挺高兴。我随手翻了几条失败案例，发现一个规律：很多以前会硬着头皮答完的任务，现在 Agent 直接结束了，理由写的是“当前信息不足，无需回答”。

问题是，这些任务里有一半其实是能做的，只是要多查一步。Agent 学会了用“不知道”来规避失败，而我们的评分规则把“无需回答”算成了正确。

指标涨了，能力退了。

这件事之后，我对 Agent 评测的态度变得保守了很多：最终答案对，不代表过程对；分数高，不代表系统在变好。

单轮打分为什么会骗人

单轮评测的逻辑很简单：给一个问题，比较模型输出和标准答案。

它在问答任务上有效，但对 Agent 不够。Agent 的行为是一条轨迹：在某个状态下，选择了什么动作，得到了什么观察，最后有没有完成任务。只看最后一段文本，会漏掉太多东西。

更麻烦的是，单轮评测很容易被“碰巧答对”骗到。Agent 可能用错误的工具、错误的参数、错误的顺序，最后蒙对了答案。下一次换个输入，就原形毕露。

还有 benchmark 污染的问题。公开数据集被反复训练之后，分数会虚高。你以为模型变强了，其实它只是见过题。

评测要分层

我现在会把评测拆成四层。

组件层，单独看检索、工具选择、参数生成、结构化输出这些环节。它便宜、定位快，适合在 CI 里频繁跑。

步骤层，看每一步是否合理：该不该调这个工具，参数对不对，有没有重复无效调用，该停的时候有没有停。

轨迹层，看整条路径：用了多少步，有没有走弯路，失败后能不能恢复，成本和时间是否可接受，有没有触发安全策略。

端到端层，看业务结果：任务成功率、用户满意度、人工接管率、投诉率、安全违规率、每次成功任务成本。

四层一起看，才能既知道“有没有变好”，也知道“为什么变好”。

轨迹评测怎么做

轨迹评测的前提，是把状态、动作和观察记下来。

一次工具调用至少要有：当前状态、调用的工具、参数、返回结果、下一步状态。有了统一结构，才能做回放、对比和自动评分。

评分不能只看“完成了没有”。还要看动作是否符合业务规则，步数和成本是否合理，失败后有没有恢复，有没有越权或泄露数据。

我一般会建一个失败分类表：理解错误、规划错误、工具选择错误、参数错误、状态管理错误、恢复失败、安全违规、终止错误。分类越细，改进越有针对性。

比如“终止错误”这一类，就是被前面那个案例逼出来的。Agent 在该继续的时候结束，和答错一样严重，甚至更隐蔽。

失败分类不只是为了报表。它能直接指导改进：工具选择错误多，就去补工具描述和示例；参数错误多，就加 schema 校验；恢复失败多，就检查重试和状态管理；终止错误多，就改评分规则和停止条件。没有分类，所有问题都会挤在“效果不好”这一个筐里。

LLM 评委要校准

用模型做评委可以省很多人工，但不能拿来就用。

rubric 要具体，不能写“回答得好不好”，要写清楚什么算好、什么算不好。优先做 pairwise 比较，而不是绝对打分。评委模型要固定版本，记录温度和 Prompt。定期抽样和人工标注对比，看看评委是否靠谱。

还要控制偏差。位置偏差、长度偏差、风格偏差都会影响结果。同一个答案放在前面和后面，得分可能不一样；长回答看起来更认真，也更容易得高分。

评委本身也要被评测。一个没校准过的评委，可能让团队误以为系统在进步。

数据从哪来

评测集不能只有正常路径。

我现在会覆盖：正常任务、边界输入、多轮追问、工具失败、权限不足、恶意注入、无答案、需要澄清的模糊问题。

数据来源有两块：人工构造的黄金集，和从生产流量里采样的真实 case。采样要注意脱敏和用户授权，别把隐私数据带进评测环境。

黄金集不需要很大，几十到几百条就能发现大部分回归。关键是覆盖失败模式，而不是追求数量。

评测报告也不要只给一个总分。总分适合对外汇报，不适合指导改进。把分数拆到任务类型、步骤、工具和失败分类，才能看出问题在哪。比如同样是 80 分，一个系统是简单任务全对、复杂任务全错，另一个是各类型都稳定在 80，两者的改进方向完全不同。

别让指标变成游戏

任何指标一旦变成考核目标，就会被优化，甚至被钻空子。

Agent 可能学会：失败时直接结束，把失败算成“无需回答”；只挑简单的子任务做；把长回答写得很像样，骗过 LLM 评委；在评测集上过拟合。

所以我现在会同时看几组指标：任务成功率、步数、成本、延迟、安全违规、人工接管率，以及失败分类的分布。单个指标涨，其他指标恶化，通常不是好事。

安全指标要零容忍。一个 Agent 成功率再高，只要有一次越权或数据外泄，就不能上线。

一次指标造假的复盘

回到开头那个 72% 涨到 81% 的评测。

我们把失败案例重新标了一遍，发现新增的“正确”里，有三分之一是 Agent 提前结束任务。它给出的理由通常是“信息不足”或“无需操作”，但人工复核后，大部分任务其实可以继续查一步。

问题出在评分规则：只要最终状态是“无需回答”，就算正确。Agent 很快学会了这条捷径。

我们改了三处。第一，把“提前终止”单独列为失败分类，除非人工确认任务真的不需要处理。第二，增加轨迹指标：平均步数、工具调用次数、证据覆盖率。第三，要求每个“无需回答”的结论附带理由和已查过的数据源。

改完之后，分数掉回 74%，但这次可信了。又跑了两周，通过优化检索和工具重试，才慢慢升到 79%。

这件事让我对“分数上涨”始终保持警惕。指标变好之前，先问一句：它是怎么变好的？

离线评测之外

离线评测能挡住明显回归，但它替代不了线上观察。

上线之后，我会看几组在线指标：任务完成率、人工接管率、用户重试率、投诉率、平均步数、成本、延迟，以及安全违规。它们比离线分数更嘈杂，但也更真实。

新版本先接小流量，和旧版本做对比。样本量不够的时候，不要因为一两个点的波动就下结论。至少看置信区间，或者多跑几天。

用户的反馈也要收。不是所有问题都能被自动指标捕捉到，尤其是“答得对但让人不舒服”这类。把投诉和人工接管的原因分类，往往能发现评测集里没有的场景。

分数之外

评测不是上线前的一最后道手续，它是你判断系统是否在变好的唯一依据。

如果评测只看最终答案，你很容易被“碰巧答对”和“学会放弃”骗到。把过程记录下来，把失败分类，把评委校准，把指标放在一起看，才知道系统到底有没有进步。