PlannerForge：面向自动驾驶运动规划器场景化测试的 LLM 智能体框架 PlannerForge: LLM Agents for Scenario-Based Testing of Motion Planners in Autonomous Driving
首个用 LLM 智能体贯通自动驾驶规划器场景测试全流程的统一对话式框架
前置知识
场景化测试（Scenario-based Testing）
行业验证自动驾驶系统（ADS）的系统化方法：在仿真中构造结构化交通场景（路网、参与者、ego 目标），批量运行被测系统并统计成功率、碰撞率等指标。Pegasus 项目确立的六组件分类学——场景源、场景生成、场景数据库、场景选择、测试执行、ADS 评估——是事实上的标准框架。
本文的贡献就是把这六组件全部搬进一个 LLM 智能体框架并新增两个阶段。不理解这条流水线，就无法理解「全生命周期统一」的含义，也无法理解论文各模块实验的划分方式。
CommonRoad 与 SUMO
CommonRoad 是开源运动规划基准格式，用 XML 描述路网、带预录轨迹的动态障碍物和 ego 规划问题；SUMO 是微观交通仿真器，按跟驰/换道模型生成真实车流轨迹。两者经 CommonRoad↔SUMO 转换桥互通，场景可在 CommonRoad XML 与 SUMO 的 .net.xml/.rou.xml 之间往返。
论文所有场景的表示、修改与执行都建立在这两个工具及转换桥上；修改模块的物理有效性和生成模块的可行性都源于「让 SUMO 而非 LLM 负责车辆动力学」这一设计。
LLM 提示工程（CP/ICL/CoT）
不微调模型、只用提示词控制输出：CP（Contextual Prompting）把输出 JSON/XML/YAML schema 与约束注入提示；ICL（In-Context Learning）加入正例与反例（如拒绝示例）示范；CoT（Chain-of-Thought）要求模型先显式推理再作答。论文按 baseline/cp/cp_cot/cp_icl/cp_icl_cot 五档做消融。
整个框架零微调，全部能力来自这五档提示；论文最重要的实证结论（如外部 CoT 与模型原生 thinking 冲突、ICL 对拒绝类子任务不可替代）都来自这套消融设计。
LLM 函数调用与意图路由
让 LLM 按预定义 schema 输出结构化 JSON（动作名+参数），由确定性代码分发到对应工具执行。本文的 Module Router 据此把用户话语分类到 MODIFY/TUNE/TEST/ANALYSE/QA 五个动作，形式化为 $\hat{a}_t = \arg\max_{a \in \mathcal{A}} f_{router}(a \mid u_t, h_t)$，两阶段完成：LLM 吐 JSON，过程引擎调用下游模块。
Router 是 PlannerForge 区别于以往线性测试工具的关键架构机制，也是五个评测任务之一（最佳 0.997，而手工正则只有 45.5%）。
运动规划器与代价函数
运动规划器在 Frenet 坐标等表示下采样或优化候选轨迹，用加权代价函数（加速度、加加速度、到参考线/障碍物距离等十余个权重）选出最优轨迹。Frenetix 是高性能采样式规划器，MP-RBFN 用径向基函数网络学习轨迹基元；二者都被本文的统一接口 $\pi_P$ 封装。
ADS Enhancement 任务的全部内容就是把「Safety-Conservative」这类自然语言翻译成这些代价权重的 YAML 覆盖（$\theta \to \theta'$）；理解代价权重才能理解调参实验和五档驾驶预设。
向量检索与混合过滤
把文本用 SentenceTransformer 等模型编码为向量存入 ChromaDB 等向量库，以余弦相似度做语义检索；可与结构化元数据硬过滤组合，并用 RRF（倒数排名融合）合并多路结果。论文对比了纯硬过滤漏斗、纯语义、混合预过滤、RRF 四条检索流水线。
选择模块靠「五槽位硬过滤为主、语义检索兜底」的策略拿到 92.0% 的 rank-1 命中率；四流水线对比证明语义检索召回好但精度崩塌（sat_all 接近 0%），硬过滤对精度不可或缺。
研究动机
现实中的自动驾驶规划器验证依赖场景化测试，但这条流水线高度碎片化、大量环节仍靠手工。以典型实践为例：场景生成要靠 GUI 编辑器或规则脚本，如规则式的 Scenario Factory 2.0 虽然每场景只需 2.2 秒，却完全无法指定城市、道路等级、车型构成等属性，且只覆盖 4 类交通参与者；场景检索靠 CommonRoad GUI 的手工参数过滤或 BM25 关键词匹配，后者在 200 条自然语言查询上的 rank-1 命中率仅 67.5%，无法处理转述、地名歧义和隐式区间约束；场景修改基本无人支持——最强的 LLM 修改工具 From-Words-to-Collisions 只支持一种编辑类型，且直接写轨迹坐标导致约 70% 的编辑违反车辆动力学（物理有效率仅 31%）；测试执行要为每个规划器单独写批量脚本；结果分析靠离线聚合；规划器代价权重全靠手工调。由于真实道路测试稀有边缘场景的代价高得无法承受（Winner 等 2019），行业被迫依赖仿真测试，但工具割裂意味着每换一个环节就要换一套工具和输入格式，研究者的时间耗在管道胶水工作上而非测试设计本身。
本文的目标是本文要构建第一个覆盖场景化测试全生命周期的统一 LLM 智能体框架 PlannerForge。具体目标有四：其一，把 Pegasus 六组件分类学（场景源、生成、数据库、选择、测试执行、ADS 评估）的全部阶段搬进一个聊天机器人驱动的界面，用户全程用自然语言操作；其二，新增两个 LLM 时代阶段——ADS Enhancement（用自然语言重调规划器代价权重）和 ADS Benchmarking（同一批场景上跨规划器比较）；其三，全程使用现成（off-the-shelf）LLM、不做任何领域微调，并系统回答「哪些开源或商用模型、哪种提示技术能胜任哪些环节」；其四，把整条流水线形式化为语言到结构化输出的决策序列，让每个模块输出都经过 schema 校验和下游可执行性验证，使整条链路可量化、可复现、可基准化。
与已有工作不同的是，已有 LLM 工作全部集中在单点：场景生成方向有 ChatScene、Chat2Scenic、Text2Scenario、NL2Scenic（面向 CARLA）、LCTGen（真实地图+语言条件）、ChatSUMO（SUMO+OSM）等；ADS 增强方向有 Language-Agent、MPC×LLM、DualAD、LeAD 等；两篇 2025/2026 年综述均确认绝大多数工作只做生成。没有人把生成、检索、修改、执行、分析、调参、跨规划器对比串成一个闭环系统。本文的独特切入有三点：第一，把流水线形式化为 $f_{gen}: \mathcal{U} \to \mathcal{S}$、$f_{sel}: \mathcal{U} \times \mathcal{D} \to \mathcal{D}$、$f_{mod}$、$f_{tune}$、$f_{test}$、$f_{eval}$ 的组合，并指出核心语言学挑战是「产出符合 schema 的 CommonRoad XML / SUMO 文件 / Frenetix YAML」；第二，用 Module Router 意图分类器打破固定的线性流程；第三，评估方法论本身即贡献——10 个模型 × 5 种提示条件 × 每格 200 查询、共 80,000 次调用的系统消融，从中提炼出可迁移到其它结构化输出任务的提示工程规律。
核心方法
直觉上，这是把测试工程师在 CommonRoad/SUMO 里的全部操作——拉地图、造车流、挑场景、改场景、跑规划器、调权重、解读结果——变成一段自然语言对话。技术路线：Gradio 聊天前端加 LangChain 后端，配三级状态管理（LangChain 在历史超 125k token 时自动摘要、Gradio 保留完整聊天记录、内存会话状态暂存中间产物）。六个模块：(1) Generation 两阶段把「慕尼黑中等密度车流的路口」转成 JSON 意图，经 Overpass API 拉取 OSM 真实路网、SUMO 微观仿真填充车流、转成 CommonRoad 场景并合成规划问题；(2) Selection 把 500+ 精选场景连同四层元数据（位置、路边设施、参与者、ego）索引进 Chroma 向量库，五步槽位对话逐级过滤；(3) Module Router 在场景就绪后把话语分类到 MODIFY/TUNE/TEST/ANALYSE/QA 并分发；(4) Modification 借 CommonRoad↔SUMO 桥做四类编辑；(5) Testing 用统一接口封装 Frenetix（采样式）与 MP-RBFN（学习式），$f_{test}(s,\theta) = \pi_P(s,\theta) = (\tau, c, m)$ 返回轨迹、碰撞标志和代价日志；(6) Analysis 把批量结果连四个上下文块喂给 LLM，输出指标、失败模式分解和调参建议，与调参器闭环。
核心创新是「语言层与动力学层彻底解耦」的幻觉隔离设计，加上打破线性流程的意图路由。LLM 永远不直接生成地图几何、路网拓扑或车辆轨迹——这三类信息分别只由 OSM 抓取、SUMO 仿真和 CommonRoad 转换器产生，从结构上排除了三类会静默传播到下游的幻觉；LLM 只在两个「类型化边界」上工作：把自然语言解析成 JSON 意图，或在 SUMO 路线文件里做 schema 约束的定点编辑。这与 From-Words-to-Collisions 让模型直接写轨迹坐标的做法本质不同——后者 31% 的物理有效率正是让 LLM 越界的代价。第二点是 Module Router：传统框架固定走「生成→选择→修改→测试→分析」，PlannerForge 在场景就绪后由 LLM 做意图分类（动作集 $\mathcal{A}$ = {MODIFY, TUNE, TEST, ANALYSE, QA}），两阶段函数调用先吐 JSON 再由过程引擎分发，用户可自由跳转。第三点是零微调哲学：所有能力全部来自五档提示工程（CP 注入 schema、ICL 加正反例、CoT 结构化推理），外加一个「每次 LLM 调用都要过解析、schema 校验和下游执行」的可执行 harness——论文的口号是提示词提高命中率，harness 让模块变得可靠。
方法步骤详情
生成模块两阶段：阶段一，LLM 用 $P_{GEN}$ 把自由文本解析成固定键 JSON 意图（位置、道路等级、密度、各类车辆数、时长，每键带默认值，如时长默认 20 秒）；边界框驱动 Overpass API（四镜像端点容错）取 .osm 数据，Nominatim 负责地名转边界框；路网在 SUMO 中仿真，车流按跟驰/换道模型生成轨迹，经 CommonRoad2SUMO 转成 CommonRoad 格式。阶段二，选 ego（首辆车/按类型/按索引）并指定目标区域（lanelet 或沿轨迹前向偏移），附初始位姿与目标即得规划问题。选择模块按位置→标签→路网→障碍物→速度五步对话，每步用 $P_{SEL}^{(k)}$ 抽一个槽位并执行 $D^{(k)} = D^{(k-1)} \cap \mathrm{match}(\hat{\ell}_k)$ 单调剪枝，返回 top-5，空集则回退 SentenceTransformer 语义检索。修改模块把场景转成 .net.xml 加 .rou.xml，LLM 用 $P_{MOD}^{\tau}$（$\tau \in \{T,B,P,G\}$）发出修改后的 SUMO 文件再回转 CommonRoad 得动力学可行轨迹：T 改边序列重定向、B 把 换成六种跟驰预设、P 按拓扑摘要增删车辆、G 直接改规划目标免往返。测试以单场景或批模式跑规划器，结果 $o_i = (\tau_i, c_i, m_i)$。增强模块把「Sporty 模式」等话术翻成 schema 合法的 YAML 覆盖 $\theta \to \theta'$。分析模块聚合批级统计、逐场景日志、当前配置与 CSV 路径四块生成诊断，并保留历史批次以推理权重变化与结果变化的因果关系。
技术新颖性
新颖性有四层。第一，系统完整性：这是首个把 Pegasus 六组件全部实现并新增 Enhancement/Benchmarking 的 LLM 框架；此前工作（ChatScene、Chat2Scenic、Text2Scenario 等）最多覆盖生成一环且大多绑定 CARLA，PlannerForge 绑定 CommonRoad/SUMO，使生成的场景可直接喂给真实研究级规划器。第二，架构模式：意图路由 + 幻觉隔离 + schema 校验 harness 构成一套可复用的 agent 设计模板，明确回答了「LLM 该做什么、确定性工具该做什么」的边界问题。第三，评估设计：80,000 次调用、50 个（模型×条件）格 × 8 个任务切片、漏斗式布尔检查（语义正确性→SUMO 可仿真→CommonRoad 回转→可规划）把「LLM 做对了吗」与「部署得了吗」解耦，这种评分协议本身可迁移到任何结构化输出任务。第四，实证发现：外部 CoT 与原生 thinking 冲突（推理模型加 CoT 反而大幅掉分）、ICL 对拒绝类子任务不可替代（出词表参数 refusal 从 0% 到 100% 只有用 ICL 才达成）、开放 20–35B 模型足以驱动整条流水线——这些规律并非自动驾驶特有。此外每个模块都以最强经典基线（SF 2.0、BM25、FWtC、手工正则、手调 Default 配置）做对照，而非只报自家分数。
实验结果
逐实验说明。(1) 五任务模块评测（每格 N=200，共 80,000 次调用）：最佳分从选择 0.880 到规划器测试 1.000；生成任务 Glm-5 用 cp_cot 得 0.957（基线 0.783，+0.174）；选择任务 Qwen3.6-plus cp_cot 的 sat_all 0.880（基线仅 0.180）；修改任务在 cp_icl_cot 下 Qwen3.6-plus 四子任务 headline 检查约 100%，行为预设（B）零样本 0%、提示补全后 100%，而结构编辑 T/P/G 零样本已有 99.0/99.0/88.5%；路由任务 Gemma4:31b cp_icl_cot 达 0.997（手工正则 45.5%）；调参任务 Gpt-5.4-mini cp_icl 满分 1.000（基线 0.675），155/191（81.2%）的 YAML 在 Frenetix 端到端可运行。(2) 端到端漏斗（200 条种子查询）：生成后 96%，选择后 91%/85%，修改后 83%/78%（商用/开源），均摊每场景约 126 s、42.5k token（商用）与 99 s、32.6k token（开源），T、P 编辑在仿真往返各漏 13–17% 和 12–16%。(3) 对比 SF 2.0：193 vs 144 可执行、属性命中 92–96%（对手不可指定）、7 vs 4 类参与者、诱导碰撞 20.0% vs 6.1%（3.3 倍），代价 21.6 s vs 2.2 s。(4) 对比 BM25：rank-1 92.0% vs 67.5%，Any@5 96.5% vs 86.0%。(5) 对比 FWtC：四类编辑物理有效 ≥94% vs 31%，Participant 编辑把 min_risk 从 1.84 压到 1.20、新增 58 次碰撞（对手 1.69、16 次）。(6) 调参：N=400 时成功率 50.4%→70.2%、碰撞 19.0%→8.4%，15 轮独立调用全部返回同一配置，方差随 N 从 ±6.8pp 收窄到 ±0.3pp。(7) 开源 Qwen3.6:35b 在五任务中三个追平商用 API。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 场景生成（对比 Scenario Factory 2.0） | 200 条查询的可执行场景数与属性命中率 | 193/200 可执行；城市 96.0%、道路 92.0%、车辆 95.6%；7 类交通参与者 | Scenario Factory 2.0：144/200；三类属性均不可指定；4 类参与者 | +49 个可执行场景；属性可控从 0 到 92–96%；代价是 21.6 s vs 2.2 s |
| 场景生成的安全关键性（越难越好） | 诱导 Frenetix 碰撞率 | 20.0% | Scenario Factory 2.0：6.1% | 严苛程度 ×3.3，更适合压力测试 |
| 场景选择（对比 BM25 关键词检索） | Satisfy@1 / Any@5（500+ 场景库，200 条查询） | 92.0% / 96.5% | BM25：67.5% / 86.0% | rank-1 +24.5pp（交互工具的关键指标） |
| 场景修改（对比 From-Words-to-Collisions） | 物理有效率 / min_risk 风险降幅 / 新增碰撞数 | 四类编辑均 ≥94% 有效；风险 1.84→1.20（Participant）；新增 58 次碰撞 | FWtC：31% 有效；1.84→1.69；新增 16 次碰撞 | 物理有效率 +63pp 以上，压险幅度 1.84→1.20 vs 1.69 |
| 规划器代价调参（N=400，对比手调 Default） | 规划成功率 / 碰撞率 | 70.2% / 8.4% | 手工 Default 配置：50.4% / 19.0% | +19.8pp / −10.6pp |
| 模块路由 | 严格意图匹配 Overall（200 条 9 类查询） | 0.997（Gemma4:31b, cp_icl_cot） | 手工正则路由 45.5% | +54.2pp |
| 端到端全链路（生成→选择→修改→测试→增强） | 200 条种子查询存活率 | 83%（商用 qwen3.6-plus）/ 78%（开源 qwen3.6:35b） | 无先例（首个全链路 LLM 测试系统） | 从 96% 起步，主要损失在选择（−6/−11pp）与修改（−9/−8pp）两段 |
局限与改进
作者承认的：端到端链路中轨迹（T）与车辆增删（P）编辑在仿真往返上分别损失 13–17% 与 12–16% 的存活查询，是最大漏点，属于基础设施限制而非语义错误；选择模块是另一泄漏点，标签槽位过度预测导致最佳 sat_all 只有 0.880——模型会发明数据库里不存在的 traffic_jam 标签（139 次），而召回高达 99.7%，纯粹是精度问题；分析模块（Analysis）没有真值评分；定量规划器结果只来自 Frenetix，MP-RBFN 仅定性对比；语料严重偏德国（每任务 200 条查询中 80–92 条是 DEU，15 国合计）；部分开源模型的结果格在提交时仍在收集。我的补充观察：第一，开环假设限制了失效模式的真实性——背景车辆不反应 ego，无法触发真实的交互性失效，20.0% 的碰撞率部分来自非反应背景这一人为放大；第二，安全关键性验证的统计并不显著（23/84 个配对场景变严峻 vs 18 个变缓和，Wilcoxon 检验 p=0.44）；第三，Enhancement 的有效性依赖「同场景同配置结果确定」这一前提，对随机化或端到端学习型规划器的适用性未知；第四，修改语料集中在 1–2 跳短改道（86.5%），长程重规划能力未被检验；第五，每场景 21.6 s、4.5k token 的生成成本对数万场景量级的大规模测试仍偏贵。
独立分析的弱点
独立分析四点弱点及改进方向。(1) 开环仿真：SUMO 导出的固定轨迹让背景车流对 ego 完全不反应，测出的碰撞不代表闭环交互风险，也更像「ego 撞上静止剧本」而非「被别车后失效」；改进方向是把 Analysis 的失败案例回流给 Generation，用 LLM 参数化背景车流的反应性，或接入 CARLA 做真正闭环。(2) 标签槽位瓶颈：tags 抽取在所有提示条件下都卡在 0.64–0.67，根源是开放生成不受受控词表约束；改进方向是用受限解码（constrained decoding）或枚举校验加重试，把 tags 从开放生成变成闭集分类，这有望把 sat_all 从 0.880 推向 0.95+。(3) 分析模块无监督：它是唯一没有真值评测的模块，而它恰恰负责「为什么失败」的诊断，幻觉诊断会误导下游调参；改进方向是构造带注入式故障的小型基准（人为制造碰撞/超时/运动学不可行），核对 LLM 归因准确率。(4) 单规划器单地域：定量结论全来自 Frenetix 与德语区路网，跨规划器泛化只有定性五预设对照；改进方向是纳入优化式、混合式等不同家族规划器并扩展多国路网复验，把 MP-RBFN 的定量比较补全。另可指出：调参实验中「15 轮全部返回同一配置」固然显示稳定，但也暗示 LLM 只是在五档预设附近的粗粒度搜索，尚未利用代价空间的连续性。
未来方向
作者明确提出的方向：闭合规划器回路（让被测规划器真正闭环反馈而非回放轨迹），这是把 20.0% 碰撞率变成可信安全结论的前提；把框架扩展到 CARLA 等其它仿真器；补全 Frenetix vs MP-RBFN 的定量头对头比较（目前仅有五档驾驶预设的定性对照，Fig. 13）。基于本文成果可以自然延伸的：把「分析→调参」升级为自动对抗性场景搜索——Analysis 已能输出失败模式分解和参数建议，让 Generation 据此迭代生成更难场景可形成自动红队循环，本文 B 任务把风险桶从 10 翻倍到 20 的结果证明这条路的可行性；把 schema 校验+可执行验证的 harness 模式推广为通用结构化输出 agent 评测协议；用受限解码修复 tags 瓶颈；利用选择模块 92% 的 rank-1 精度构建自动场景课程（curriculum）；在调参模块引入安全/舒适/效率的多目标帕累托搜索而非单点 YAML 覆盖；以及把防重入的确定性工具链与 LLM 松耦合的架构迁移到其它安全关键领域的仿真测试（机器人、低空飞行器）。
复现评估
复现条件相当好。代码、数据与全部提示词承诺开源（github.com/TUM-AVS/PlannerForge，附录 A.8 列出各模块提示文件）；商用模型给出精确 model-id（qwen3.6-plus、deepseek-v3.2、glm-5、gemini-3-flash-preview、gpt-5.4-mini），开源模型固定到 Ollama 镜像 tag（如 qwen3.6:35b@07d3521、gemma4:31b@6316f06、gpt-oss:20b@17052f9）；四个评测语料各 200 条自然语言查询、GT 结构化答案键（gt_valid_ids 缓存）随论文发布，结果表格粒度到每个（模型×提示）格，可逐项核对。算力门槛低：开源后端用 Q4_K_M 量化，单张 RTX 5090（32GB）即可跑 27GB 档的 Qwen3.6:35b/Gemma4:31b 与 14GB 的 Gpt-oss:20b，SUMO/Frenetix 在 CPU 上运行；论文还专门验证了「全开源、零 API」的可行配置。难点在工具链拼接：CommonRoad、SUMO、CommonRoad↔SUMO 桥、Frenetix、MP-RBFN、ChromaDB、Overpass API（有速率限制，需四个镜像端点容错）多组件依赖，环境搭建和 80,000 次评测的时间成本是主要摩擦；数据中 5/245 场景因 MOTORCYCLE 映射缺失无法往返，提示复现者会遇到类似的边角问题。总体评估：中等偏低难度。
论文图表
总览图：从场景生成到 ADS 评估的整条场景化测试流水线被 LLM 智能体自动化，用户通过对话驱动各环节。
一图看懂论文定位——不是又一个场景生成工具，而是覆盖全生命周期的统一框架，是论文最核心的主张。
SF 2.0 用时 2.2 s、144/200 可执行、属性不可指定、4 类参与者、6.1% 碰撞；PlannerForge 用时 21.6 s、193/200 可执行、城市/道路/车辆属性命中 96.0%/92.0%/95.6%、7 类参与者、20.0% 碰撞。
生成模块的关键对比：清晰呈现「用 10 倍时间换取属性可控性与场景严苛性」的权衡。