聊天分高Agent照样不能用

我见过这种场面不止一次。一个客服 Agent 在对话评测集上拿 92 分，全组庆祝，两周后上线，投诉翻倍。分是真的，不能用也是真的。

问题出在评测对象错位了。那 92 分评的是"它单句答得好不好"，线上用户要的是"它能不能把这件事办完"。

三处对不上：

• 评测集是一问一答，Agent 干活是多步循环：想、调工具、看结果、再想。中间任一步歪了，后面全歪，而且评测看不出来。
• 评测只跑一次就给分，Agent 同一句话跑两次可能走出完全不同的工具序列。单次得分把随机性盖住了。
• 评测只看答得对不对，不看花了多少 token、多少秒。一个能做完但比基线贵 100 倍的 Agent，上不了线。

这篇先把差异说清，后面分别针对（任务集、轨迹、工具调用、可靠性、安全、闭环）展开讲讲。

看清目标明确阶段

评 Agent 之前，先确认你评的是哪一层。三层不是替代关系，是递进关系：

• 单轮输出：能发现知识错、格式错、语气差，发现不了多步任务能不能办完。如果你的 Agent 只会问答，这一行就是全部，到此为止。
• 多步轨迹：能发现绕路、选错工具、重复调用、中途放弃，发现不了同一任务反复跑是否稳定。稳定性单起一篇讲 pass^k。
• 端到端任务：能发现真实成功率、可靠性、性价比，发现不了失败具体卡在哪一步。这一条要轨迹分来补。

三层是递进不是替代：上一层能发现的，下一层都继承了；下一层新增的是上一层看不见的。所以往上走一层，前面的指标一个都不用丢。

阶段怎么选

Agent 评测的三个本质：评轨迹不评答案、非确定性必须多次跑、成本与延迟是一等指标。 相关agent评测文章都建立在这三条上。

一、评轨迹不评答案

LLM 评测评的是"输入到输出"这一跳。Agent 评测评的是一条路径：它规划了什么、调了哪个工具、拿到结果后怎么调整、最后有没有收口。

为什么轨迹重要？因为结果对可能是蒙的，过程错一定会再错。一个 Agent 用错误的工具顺序凑出了正确结论，这次算它过，下次换个输入就崩。只评答案的评测集，对这类问题零覆盖。

业界已经把这个共识写进方法论：评 Agent 要评多步轨迹，而不是单轮回答，因为错误会跨步累积，而部分进展本身有价值。所以轨迹评测要同时看两件事，任务有没有完成，以及路径是不是合理。

一个具体的坑：早期我们只记"任务成功/失败"，一次失败排查了两天才发现，Agent 其实前 8 步全对，第 9 步调用了一个不存在的字段，工具返回空，它没有重试策略，直接把空值当结果编了一段回答。任务级 pass/fail 完全盖住了这个信息。后来加了步骤级记录，同一类问题从"两天"变成"看一眼轨迹就知道"。具体怎么打过程分，03 篇展开。

二、非确定性：单次跑通不算数

同一个 prompt、同一个模型、同一个温度，Agent 两次运行的路径可能完全不同。工具返回带随机性（网络、API、环境），模型采样带随机性，两者叠加。

这意味着两件事：

第一，单次 pass/fail 会骗人。 跑一次成功，可能是它稳定成功，也可能是它运气好。五种可能里中了唯一一种，和每次都中，看起来都是"pass"。

第二，可靠性才是墙，不是能力。 Sierra 的 τ-bench 专门做了这个区分：它同时报 pass@k（k 次里至少成功一次）和 pass^k（k 次全部成功）。公开水位是前沿 Agent 单次成功率不到 50%，连续 8 次全成的概率不到 25%。也就是说，一个"跑一次能过"的 Agent，连着跑 8 次还能全过四分之一都不到。

这两个指标不是一个东西：

• pass@k 测能力上限，允许它试错。
• pass^k 测一致性，等价于生产里"用户连着用 8 次都顺利"。

生产要的是后者。一篇 Agent 需要用户重试的场景，重试成本就是用户的信任。这套度量 05 篇专讲。

三、成本与延迟是一等指标

LLM 评测时代，成本是账单问题。Agent 评测时代，成本是能力问题：它直接反映路径效率。

同样把任务办成，两个 Agent 一个调 3 次工具，一个调 30 次，谁更可用？显然前者。冗余调用意味着推理绕路、上下文膨胀、出错面变大，还顺带把延迟推高。

所以要跟准确率一起记的，至少三样：token 消耗/任务、工具调用次数/任务、端到端耗时。业界方法论里把这条列为 Agent 评测与 LLM 评测的明确差异，理由是"能做完但贵 100 倍"的方案不算可上线。

一个坑：我们曾有个版本任务完成率提升了 4 个点，全组很高兴，一查平均调用次数从 6 涨到 21，token 成本翻了 3 倍多。按贵出来的钱算，那 4 个点不划算。如果评测里没有成本列，这种退步永远不会被发现，因为它在"分数"上是涨的。

四、scaffold 依赖：同模型分数能差两位数

这条最容易被忽略。Agent 的分数不只由模型决定，还由外壳决定：prompt 设计、工具访问权限、重试预算、执行环境、评估器版本。

公开信息里有一句必须记住的警告：同一个模型，厂家用自己的 scaffold 跑出来的分和第三方评估器跑出来的分，能差两位数。所以看到"某某模型 SWE-bench 80%"时，正确的下一个问题是"用什么 scaffold、什么工具栈、什么重试策略"，而不是"那可以上线了"。

对我们的意义很直接：看榜定方案是错的，必须用自己的任务集、自己的工具栈复测。公开基准只能用来定位"大概在什么水位"，不能当验收结论。而且基准本身会腐化，2026 年有研究指出 8 个主流 Agent 基准都能被 reward hacking 到接近满分，原因包括评测环境把答案暴露在环境变量里、评分用例本身写错、以及只报单次运行掩盖随机性。这三类问题的反面，本系列计划起3篇的内容。

五、这三条差异，怎么落到你的评测里

不用推翻重来，改三处就够：

1. 评测记录从"最终答案"扩到"步骤轨迹"：每次工具调用记下工具名、参数、返回值、耗时。这是轨迹评测的数据底座。

2. 每次评测跑 k 次，报 pass^k 而不只是 pass@1：k 取 3 到 8，按任务耗时定。同时报方差或置信区间，让小样本的结论自己现形。

3. 成本列进评测报告：token、调用次数、耗时三个数，和准确率并排。任何"分数涨了但成本暴涨"的版本，先看性价比再谈发布。

和已有四件套怎么接：评测集、评分卡、裁判、难负这四样照样用，只是评测集里每条任务要多带一个"初始状态"和"验收标准"，评分卡要多一列"过程分"，裁判要看轨迹而不只看答案。

一句话收尾

Agent 评测难在它评的东西会动：路径会变、结果会飘、成本会涨。你的评测集里，现在记的是最终答案，还是那条走完的轨迹？