PlannerForge：用大模型智能体打通自动驾驶运动规划测试

导语

自动驾驶系统的安全验证，难点不只是找到一个场景，而是要持续生成有价值的测试样本、将自然语言要求转成可执行环境、运行规划器，并判断系统究竟为何失败。现有场景测试往往由多个独立模块组成，生成、检索、修改、执行和分析之间缺少紧密反馈。发表于 EMNLP 2026 主会的 PlannerForge，试图用一套大模型智能体框架把这条链路连接起来。

核心要点

• 覆盖完整测试链路。 PlannerForge 将场景生成、场景选择、场景修改、模块路由、运动规划器测试和结果分析纳入统一流程，目标是减少人工在不同工具之间搬运需求和测试结果。
• 增加两个扩展环节。 除传统的场景到评估流程外，系统还加入 ADS Enhancement 与 ADS Benchmarking，分别面向自动驾驶系统改进和跨系统基准比较。换言之，它不只负责“找问题”，还尝试帮助组织后续改进与评测。
• 评估不同模型和提示策略。 研究使用 10 个现成大模型，在 5 种提示条件下考察各项任务。按任务取得的最佳分数为 0.88 至 1.00；20B—35B 规模的开源后端在多数任务上可以接近商业 API，Qwen3.6:35B 在五项任务中的三项达到相当表现。
• 关注端到端损耗。 当多个模块串联时，商业模型链路保留了 83% 的种子查询，开源模型链路保留了 78%。这说明单模块表现并不等于完整系统表现，信息在路由、转换和执行过程中仍会损失。
• 改善自然语言到场景的落地。 与 Scenario Factory 2.0 的对比中，PlannerForge 在 200 条自然语言请求中生成了 193 个可执行场景，而对方为 144 个；对城市、道路和车辆属性的实现率达到 92%—96%。

意义与边界

PlannerForge 的价值首先在于重新定义自动驾驶测试工具的组织方式：大模型不再只充当场景生成器，而是成为连接需求、仿真执行和评估反馈的调度层。这种设计有望降低测试流程的碎片化，并让测试人员用更接近自然语言的方式提出复杂条件。

但这些结果仍应被理解为框架和任务层面的验证，而不是自动驾驶安全已经得到证明。测试质量取决于场景是否真实、仿真器是否可靠、评估标准是否充分，以及智能体能否识别自身生成或判断中的错误。尤其是端到端保留率显示，模块之间的衔接仍是关键瓶颈。未来更重要的问题，是这些智能体能否在更复杂的交通参与者互动、真实数据和独立安全审计中保持稳定，并将发现的问题转化为可验证的系统改进。

来源：Hugging Face Daily Papers