[2026] MobilityBench：打破真实出行黑盒，高德地图开源首个真实场景路线规划智能体基准

TL;DR

随着大语言模型（LLM）能力的跃迁，能够调用工具的“智能出行助理”正成为现实。然而，如何衡量这些智能体在复杂、多变的真实路网中是否真的“靠谱”？本文介绍了 MobilityBench，这是首个利用大规模真实匿名用户查询构建的路线规划智能体基准测试，配套确定性沙盒环境，旨在为出行场景下的 AI Agent 提供一把严苛的刻度尺。

1. 痛点深挖：为什么评价出行助理这么难？

在真实的城市计算任务中，路线规划远不止“从 A 点到 B 点”：

• 语义复杂性：用户会说“帮我找个加油站，避开高速，顺便路过一下某超市”。
• 环境非确定性：如果你今天测 GPT-4 走这条路，明天测 Claude 走这条路，由于路况（Traffic）变了，API 返回的耗时完全不同，无法进行科学的消融实验。
• 评估维度缺失：仅看最终是否到达目的地（Success Rate）太粗糙，无法诊断智能体是在“理解指令”阶段错了，还是在“工具调用”参数传错了。

2. 核心架构：场景分类与确定性沙盒

MobilityBench 最大的贡献之一是其任务分类法（Task Taxonomy），将用户意图划分为 11 个场景，包括基础信息检索、路径依赖检索、基础规划及最具挑战性的偏好约束规划（Preference-Constrained Planning）。

为了解决复现性难题，作者构建了一个 API-replay Sandbox。该沙盒缓存了 22 个国家、350 多个城市的真实 API 响应。智能体调用的 API 都会被拦截并重定向到固定的缓存数据中，这相当于为 AI 实验冻结了“时空”，保证了不同模型在同一路况下进行博弈。

3. 方法论：多维度诊断评估协议

MobilityBench 不再把 Agent 当作黑盒，而是分解为四个核心能力点：

1. Instruction Understanding (IU)：考查意图识别（ID）和信息抽取（IE）的准确性。
2. Planning：通过 DEC-P/R 指标看原子动作的分解是否冗余或遗漏。
3. Tool Use：关注 API 的 schema 合规性（SC）和参数填充精度。
4. Decision Making：衡量最终交付率（DR）和通过率（FPR）。

4. 实验发现：SOTA 表现与“思考”的代价

作者对 Qwen, DeepSeek, GPT, Claude, Gemini 等主流模型进行了详尽评估。

主要结论包括：

• 模型梯度明显：Claude-Opus-4.5 和 Gemini-3 系列在处理复杂指令上依然领先，但国产模型如 Qwen3-235B (MoE) 在 ReAct 架构下展现了极强的竞争潜力。
• ReAct vs. Plan-and-Execute：实验证明 ReAct（思考-行动-观察）闭环模式在动态反馈场景下鲁棒性更好，但代价是 Token 消耗增加了约 35%。
• Thinking Mode 的魔力：引入类似于 DeepSeek-R1 的“思考过程”能让 Qwen-30B 的最终通过率提升约 6%，证明了慢思考对于路径优化这种逻辑密集型任务的价值。

5. 深度洞察：Preference-Constrained 是最后的高地

如下图的雷达图所示，大多数模型在基础任务（左侧）表现接近满分，但在偏好约束规划（PCP）（右侧）明显缩水。这意味着当用户提出“不走外环、少换乘、带孩子方便的路线”等模糊且相互制约的约束时，Agent 的推理链条极易断裂。

总结与局限

MobilityBench 为行业提供了一个扎实的实验平台，尤其是它对真实语音查询（Voice Queries）的重视，抓住了移动端出行的核心交互模式。其局限性在于目前仍遵循“不与用户澄清”的假设，而真实的出行助理往往需要通过多轮对话来对齐（Alignment）用户的模糊意图。

这项工作预示着，未来的导航不再是简单的 A* 搜索，而是一场基于语义理解的复杂逻辑博弈。