RideWay: 工具使用语言代理的高效任务完成基准测试

# RideWay：面向工具使用语言代理的高效任务完成基准测试  
来源：https://arxiv.org/html/2609.17985  
Boli Fang††注释：同等贡献。通讯作者。Mingzhi Hou，Claire Liu  
所属机构：滴滴全球  
联系邮箱：summerhan, bolifang, houmingzhi, [email protected]  

###### 摘要  
AI代理的评估通常基于任务是否完成。在交互式服务场景中，即使任务成功，代理也可能因重复提问、冗余搜索或不必要的修改而使用户体验受挫。我们提出**RideWay**——一个面向有状态工具调用环境中网约车代理的效率评估基准，同时引入**效率效用**指标：该指标以成功为前提，根据相对于任务特定基准所需的额外工具调用次数与用户交互轮数进行折扣校准。人类配对偏好实验为相对惩罚赋予权重，反映了整体服务流程的权衡：额外对话常带来明显摩擦，而额外工具调用有时用于验证约束或保留用户意图。通过对58项任务和24个模型的测试，结果表明：额外交互轮数的惩罚系数约为额外工具调用的两倍。在任务互斥的留出偏好数据上，效率效用整体准确率达78.7%：当轨迹差异体现在交互轮数时准确率为90.6%，但当差异仅存在于工具调用时（此维度上人类标注者一致性最低）准确率降至随机水平。因此，RideWay使交互效率能够与任务成功率一同量化，并揭示了基于计数的工具使用评估方法的局限性。  

## 1 引言  
工具使用代理的评估不仅应关注任务是否完成，还需关注其*完成方式*。在网约车服务中，两个代理可能都成功完成有效行程：一个确认约束后直接完成，另一个则经历多次澄清或不必要修改才达成相同结果，给用户带来更显著的负担。但更多操作未必是浪费：例如在预订前检查多个候选上车点的行程时间，虽比直接猜测产生更多工具调用，却更可能保留用户的约束条件。仅关注成功的评估器无法区分这些情况，而简单的操作计数惩罚则会将有效验证与无谓摩擦混为一谈。因此，评估成功的代理需要以成功为前提的效率度量，该度量需分离用户交互轮数与后台工具调用，并通过人类偏好学习其相对成本。  

现有交互式代理基准使任务完成度的量化日益精确，但往往对服务用户方式差异显著的成功轨迹赋予相同评分（Liu等, 2024; Yao等, 2024; He等, 2025; Mazaheri与Mazaheri, 2026）。因此，仅基于结果的评分无法衡量用户对话与后台工作的不同综合负担，即使轨迹达成相同结果。  

这些考量推动了**RideWay**（代码、数据与复现脚本详见：https://anonymous.4open.science/r/RideWay-368B/；附录B详细说明复现方法）的提出——面向网约车代理的效率评估基准与评分协议。网约车作为测试平台具有优势：交互天然具有多轮次、工具密集的特点，需要地理定位、偏好追踪与路径调整，同时又足够具体，可通过行为准则和后台状态进行评估。我们在中文环境下研究这一场景——该资源丰富的语言在服务型代理基准中仍相对缺乏代表性。  

这一场景引出了仅以成功为导向的评估未能解决的问题：*如何衡量成功AI代理的交互效率，而不仅限于其成功与否？* RideWay通过**效率效用**指标回答此问题：这是一个以成功为前提的评分，失败轨迹得分为零。对于成功轨迹，它仅对超过任务特定基准（Anderson等, 2018）的额外努力进行折扣，分别建模用户交互轮数与后台工具调用的超额部分，并通过盲选人类配对比较（Bradley与Terry, 1952）校准相对惩罚权重。  

总结贡献如下：  
- • 提出**RideWay**：面向有状态工具调用环境中网约车代理的评估基准，包含模拟用户、分层成功判定与任务特定基准标注。  
- • 提出**效率效用**：以成功为前提、基于基准相对度量的指标，区分工具调用与用户交互轮数的超额部分，并通过盲选人类配对偏好拟合其综合惩罚权重。  
- • 在任务互斥的留出人类偏好数据与鲁棒性检验中验证效率效用：用户交互轮数的超额部分获得一致且经留出验证的显著惩罚；而工具调用维度标注者一致性较低，揭示了基于计数的效率评估可靠性的边界。  

## 2 背景与相关工作  
交互式代理基准已将语言模型评估从静态问答转向可执行环境中的多轮行动。工具使用与推理行动研究关注语言模型如何与外部动作或API调用交织（Yao等, 2023; Schick等, 2023），而函数调用与环境基准则测试API选择、模式遵循、网页交互、编程及多步骤任务执行（Qin等, 2024; Yan等, 2024; Shridhar等, 2021; Yao等, 2022; Deng等, 2023; Zhou等, 2024; Jimenez等, 2024; Liu等, 2024; Zhang等, 2024; Yoran等, 2024; Drouin等, 2024; Ma等, 2024）。这些基准使代理行为更可观测，但主要评分通常仅关注代理是否达到正确最终状态或完成请求任务。  

工具-代理-用户基准与RideWay最为接近，因为它们要求代理同时管理对话状态与工具状态。τ-bench与τ²-Bench构建了在真实领域中与用户和工具交互的对话代理（Yao等, 2024; Barres等, 2025）；VitaBench通过用户状态、数据库状态、对话动作、工具调用与任务奖励形式化生活服务任务（He等, 2025）；T1-Bench则通过固定模拟器与评判配置扩展此路线至多场景代理评估（Winata等, 2026）。三者均评分任务完成度或奖励，未评分*成功轨迹的实现路径*。  

RideWay遵循其工具-代理-用户前提，并在成功评估之上增加正交测量层：基于双轴、人类校准的努力惩罚，将后台工具调用与用户交互轮数分离，而非将轨迹质量压缩为单一完成信号。轨迹敏感评估关注代理的路径选择而非仅最终答案。在具身导航中，路径长度加权成功率仅对成功代理给予奖励，并对不必要长路径进行折扣（Anderson等, 2018）。代码与代理基准使用重复尝试或pass@k式指标区分偶然成功与可靠任务完成（Chen等, 2021）。然而对于服务型语言代理，轨迹努力并非单一路径长度：澄清对话、数据库检查、状态修改调用与偏好保持式修改可能对用户产生不同影响。  

因此，RideWay通过任务特定基准测量两个可观测努力轴：用户交互轮数与后台工具调用。当绝对评分困难时，人类偏好建模为校准这些努力轴提供了方法。Bradley-Terry配对比较模型从比较判断中估计潜在偏好（Bradley与Terry, 1952），基于偏好的学习更广泛地从人类选择而非手动指定的标量标签推断效用（Ng与Russell, 2000; Abbeel与Ng, 2004; Christiano等, 2017; Ouyang等, 2022; Rafailov等, 2023; Azar等, 2024; Nika等, 2024; Zheng等, 2023）。  

RideWay局部应用此思想：标注者比较同任务成功轨迹的效率，拟合的惩罚将判断转化为任务相对评分。这与高效LLM研究不同——后者关注模型压缩、推理成本、延迟或碳足迹（Chen等, 2023; Wan等, 2024; Zhu等, 2024; Xia等, 2024; Faiz等, 2024），衡量计算系统而非用户交互路径。  

## 3 RideWay 基准测试  
RideWay通过生成有状态工具-代理-用户轨迹评估网约车代理，并通过独立LLM成功判定面板进行筛选（图1）。每项任务均为被评估代理、模拟用户与数据库支持工具环境之间的交互式episode，遵循近期工具-代理-用户基准设计（Yao等, 2024; Barres等, 2025; He等, 2025; Winata等, 2026）：代理进行对话并调用网约车服务工具，直至完成工作流或终止，产生包含用户对话与后台动作的轨迹。随后，三判断LLM面板根据任务准则与后台状态评估轨迹，确保未完成或违反约束的尝试被标记为失败而非高效完成。  

#### 设计目标。  
RideWay的任务集构建旨在使效率成为有意义而非偶然的属性。任务需多重决策、存在多种合理解决方案路径、可通过准则与后台状态评分，并包含任务特定基准，使约束更多的工作流不会因需更多交互而比简单任务受罚。  

**表1**：RideWay基准统计数据（总体与分组）。数值单元格显示每任务最小-最大（均值）；工具清单与语言详见下文。  
**图1**：RideWay三阶段流程：轨迹生成、轨迹评估与效率校准。  

#### 环境与工具。  
环境提供26种网约车服务工具：18种读取工具与8种写入工具。读取工具涵盖保存地址查询、当前位置、兴趣点与附近搜索、地理编码、历史/订单查询、行程估价、行程时长估算、司机匹配、航班信息、路线搜索与实时行程状态。写入工具涵盖车型选择、即时与预约行程创建、行程确认、取消、目的地更新、行程提醒与行程备注。底层状态包含用户配置字段、保存地址、车型、动态生成的司机候选、当前与历史行程订单、兴趣点数据、路线估算及预订状态。工具调用可读取或修改此状态，因此代理需同时追踪用户潜在意图与环境变化。  

#### 任务构建。  
RideWay包含58项手动策划的网约车任务（44项用于校准的任务集，14项任务互斥的自定义任务集用于留出验证）。任务围绕能力标签组织，强调起止地定位、订单类型选择、显式与隐式偏好、上下文延续、时间推理、历史回忆、模糊地点、司机推荐、弱信号推理、禁止主动下单行为、路线规划与路径调整。许多任务在初始语句中隐藏约束，或要求在修改后保留早期偏好。  

#### 语言与地域。  
RideWay为中文基准：任务指令、模拟用户语句与用户端代理响应使用简体中文，而结构化工具调用保留英文API标识符，形成中英混合界面。其依赖语言与文化的效率偏好不应假设可无变更地迁移至其他地域。  

#### 准则与基准努力。  
每项任务包含用户场景、初始查询、评分准则及两个人类基准努力字段。为获取基准值，精通中文的标注者作为支持代理执行每项任务，在与构建任务相同的指令下与用户LLM交互；我们使用其工具调用次数与助手轮次数的中位数作为$f_{\mathrm{tool}}(x)$与$f_{\mathrm{turn}}(x)$（58项任务数据：调用次数3-22次，均值7.5；轮次数3-23次，均值9.1；准则项2-11项，均值5.2）。这些基准值是任务相对锚点而非理论最短路径，用于避免跨不同网约车工作流比较原始交互长度。  

#### LLM面板评估。  
RideWay采用保守的LLM-as-a-judge成功判定机制，避免将偶然的单次评估视为已解决（Zheng等, 2023; Panickssery等, 2024）。每条轨迹由三个不同LLM组成的面板判定；每个评判器运行3次并采取多数投票，仅当至少两个评判器通过时轨迹才判定成功。这种层级聚合降低了对单一模型族准则解释的依赖。评判器温度设为0；由于真正的API级非确定性，3次通过仍在2-3%的轨迹上存在差异，因此多数投票控制实际噪声而非重复相同调用。三个评判器（hy3-preview, seed2.0-lite, grok4.3）均不属24模型代理池，限制了同族评判可能引入的自我偏好偏差（Panickssery等, 2024）。  

## 4 效率效用指标  
效率效用继承其