让一个大模型帮你订一趟 5 天 4 城的出差行程,要求航班预算不超过 8000、每天至少一个客户拜访、周三下午留给远程会议、住宿离地铁站步行 15 分钟以内。这类任务的难度不在于任何单一约束,而在于所有约束必须同时满足——改一个时间窗口,可能连锁打翻整个预算和路线。
这就是"规划"能力的核心挑战:把目标、约束、资源和长期后果协调进一个可执行、可验证的方案。2026 年 5 月 20 日,腾讯混元团队与中国人民大学高瓴人工智能学院联合发布了 PlanningBench(arXiv:2605.20873),一个面向 LLM 规划能力的可扩展、可验证评测与训练框架,在 HuggingFace 和 GitHub 同步开源。 结果很直白:在 PlanningBench 的测试集上,GPT-5.4 最高配置(xhigh)的全通过率(All-pass)仅为 63.17%,意味着超过三分之一的规划任务它无法给出完全满足所有约束的方案。开源模型中表现最好的 Seed-2.0-pro-high 为 44.33%,DeepSeek-V3.2-thinking 为 37.13%,Qwen3.5-plus-thinking 为 34.03%。 PlanningBench 做了什么不一样的事
现有的规划评测绝大多数是"固定题库"模式——收集一批任务实例,跑模型,出分数。PlanBench(ASU,2022 年首发)基于 PDDL 形式化语言定义规划域,侧重测试模型是否掌握了形式化推理能力。TravelPlanner(2024)把评测聚焦到旅行规划这一个垂直场景。刚刚在 6 月 3 日发布的 Agent Planning Benchmark(APB)覆盖了 22 个领域和 4209 个多模态用例,但关注的是智能体的规划诊断,不提供训练支持。
PlanningBench 的设计思路不同。它不是一个固定的题集,而是一个"数据生成框架"——能按需合成规划问题,同时自动生成验证清单(checklist),既能用来评测,也能直接用来做强化学习训练。
具体做法分两步走。第一步由 20 名专业标注员和算法研究员从真实规划场景中提炼出任务分类体系(taxonomy),覆盖 6 大规划家族、30+ 具体任务类型。6 大家族分别是:排程与时间表编排(占比 28.42%,含课程排课、会议安排、考试调度等)、项目与生产运营(21.90%)、路线与出行(17.21%)、资源分配与匹配(11.21%)、应急响应与公共服务(11.47%)、排班与人力调度(9.78%)。每个任务类型平均有 5-10 个子任务变体。
第二步是约束驱动的合成流水线(constraint-driven synthesis pipeline)。流水线由三个闭环组件构成:Generator 生成候选实例,Responder 尝试求解,Critic 验证结果。当 Responder 完全解出当前实例时,流水线自动提高下一轮的约束难度——减少基础约束的采样权重,增加中等和困难约束的采样权重。约束本身分三层:基础层(资源边界、时间窗口、可行性)、中等层(公平性、多目标权衡、负载均衡)、困难层(不可行识别、异常恢复、冲突目标下的协调)。
这套流水线生成的数据经过自动验证和人工质控审计,86.15% 的合成样本无需修改或仅需小幅修订即可直接使用,没有样本被直接丢弃。
对比来看,PlanningBench 在几个维度上与现有评测拉开了差距:
评测结果:即使最强模型也有三分之一的任务做不完
PlanningBench 用两个指标衡量规划能力:All-pass(全通过率,方案必须满足验证清单中的所有条目)和 Avg-pass(平均通过率,满足了多大比例的条目)。前者衡量"能不能交出一份完整方案",后者衡量"做对了多少局部"。
11 个模型的完整排名如下:
GPT-5.4-xhigh 排第一,All-pass 63.17%,Avg-pass 92.35%。GPT-5.4-high 和 GPT-5.4-medium 紧随其后,All-pass 分别为 58.56% 和 58.09%。Gemini-3-1-pro 排第四,53.25%。 开源阵营中,Seed-2.0-pro-high 以 44.33% 领跑,后面依次是 DeepSeek-V3.2-thinking(37.13%)、Hy3-Preview(36.17%,即腾讯混元自家模型)、Qwen3.5-plus-thinking(34.03%)、DeepSeek-R1(33.07%)。老一代的 Gemini-2.5-pro 排到了第十位(31.70%),Seed-2.0-pro-medium 垫底(30.63%)。
几个值得关注的点。All-pass 和 Avg-pass 之间存在巨大落差——GPT-5.4-xhigh 的 Avg-pass 高达 92.35%,说明它大部分约束都能满足,但 All-pass 只有 63.17%,说明剩下的 7-8% 约束频繁成为"最后一根稻草"。这验证了规划任务的核心难点:一个局部合理的决策可能在全局层面导致方案失败。
闭源与开源之间的差距也很明显。排名前四全是闭源模型,开源最高的 Seed-2.0-pro-high 落后 Gemini-3-1-pro 近 9 个百分点。腾讯自家的 Hy3-Preview 排在开源第三、总榜第七,没有主场加分——考虑到评测框架出自同一团队,这个结果反而增加了评测的可信度。
不只是评测:规划数据做 RL 训练,效果外溢到通用指令遵循
PlanningBench 的第二个贡献是把同一套验证数据直接用于强化学习训练。团队使用 GRPO(Group Relative Policy Optimization)在 PlanningBench 生成的数据上做训练,然后在模型从未见过的规划评测集上测试迁移效果。
结果显示,训练后的模型在 TravelPlanner 和 ChinaTravel 这两个外部规划评测上均有提升。更有意思的是,收益不局限于规划任务——在 Multi-Challenge、Inverse IFEval、Collie 等通用指令遵循和复杂推理评测上也观察到了增益。这意味着规划训练可能在教模型"约束整合"和"全局一致性维护"这类通用能力,而非只是拟合特定任务模板。
论文还发现了一个训练层面的关键洞察:具有确定性最优解(determinate optimal solutions)的规划实例,能提供更清晰的奖励信号和更稳定的训练动态。早期一批约 1000 个合成样本中,由于答案空间过于宽松(多个局部可行解都能得正分),GRPO 训练反而导致性能退化。后续批次加强了对唯一最优解的偏好,训练效果才明确改善。
这个发现对 RL 训练实践有直接启示:如果奖励信号只能区分"部分对"和"部分错",模型可能学到的是如何拿部分分,而非如何构建全局一致的方案。PlanningBench 的约束验证清单和确定性最优解偏好,让奖励信号具备了方向性。
局限和需要注意的地方
PlanningBench 的设计选择同时也是它的边界。
纯文本、无工具、自包含的设定简化了评测,但也意味着它不覆盖真实世界规划中最常见的两个环节:信息检索和工具交互。TravelPlanner 需要调用航班和酒店 API,APB 需要调用工具链——PlanningBench 有意跳过了这些。好处是控制了变量(排除了工具调用失败对规划能力评估的干扰),代价是它测的是"纯推理规划"而非"端到端规划执行"。
合成数据的真实性仍有上限。虽然任务分类体系来自真实场景,但具体实例是由 LLM 合成的(Generator 本身是一个模型)。论文报告了 86.15% 的样本质量合格率和人工审计流程,但合成数据是否完全覆盖了真实规划问题的长尾复杂性,这个问题还没有答案。
评测覆盖的模型范围有局限。11 个模型中有 3 个是 GPT-5.4 的不同配置,Anthropic 系列模型(Claude)完全缺席。这可能是 API 可用性的原因,但确实影响了结果的完整性。 论文团队与腾讯混元团队的关系需要透明度。一作和通讯作者分属人民大学和腾讯混元,Hy3-Preview 是腾讯自家模型。虽然 Hy3-Preview 在排名中没有异常表现(总榜第七、开源第三),但评测方与被评测方的利益关联是读者应该知道的信息。
GRPO 训练实验的规模和可复现性。论文给出了迁移增益的方向性结论,但未详细公布训练的具体超参数、数据量、计算成本和统计显著性区间。"确定性最优解提供更好奖励信号"这个洞察很有价值,但目前还是基于有限实验的观察,不是大规模验证过的结论。
选型建议:PlanningBench 适合谁
如果你在研究 LLM 规划能力,PlanningBench 提供了目前覆盖面最广的规划评测框架(30+ 任务类型 vs 大多数竞品的 1-5 个)。它的约束分层体系(基础/中等/困难)和自适应难度合成,比固定题库更适合用来做细粒度诊断——比如定位一个模型是在"时间窗口冲突"上弱还是在"多目标权衡"上弱。
如果你在做 RL 训练,PlanningBench 的最大价值可能不是评测,而是它的验证清单可以直接转化为奖励信号。论文证明了在规划数据上做 GRPO 训练能产生跨任务迁移增益,对通用指令遵循也有正向溢出。"确定性最优解"的训练偏好是一个值得在自己数据上复现的实践建议。
如果你需要端到端的智能体规划评测,PlanningBench 不够用。它测的是纯文本推理规划,不涉及工具调用和环境交互。这种场景更适合 TravelPlanner(旅行规划 + API 检索)、APB(多领域 + 工具链)或 PawBench(模型 × Harness 交叉评测)。
如果你是 PlanBench(ASU)的用户,需要注意名字相似但项目完全不同。PlanBench 基于 PDDL 形式化域、测试的是形式化推理,PlanningBench 基于自然语言真实场景、测试的是约束整合规划。两者互补而非替代。