MobilityBench: A Benchmark for Evaluating Route-Planning Agents in Real-World Mobility Scenarios

Paper: arXiv:2602.22638 Code: AMAP-ML/MobilityBench Code reference: main @ da07a8c5 (2026-03-04)

1. Motivation（研究动机）

现有 agent benchmark 没有真正覆盖“日常出行路线规划”

LLM-based tool agent 已经可以把自然语言推理和外部 API 调用连接起来，但 route-planning agent 的难点比一般 tool-use 更贴近真实世界：用户请求里同时包含地点、当前位置、出发/到达时间、交通方式、偏好（如“不走高速”“少换乘”“避开某条路”）、多途经点和动态路况。一个可部署的出行 agent 不只要“生成看起来合理的回答”，还必须正确识别意图、补全 API 参数、调用地图/天气/路况/路线工具，并输出满足约束的可执行 itinerary。

TravelPlanner / TravelBench 这类工作更偏高层旅行行程或抽象约束推理，不能充分诊断地图环境里的细粒度工具链：例如地名要先 geocoding，路线要区分 driving / bus / bicycling / walking，实时交通和天气会随时间变化，同一个 live API 在不同日期可能返回不同答案。若直接连线上地图服务评测，结果会被交通状态、POI 数据更新、服务限流和后端版本影响，难以复现，也难以公平比较不同 LLM 或 agent framework。

论文要解决的具体问题

MobilityBench 的目标是把真实 Amap 用户出行查询转成可复现的、episode-centric 的 route-planning agent benchmark：每个 episode 都包含匿名用户 query、地理上下文、冻结的 API response snapshot 和结构化 ground truth；评测时 agent 不能访问 live endpoint，只能通过 deterministic API-replay sandbox 拿到预录制响应。这样可以让 measured performance 更接近“模型是否会理解、规划、调用工具和做最终决策”，而不是外部地图服务在评测时是否变了。

为什么值得研究

如果这个问题解决得好，route-planning agent 的研究就可以从单一成功率转向可诊断、可复现的工程指标：Instruction Understanding 定位“有没有读懂请求”，Planning 定位“有没有拆对步骤”，Tool Use 定位“有没有选对 API / 填对 schema”，Decision Making 定位“最终路线是否真的满足约束”，Efficiency 定位“token / latency 成本能否上线”。这对面向地图、出行、O2O、本地生活等 domain-specific agent 都很关键，因为这些系统的错误通常不是单点 LLM hallucination，而是长链路里某个中间决策、参数或工具返回被误用。

2. Idea（核心思想）

核心洞察

MobilityBench 的核心不是再造一个静态问答集，而是把真实 mobility request 变成“可重放的工具交互 episode”：真实 API 调用在构造阶段被执行并缓存，评测阶段则通过 sandbox replay 固定同一输入对应的同一观察值。这样既保留了地图任务的 grounded tool interaction，又消除了 live service 的非确定性。

关键创新

第一，论文从 Amap 真实匿名语音/文本查询构建 100,000 个 mobility episodes，并归纳出 11 个细粒度场景与 4 个高层 intent family。第二，它把 ground-truth SOP、工具调用轨迹和 API 响应冻结为 replayable reference，使 end-to-end agent evaluation 不依赖人工主观评分。第三，它提出 multi-dimensional protocol，将最终成功率拆解为 ID / IE / DEC / TS / SC / DR / FPR / IT / OT 等指标，能看到“路线失败”究竟是读错意图、漏掉步骤、选错工具、schema 不合规，还是最后选择不满足约束。

与已有方法的本质区别

相对 TravelPlanner 这类 itinerary-level benchmark，MobilityBench 更底层、更服务化：它要求 agent 在地图 API 工具链上完成 POI、geocoding、traffic、weather、driving/bus/bicycling/walking route 等调用，并用 replay sandbox 保证可复现。相对 ToolBench 这类泛化 API benchmark，MobilityBench 又更 domain-specific：场景、工具 schema、ground-truth SOP 和评分规则都围绕真实出行路线规划设计，因此能诊断 route-planning agent 的可部署能力，而不仅是泛化函数调用能力。

3. Method（方法）

3.1 Overall framework：episode + replay sandbox + 多维评测

Figure 1 解读：图中把 MobilityBench 分成三条主线：左侧是真实 Amap query 的收集、过滤和 intent taxonomy 构建；中间是 ground-truth construction，将 query slots、POI/geocoding、route/weather/traffic 等 API 证据组织成 episode；右侧是 evaluation pipeline，agent 只能通过 deterministic replay sandbox 调工具，最后用多维指标评估 instruction understanding、planning、tool use、decision making 和 efficiency。关键点是：agent 看到的是用户 query 与 context，不看到 ground truth；sandbox 返回的是构造阶段冻结的 API 响应，因此不同模型面对同一 episode 时外部环境一致。

每个 episode 定义为： $e = (x, z, S, y)$ 其中 $x$ 是匿名自然语言用户请求， $z$ 是城市、当前位置等 mobility context， $S$ 是 replay sandbox 中固定、可重放的 API response snapshot， $y$ 是用于自动评分的结构化 ground truth。论文明确采用 no-clarification setting：agent 不能追问用户，所以每个 episode 必须仅凭初始 query 可解。这一点让 benchmark 更严格，也更贴近驾车/步行等“用户无法频繁交互”的移动场景。

3.2 数据构建与任务 taxonomy

MobilityBench 从 Amap 过去六个月的大规模匿名 mobility query 构建。原始 voice query 会被转写成文本；随后在 no-clarification 约束下去除 malformed、underspecified、ambiguous 请求，并对近重复样本去重。论文用 Qwen-4B 做 open-set intent classification：先给出 information access 与 route planning 两个粗根节点；无法归入已有标签的 query 会触发新候选 intent；再经过多轮专家合并、裁剪和定义澄清，形成互斥且覆盖面较大的 taxonomy。

Figure 2 解读：该图展示 MobilityBench 数据的全球覆盖。论文正文强调 benchmark 覆盖 350+ 城市；官方 README 进一步说明 release 目标为 22 个国家、350+ 城市，并呈现长尾地理分布。这个分布说明 benchmark 不只是单城路线规划，而是覆盖多城市、多区域、多路况与不同 POI/路线服务状态；同时也意味着评测必须控制 live API 非确定性，否则城市和时间带来的外部变化会掩盖模型差异。

论文把 11 个核心场景组织成 4 个 high-level intent family：

Intent family	Scenarios	需要 agent 做什么
Basic Information Retrieval	POI Query, Geolocation Query, Nearby Query, Weather Query, Traffic Info Query	查询地点、当前位置、附近 POI、天气、路况等单步或浅层信息。
Route-Dependent Information Retrieval	Route Property Query, Arrival/Departure Time Query	先算路线，再回答距离、耗时、到达/出发时间等派生信息。
Basic Route Planning	Point-to-Point Planning, Multi-stop Planning	规划起终点或多途经点路线，输出可执行 itinerary。
Preference-Constrained Route Planning	Option-Constrained Route Planning, Route-Constrained / Customized Planning	在不走高速、少换乘、指定线路/站点/道路等偏好或硬约束下规划路线。

论文内部命名有一个需要注意的细节：正文示例中出现 Multi-Modal Route Planning，Appendix 表格中对应更强调 Customized Planning；released code 的 PlanningMetric.TASK_SCENARIO_TO_GOLDEN 与 AnswerMetric.TASK_SCENARIO_TO_EVAL_TYPE 使用的是 Route-Constrained Planning，没有单独暴露 Multi-Modal 类别。笔记后续按“11 scenarios / 4 families”的主设定理解，把这些差异视为论文命名与 release schema 的轻微不一致。

3.3 Ground-truth construction：SOP + 标准工具程序 + 执行轨迹

每个 scenario 都有 domain expert 定义的 SOP，描述最小必要工具调用链。一个标准 tool program 通常包含三步：

从 query 中抽取并标准化 slots，例如 POI、起终点、途经点、时间、出行方式、偏好策略；
用 POI retrieval / reverse geocoding 把文本地点映射到结构化 entity 或坐标；
参数校验后调用 routing、traffic、weather 等下游工具，并在有偏好或硬约束时验证 feasibility。

这个执行过程的完整 trace、关键中间结果和最终参考答案会被固化进 $y$ ，用于自动评分和错误诊断。它不是给 agent 的答案，而是 evaluator 的 reference：agent 只通过 sandbox 工具观察外部世界。

3.4 Deterministic API-replay sandbox

构造 ground truth 时，MobilityBench 使用 AMap Web Service API 的 9 类工具：poi_query、nearby_poi_query、reverse_geocoding、weather_query、traffic_info_query、driving_planning、bus_planning、bicycling_planning、walking_planning。评测时 agent 禁止访问 live API；所有调用都被路由到 replay sandbox。缓存 key 会 canonicalize 参数，例如坐标格式、时间格式和地点名；exact lookup 失败时，POI 可退化到 fuzzy name matching，坐标类工具可用 nearest-neighbor spatial matching，以保证语义上等价的调用仍能得到可比响应。

直觉上，这个 sandbox 让 benchmark 同时满足两个看似冲突的目标：它不是纯文本问答，因为 agent 仍需真正选择工具和填参数；它也不是 live service eval，因为工具观察值被冻结，模型间差异不会被当天路况、API 限流或 POI 更新污染。

3.5 Evaluation protocol：从黑盒成功率拆成可诊断指标

Instruction Understanding 包括 Intent Detection 与 Information Extraction。Intent Detection 比较预测 intent $\overset{y}{^}_{I D} (x)$ 与 ground truth $y_{I D} (x)$ 的相似度是否超过阈值 $τ_{t h res h o l d}$ ： $ID = \frac{1}{∣ X ∣} \sum_{x \in X} I (sim (\overset{y}{^}_{I D} (x), y_{I D} (x)) \geq τ_{t h res h o l d}) .$ Information Extraction 要求抽取出的显式/隐式约束集合完全匹配： $IE = \frac{1}{∣ X ∣} \sum_{x \in X} I (\overset{y}{^}_{I E} (x) = y_{I E} (x)) .$ Planning 关注任务拆解的覆盖与冗余。令 $V_{p re d} (x)$ 为 agent 预测的 atomic action sequence， $V_{g o l d} (x)$ 为 ground truth sequence， $f_{D EC}$ 判断两个 atomic action 是否匹配： $DEC - P = \frac{1}{∣ X ∣} \sum_{x \in X} \frac{∣ V _{g o l d} ( x ) \cap _{f_{D EC}} V _{p re d} ( x ) ∣}{∣ V _{g o l d} ( x ) ∣},$ $DEC - R = \frac{1}{∣ X ∣} \sum_{x \in X} \frac{∣ V _{p re d} ( x ) \cap _{f_{D EC}} V _{g o l d} ( x ) ∣}{∣ V _{p re d} ( x ) ∣} .$ 论文还定义 Task Dependency（DEP）来检查 atomic action 的依赖顺序，但 released PlanningMetric.compute() 当前只把 DEC_P 与 DEC_R 写入 details，_compute_dep() 存在但默认路径没有汇总输出。

Tool Use 包括 Tool Selection、Schema Compliance 和 Parameter Filling。Tool Selection 报告必要工具覆盖与冗余补集： $TS - P = \frac{1}{∣ X ∣} \sum_{x \in X} \frac{∣ T _{g o l d} ( x ) \cap T _{p re d} ( x ) ∣}{∣ T _{g o l d} ( x ) ∣},$ $TS - R = 1 - \frac{1}{∣ X ∣} \sum_{x \in X} \frac{∣ T _{p re d} ( x ) ∖ T _{g o l d} ( x ) ∣}{∣ T _{p re d} ( x ) ∣} .$ Schema Compliance 检查必填字段是否完整、类型和值域是否合法、是否包含 schema 外字段： $S_{SC} = S cor e_{co m p} \cdot (1 - R),$ 其中 $R = 1$ 表示存在非法额外字段。Released ToolCallMetric 还计算了 parameter_filling，但默认 MetricResult.details 只暴露 TS_P、TS_R、SC。

Decision Making 用 Delivery Rate 与 Final Pass Rate 表示：DR 衡量是否生成完整可执行输出；FPR 衡量最终方案是否满足所有显式/隐式约束。Efficiency 用输入 token（IT）和输出 token（OT）近似部署成本。

3.6 Released code 的实际执行路径

Code reference: main @ da07a8c5 (2026-03-04) — pseudocode and mapping based on this commit

def replay_tool_call(tool_name: str, args: dict, sandbox_store: dict) -> dict:
    """Released sandbox tools validate arguments, normalize keys, then read cached AMap results."""
    normalized = canonicalize(args)  # e.g., coordinates, city, strategy, waypoints
    validate_against_tool_schema(tool_name, normalized)
    result = lookup_cached_response(sandbox_store, tool_name, normalized)
    if result is None:
        return {"status": "failed", "error": "no cached replay result"}
    return {"status": "success", "data": result}

async def react_episode(query, context, tools, llm, max_iterations=10):
    messages = [system_prompt("react"), f"Context: {context}", f"User query: {query}"]
    for step in range(max_iterations):
        response = await llm.ainvoke(messages)
        parsed = parse_json_or_finish(response.content)
        if parsed["action"] == "finish":
            return parsed["final_answer"], messages
        tool = tools[parsed["tool_name"]]
        observation = tool.invoke(parsed["tool_args"])
        messages += [response, ToolMessage(observation)]
    return force_finish_from_history(messages), messages

async def plan_and_execute_episode(query, context, planner_llm, worker_llm, reporter_llm, tools):
    state = {"query": query, "context": context, "messages": []}
    plan = await planner_llm.with_structured_tool("RawPlan").ainvoke(state)
    for step in plan.steps[:10]:
        pending_tasks = [task for task in step.tasks if task.status == "PENDING"]
        worker_results = await parallel_map(
            lambda task: run_worker(task, worker_llm, tools, state), pending_tasks
        )
        if all(result.failed for result in worker_results):
            break
        state["messages"].extend(result.messages for result in worker_results)
    final_report = await reporter_llm.ainvoke(state)
    return final_report.content, state

def evaluate_case(prediction: dict, ground_truth: dict, configs: dict) -> dict:
    instruction = InstructionMetric(configs["instruction"]).compute(prediction, ground_truth)
    planning = PlanningMetric(configs["planning"]).compute(prediction, ground_truth)
    tool = ToolCallMetric(configs["tool"]).compute(prediction, ground_truth)
    answer = AnswerMetric(configs["answer"]).compute(prediction, ground_truth)
    efficiency = EfficiencyMetric().compute(prediction, ground_truth)
    return {
        "ID": instruction.details["intent_detection"],
        "IE": instruction.details["information_extraction"],
        "DEC_P": planning.details["DEC_P"],
        "DEC_R": planning.details["DEC_R"],
        "TS_P": tool.details["TS_P"],
        "TS_R": tool.details["TS_R"],
        "SC": tool.details["SC"],
        "DR": answer.details["delivery_success"],
        "FPR": answer.details["accuracy"],
        "IT": efficiency.details["input_tokens"],
        "OT": efficiency.details["output_tokens"],
    }

Paper Concept	Source File	Key Class/Function
ReAct think-act-observe loop	`src/mobility_bench/agent/frameworks/react/nodes.py`	`reasoning_node`, `action_node`, `_parse_react_response`
Plan-and-Execute planner/worker/reporter	`src/mobility_bench/agent/frameworks/plan_and_execute/nodes.py`	`planner_node`, `worker_node`, `reporter_node`
Agent loop limits and sandbox path	`configs/agent/default.yaml`	`plan_and_execute.max_plan_iterations=10`, `react.max_iterations=10`, `sandbox_data_dir=data/sandbox`
LLM sampling config	`configs/models/default.yaml`	`temperature=0.1`, `max_tokens=8192` for configured roles where present
Dataset schema	`configs/datasets/mobility_6262.yaml`, `data/datasets/sample_10.csv`	`query`, `context`, `task_scenario`, `intent_family`, `tool_list`, `route_ans`
Evaluation registry and batch runner	`src/mobility_bench/evaluation/runner.py`	`EvaluationRunner.evaluate_metric`, `run_all`, `aggregate_results`
Instruction metrics	`src/mobility_bench/evaluation/metrics/instruction.py`	`InstructionMetric.compute`, similarity threshold 0.7
Planning metrics	`src/mobility_bench/evaluation/metrics/planning.py`	`PlanningMetric.compute`, `TASK_SCENARIO_TO_GOLDEN`, `_compute_dec`
Tool metrics	`src/mobility_bench/evaluation/metrics/tool_call.py`	`ToolCallMetric.compute`, `_evaluate_tool_calls`
Outcome metrics	`src/mobility_bench/evaluation/metrics/answer.py`	`AnswerMetric.compute`, `_evaluate_route`, `_evaluate_route_custom`
Replay sandbox tools	`src/mobility_bench/tools/sandbox/*.py`	`query_poi`, `driving_route`, `bus_route`, `weather_query`, etc.

论文公式与 released code 实现差异：paper 报告的 evaluation set 是 7,098 episodes，但当前 public repo 的 configs/datasets/mobility_6262.yaml 指向 data/datasets/combine_6262.xlsx，checkout 中未包含该文件，只有 data/datasets/sample_10.csv（实际 115 行）作为样例；README 也说明 full dataset will be released progressively。另一个差异是 paper 描述了 DEP / PF 等细粒度项，而 released default metrics 中 DEP 未进入 PlanningMetric.compute() 输出，PF 被 _evaluate_tool_calls() 计算但默认 details 不直接报告。因而这份笔记把论文表格数值视为 paper-reported benchmark 结果，把代码分析视为当前 release 的可复现工具链与评测骨架。

4. Experimental Setup（实验设置）

Dataset 与规模

论文构建了 100,000 个来自真实 mobility scenarios 的 episode，覆盖 11 个核心分析场景。为了兼顾统计显著性与推理成本，正式实验采用按 task scenario 与 city 分层的随机采样，最终 evaluation set 为 7,098 episodes。官方 README 还给出数据覆盖目标：22 个国家、350+ 城市；scenario distribution 为 Basic Information Retrieval 36.6%、Route-Dependent Information Retrieval 9.6%、Basic Route Planning 42.5%、Preference-Constrained Route Planning 11.3%。

Baselines / backbones

Agent framework 主要比较两类：ReAct 与 Plan-and-Execute。论文没有把 LLM Compiler、LATS、Tree-of-Thought 纳入主实验，理由是这些方法计算成本更高、与 route-planning 的 latency / tool-interaction 约束适配性较弱。

LLM backbones 覆盖 open-source 与 closed-source：Qwen3-4B、Qwen3-30B-A3B、Qwen3-32B、Qwen3-235B-A22B、DeepSeek-R1、DeepSeek-V3.2-Exp，以及 GPT-4.1、GPT-5.2、Claude-Opus-4.5、Claude-Sonnet-4.5、Gemini-3-Pro-Preview、Gemini-3-Flash-Preview。

Metrics

主表报告 11 个指标：ID、IE、DEC-P、DEC-R、TS-P、TS-R、SC、DR、FPR、IT、OT。ID/IE 衡量自然语言理解，DEC-P/DEC-R 衡量计划拆解，TS-P/TS-R/SC 衡量工具选择与 schema 合规，DR/FPR 衡量最终是否交付与是否满足约束，IT/OT 衡量 token 成本。

Evaluation config / hyperparameters

论文与代码共同给出的统一设置是：sampling temperature 为 $0.1$ ，maximum output length 为 $8, 192$ tokens，agent maximum inference steps 为 $10$ 。Released config 对应 configs/models/default.yaml（模型角色、temperature、max_tokens）、configs/agent/default.yaml（Plan-and-Execute max_plan_iterations=10、max_worker_retries=3，ReAct max_iterations=10）和 configs/evaluation/default.yaml（tool schema 最小/最大字段、instruction similarity threshold 0.7、answer similarity threshold 0.8、distance tolerance 0.05、planning alpha 0.8 / beta 0.2）。论文未详细说明硬件/GPU配置；由于主实验是多家 closed/open LLM API 或服务推理，硬件不是统一训练设置。

5. Experimental Results（实验结果）

Overall performance：ReAct 更强但更贵，Plan-and-Execute 更省 token

主表中，Plan-and-Execute 下 Claude-Opus-4.5 的表现最好，DR 为 83.53%、FPR 为 65.77%；Claude-Sonnet-4.5 为 DR 81.96%、FPR 64.31%；Qwen3-235B-A22B 为 DR 81.22%、FPR 64.16%。ReAct 下，Gemini-3-Pro-Preview 达到最高 FPR 69.09%、DR 84.38%；DeepSeek-V3.2-Exp 达到 FPR 68.88%、DR 84.95%；Gemini-3-Flash-Preview 达到 FPR 67.90%、DR 85.18%；Qwen3-235B-A22B 也达到 DR 85.95%、FPR 66.69%。

Framework	Model	ID	IE	DEC-P	DEC-R	TS-P	TS-R	SC	DR	FPR	IT	OT
ReAct	Gemini-3-Pro-Preview	83.54	88.75	68.70	65.11	90.74	75.04	98.70	84.38	69.09	20164.76	1242.48
ReAct	DeepSeek-V3.2-Exp	78.18	90.78	71.85	77.19	87.99	82.19	98.23	84.95	68.88	15427.89	622.05
ReAct	Qwen3-235B-A22B	82.13	90.51	72.23	77.75	84.13	84.66	97.24	85.95	66.69	15391.23	604.73
Plan-and-Execute	Claude-Opus-4.5	76.82	95.81	88.80	70.99	84.76	76.53	97.22	83.53	65.77	12643.41	808.83
Plan-and-Execute	Claude-Sonnet-4.5	97.21	95.69	89.46	71.81	84.63	78.17	96.89	81.96	64.31	13267.99	863.81
Plan-and-Execute	Qwen3-235B-A22B	97.24	94.36	89.39	66.96	84.59	73.49	97.01	81.22	64.16	12563.66	703.60

论文的核心结论是：ReAct 的 closed-loop think-act-observe 在动态工具反馈下更稳，整体 FPR 通常高于 Plan-and-Execute；但 ReAct 会持续累积 observation history，平均 IT 比 Plan-and-Execute 高约 35.38%，直接推高 API 成本和 wall-clock latency。Plan-and-Execute 的预先计划更省上下文、计划指标更高，但面对工具反馈变化时鲁棒性不足。

Scenario study：Preference-Constrained Route Planning 是最难场景

Figure 3 解读：四个 radar 分别对应从 Basic Information Retrieval 到 Preference-Constrained Route Planning 的任务族，越往右约束越复杂、逻辑链越长。Basic information retrieval 和普通 route planning 上多数强模型已能维持较好的工具使用与最终交付；Preference-constrained planning 则明显更难，因为 agent 不仅要找到路线，还要把“不走高速”“少换乘”“指定线路/道路”等约束转成正确 API 参数或后验验证条件。图中也体现了 framework trade-off：Plan-and-Execute 在结构化拆解上更稳定，ReAct 在依赖工具反馈修正的场景中更有优势。

Model study：scale 与 thinking 都有收益，但成本显著增加

Figure 4 解读：该图比较 Thinking 与 Non-thinking 设置下的 FPR。论文在 1,000 个代表性样本上控制比较 Qwen-4B、Qwen-32B、Qwen-30B-A3B、Qwen-235B-A22B，并加入 DeepSeek-R1 作为强 reasoning baseline。DeepSeek-R1 的 FPR 为 70.46%；开启 thinking 对各模型都有帮助，最大绝对提升出现在 Qwen-30B-A3B，FPR 增加 5.98%。但 thinking 会显著增加 generated tokens、成本和 latency，因此对实时在线路线规划 agent 并不总是可部署。

规模效应也成立：在 dense Qwen 系列中，从 4B 扩到 32B 平均成功率提升 0.91%；在 MoE 设置下，从 Qwen3-30B-A3B 扩到 Qwen3-235B-A22B 额外提升 5.43%。论文还观察到，大模型往往生成更长的 solution trajectory，DEC-P/DEC-R 显示它们会探索更多步骤；这可能带来冗余，但也提高了最终可行解的覆盖率。

Open-source 模型的实用性

虽然 Claude、Gemini 等 closed-source 模型在若干维度仍领先，open-source MoE 已非常接近：ReAct 下 Qwen3-235B-A22B 达到 DR 85.95%、FPR 66.69%，DeepSeek-V3.2-Exp 达到 FPR 68.88% 且输出 token 更低（OT 622.05）。这对企业私有化部署很重要：route-planning 任务常涉及位置、偏好和出行上下文，私有化模型/服务可能比完全依赖外部 closed API 更容易满足合规和成本要求。

Limitations 与结论

论文的主要限制有四点。第一，deterministic replay sandbox 保证可复现，但也冻结了真实世界动态，不能完全代表线上实时交通/天气变化下的鲁棒性。第二，no-clarification setting 提高了评测严格性，但实际产品可能通过多轮澄清解决 underspecified query。第三，public release 在 main@da07a8c5 仍是 progressive release：完整数据未随 repo checkout 一起发布，release config 与 paper 7,098-episode 设置存在差异。第四，实验没有覆盖 LATS、Tree-of-Thought 等更重的搜索式 agent，因此结论主要适用于 ReAct 与 Plan-and-Execute 这两类主流、相对可部署框架。

总体上，MobilityBench 证明了 route-planning agent 评测需要“真实数据 + 冻结工具环境 + 多维诊断”三者同时存在。只看最终回答会掩盖错误来源；只看 tool-call correctness 又无法判断路线是否满足用户约束。它为 domain-specific mobility agent 提供了一个更接近生产系统的评测基准，也暴露出当前模型在 preference-constrained planning、成本控制和实时部署上的改进空间。

Paper Notes

探索

MobilityBench: A Benchmark for Evaluating Route-Planning Agents in Real-World Mobility Scenarios

MobilityBench: A Benchmark for Evaluating Route-Planning Agents in Real-World Mobility Scenarios

1. Motivation（研究动机）

现有 agent benchmark 没有真正覆盖“日常出行路线规划”

论文要解决的具体问题

为什么值得研究

2. Idea（核心思想）

核心洞察

关键创新

与已有方法的本质区别

3. Method（方法）

3.1 Overall framework：episode + replay sandbox + 多维评测

3.2 数据构建与任务 taxonomy

3.3 Ground-truth construction：SOP + 标准工具程序 + 执行轨迹

3.4 Deterministic API-replay sandbox

3.5 Evaluation protocol：从黑盒成功率拆成可诊断指标

3.6 Released code 的实际执行路径

4. Experimental Setup（实验设置）

Dataset 与规模

Baselines / backbones

Metrics

Evaluation config / hyperparameters

5. Experimental Results（实验结果）

Overall performance：ReAct 更强但更贵，Plan-and-Execute 更省 token

Scenario study：Preference-Constrained Route Planning 是最难场景

Model study：scale 与 thinking 都有收益，但成本显著增加

Open-source 模型的实用性

Limitations 与结论

目录