任务完成了，用户却更烦了
评估智能体时，最常用的指标是「任务是否完成」。这个指标简单、跨领域可比，也因此被大量基准沿用。但它遮住了一个在真实服务里很常见的情形：任务确实完成了，过程却让人不痛快。
反复追问同一个信息、做多余的检索、把已经确认过的步骤再走一遍——这些行为都不会让任务失败，却会让用户觉得对面「没听懂」。9 月 16 日提交到 arXiv 的 RideWay（编号 2609.17985）就是冲着这个盲区来的。
为什么把场景选在网约车
论文把环境设成有状态的工具调用，具体场景是网约车。这个选择不是随手挑的：它同时具备几个适合观察效率的条件。
一是任务有明确的完成判定。车约到了就是约到了，不需要争论。二是过程摩擦完全可见。用户每一轮对话都在场，多问一句、多确认一次，用户立刻能感觉到。三是工具调用次数与用户轮次可以被清楚地区分开——这在多数基准里是被合并统计的，而这篇论文恰恰要把两者拆开看。
作者把这类问题归成一句比较克制的话：一个成功的智能体，仍可能因为反复提问、冗余检索或可以避免的返工而让用户不满。
Efficiency Utility 是怎么算的
论文提出的指标叫 Efficiency Utility，直译大致是「效率效用」。它的结构里有一个容易被忽略的设计：受成功门槛约束。
意思是，先看任务有没有完成。没完成，效率再高也不计入——这一点很关键，否则就会出现「什么都不做、所以步骤为零」的最优解。在成功的前提下，再看它比「任务参考工作量」多用了多少额外工具调用、多花了多少面向用户的轮次，然后对超出的部分折价。
「任务参考工作量」这个基准值是按任务单独设定的，不是全局统一阈值。这符合直觉：不同任务本来就需要不同数量的工具调用，用一个统一标准去衡量全部任务，等于把任务难度当成了噪声。
惩罚权重为什么要用人类偏好来定
折价的比例如果全靠研究者拍板，指标的可信度就很有限。论文的做法是引入人类配对偏好来校准：把两条轨迹摆在一起，让人判断哪一条体验更好，再用这些判断去拟合两类多余行为的相对惩罚。
拟合出来的结果值得注意。多余额外轮次的惩罚，大约是多余工具调用惩罚的两倍。
为什么差距这么大，论文给了解释：服务流程里，额外的对话往往会直接制造可见的摩擦；而额外的工具使用有时是在核对约束、确认条件，反而可能是在保护用户意图。同一个「多花了功夫」，落在用户侧和系统侧，代价不一样。
这条结论对做产品的人有直接含义：不要把所有「多余」一视同仁地砍掉。该压缩的是用户能感知的那部分，系统内部的必要核对要保留。
58 项任务、24 个模型上测出了什么
实验在 58 项任务、24 个模型上进行。结果分成了三层。
整体上，Efficiency Utility 在任务不相交的留出偏好上达到了 78.7% 的准确率。这个数字意味着，它能以接近八成的把握判断出两条轨迹里哪一条更让用户舒服。
拆开看差别就大了。当两条轨迹的差异体现在轮次上时，准确率升到 90.6%——也就是说，人对「多问了几轮」这件事的判断相当一致，指标也抓得住。
而当两条轨迹的差异只体现在工具调用上时，指标退化到了随机水平。
那个「接近随机」的结果才是重点
在很多评测报告里，「某一项退化到随机水平」会被当成瑕疵略过。但在这篇论文里，它更像是主要发现之一。
原因在于，标注者在这一轴上分歧最大。也就是说，两个人的偏好判断本身就很难统一——因为多调用几次工具，究竟算低效还是算谨慎，取决于上下文和判断者的立场。既然人类自己都难以形成稳定共识，那么用一个固定的惩罚系数去拟合它，本身就不可能做好。
这条结论直接指向一种常见的评测习惯：用工具调用次数来衡量智能体效率。论文用数据说明，这条路在「仅工具调用有差异」的情形下是有上限的。它不否定按次数统计的价值，但明确指出次数本身不足以代表效率。
对做评测的人来说，推论是比较实用的：如果一项指标在人类标注一致性低的维度上表现接近随机，那么它反映的是这个维度的定义还没稳定下来，而不是模型不够好。
这套指标能外推到哪里
论文自己也点出了场景的边界。网约车属于交互密集、摩擦即时可见的服务场景，在这里「多问一句」的代价很高。换到别的领域，结论未必成立。
举例来说，在需要多轮核查的场景里，多确认一遍可能是必要的合规动作；在一次性、批处理的场景里，用户根本不在场，轮次这个维度甚至不适用。因此 Efficiency Utility 更适合被看成一种方法示范：把效率从成功率里剥出来，并且用人类偏好去校准折价权重——而不是一套拿过来就能直接套用的通用指标。
为什么用配对偏好，而不是绝对打分
论文选择让标注者比较两条轨迹，而不是给单条轨迹打一个分数。这个选择在方法上有讲究。人对绝对分数的尺度很难保持一致——同样是「多绕了两轮」，心情好的时候评 4 分，赶时间的时候评 2 分。但把两条摆在一起问「哪条更顺」，判断会稳定得多。
代价是配对偏好需要更多标注量，而且只能间接推出绝对阈值。论文最后用拟合出的相对惩罚来构造指标，走的正是这条路。
论文没有说的部分
从公开摘要能看到的，是任务数量、模型数量、惩罚比例的拟合结果与准确率。看不到的是这些模型在网约车任务上的绝对成功率、单次运行的 token 与延迟成本，以及效率折价之后对模型排名的实际影响。
这几项缺失会影响到一个实际判断：如果高效率模型的成本优势被折价吃掉，那么「选哪个模型」的答案可能和单看成功率时完全不同。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
把「好」这件事拆成两件事
这篇论文的价值不在于又提供了一个排行榜，而在于它把服务型智能体的「好」拆成了两层：一层是把事办成，另一层是别让用户为办成这件事付出额外的沟通成本。
两层之间并不总是同向的。有的模型愿意多问几句来降低猜错概率，在成功率上获利、在体验上吃亏；有的模型干脆利落，成功率略低但交互干净。过去的基准把这两种取舍压在同一个数字里，等于默认了它们可以互相抵扣。RideWay 的意义，是把这笔账摊开让人自己算。