Agent 的轨迹评估和单轮问答评估有什么不同？

单轮问答只要看最终答案对不对，Agent 是多步的，所以除了结果还要看过程——它调了哪些工具、顺序对不对、有没有多余的调用、有没有死循环。做法是准备参考轨迹，把实际调用序列和参考序列比对，看是否完全一致、或者是否按顺序包含了关键调用。另外还要看步数和成本，因为 Agent 可能绕很远才做对。

这个答案抓住了核心差异（结果 vs 过程），也提到了成本，能过。

它止步于 60 分的原因是：它把「和参考轨迹比对」当成了默认方案，而这在真实项目里几乎不可持续。而且它没提副作用，也没提层级顺序。

我认为有三个本质差异，然后有一个很现实的工程妥协。

差异一：Agent 有副作用，单轮问答没有。 单轮问答评错了，代价只是一个错答案。Agent 评错了，可能真的发了邮件、真的退了款、真的改了工单状态。所以 Agent 评测的第一件事不是指标，是沙箱：工具要有可替换的 mock 实现，环境要能快照和回滚。没有沙箱就没有轨迹评测——你不敢跑第二遍的东西不叫评测。 而且这带来一类单轮问答完全没有的指标：状态断言——不只看它说了什么，还要看跑完之后世界变成了什么样（该建的工单建了没、不该改的字段动了没）。

差异二：结果对不代表过程对。 典型形态是「碰巧对」：它没调检索工具，靠参数记忆答对了；或者调了 9 次工具、其中 7 次是重复的无效调用，最后蒙对。只看端到端结果，这两种都是满分，但前者会在数据一变就崩，后者是成本黑洞。 常见的轨迹指标大致是这一套：完全匹配 / 有序包含 / 无序包含 / 精确率 / 召回率 / 特定工具是否被调用。有序包含是「参考里的关键调用按顺序都出现了，允许有多余的」；精确率惩罚多余调用；召回率看关键步骤有没有漏。 实践上要说一句大实话：完全匹配在真实 Agent 上几乎恒为 0，把它放上看板只会让人麻木。真正能用的是有序包含 + 精确率 + 特定工具是否被调用（后者当安全关卡用：必须调过权限校验工具）。

差异三：步数、耗时、token 本身就是质量指标。 单轮问答的成本是个常数，Agent 的成本是分布，长尾能差一个数量级。所以评测报告里必须并列成功率、平均步数、P95 步数、单次成本。一个成功率 +2%、平均步数 +40% 的版本，通常不该发。

然后是那个工程妥协——参考轨迹标不起，怎么办。 参考轨迹是整个评测体系里最贵的标注，而且 Agent 的 prompt 一改，轨迹就变，评测集腐化极快。所以我们生产上真正在跑的，大部分不是「和参考轨迹比对」，而是负向轨迹断言 / 不变量检查：不要求它走哪条路，只要求它不越界。比如——

• 不许没调 check_permission 就返回用户数据；
• 不许连续 3 次调同一工具同一参数（死循环）；
• 不许在只读会话里出现写工具；
• 不许在没有检索命中的情况下给出带具体数字的结论。

这等于把轨迹评测从「标准答案匹配」降级成「不变量检查」，标注成本降一个数量级，而且不随 prompt 改动腐化。 参考轨迹只保留在少数几条关键主流程上。

最后是层级顺序：先建端到端（结果对不对 + 状态对不对），只有端到端掉分时才下沉到轨迹级，轨迹级也定位不了才下沉到组件级。反过来做——一上来给每个环节配指标——会得到一堆互相矛盾的分数，没人知道该信哪个。

补一条 2026 特有的：effort 档位必须是评测矩阵的一个维度。降档位会直接改变工具调用次数，也就直接改变轨迹指标和成本。换档位和换模型一样，要走完整回归，不能当调参处理。