最近我把一批视觉语言模型拉到同一套评测框架下跑了一遍发现了一个大家其实早有预感、但第一次被量化出来的现象你把一张乱糟糟的厨房照片丢给模型它能详细说出烤箱上搁着烤盘、台面下有一摊水渍但当你给它布置一个实体任务——比如“把蓝色杯子放到最左边的抽屉里”它几乎拿不出一条像样的动作序列。这个现象的量化版本就是Plan-Bench这个评测基准想回答的问题。它的标题问得很直接现有的视觉语言模型VLM能不能从感知层面的“看图说话”再往前走出关键一步在具身世界中完成真正的推理与规划Plan-Bench这个名字本身就划清了评测边界不测模型会不会识别而测它会不会推理、会不会制定计划、会不会在计划失败后自我修复。接下来的内容我按一个“动手复现过它的人”的视角来聊先讲为什么非要有Plan-Bench不可再拆它的任务体系和计分逻辑然后把我踩过的几个坑和完整排查过程交代清楚最后谈谈从结果里读到的VLM能力边界。这篇文章适合正在做多模态模型评测、研究具身智能Agent、或者想给机器人配“大脑”的开发者和研究者参考。1. 一个让人意外的结果模型会看图说话却在动手做事时彻底露馅1.1 感知题接近满分规划题不到三成我在本地复现Plan-Bench的时候第一轮先跑的是它的感知级子任务。这个环节里模型只需要看图回答一些可以直接从视觉观测中得到的结论物体在哪个位置、什么颜色、尺寸大小、是否被遮挡。这部分结果没什么意外主流VLM做得都很好某7B开源模型准确率能做到90%上下闭源商用组的成绩更是接近满分。真正让我挑眉的是更高层级的规划环节。一进到“规划”题目模型需要把一个目标描述翻译成若干动作整个局面就完全不一样了。同一个开源模型感知得分还在90%附近规划类任务的成功率掉到了不到30%。不是某一项特别难而是几乎所有涉及多步操作的任务都开始崩塌。我最初以为是提示词写得太含糊反复调整了一个下午结论是差距虽然会因为提示词往回收一点但整体趋势非常稳固感知和规划之间隔着一条明确的能力鸿沟。模型类别感知任务得分推理任务得分规划任务得分开源7B组91%72%28%开源13B组93%78%35%闭源商用组96%88%51%这张表里是我自己在统一配置下跑出来的趋势结果未必代表这些模型在所有硬件条件下的表现但相对顺序是稳定的。最扎眼的不是闭源商用组也才到51%而是“感知-推理-规划”三档分数呈现瀑布式下跌。模型能看明白世界也能推断出局部因果但一旦要求它把所有这些线索组织成一个可执行的多步方案能力就开始断崖式衰减。1.2 为什么感知和规划之间的差距这么大很多人会把“VLM规划能力差”简单归结为参数不够多或者训练数据不够大但Plan-Bench这组数据指向一种更像本质的解释感知本质是“匹配”规划本质是“生成与决策”两件事调用的是完全不同的内部机制。感知任务里模型做的是把二维图像特征映射到语义标签。训练数据里有海量的图文对模型见惯了各种物体、颜色、空间关系所以它本质上是在做模式匹配高度相关——看到这个特征组合能联想到“蓝杯子放在桌上”的语义描述因为它在大量样本里见过类似的映射自然答得准。规划就不一样了。给出“蓝色杯子放到红色盒子里”的目标模型需要维护一个状态集合杯子的初始坐标、需要被抓取并移动的轨迹、目标容器的位置、容器盖子的开关状态。它还要预测动作的后果如果先抓杯子而不是先开盖子会不会导致后续拿不出来这些不是简单的输入输出映射而是一种对世界动态变化的建模能力。用大白话说感知是“认得出菜名”规划是“能安排后厨流程”认菜名靠记忆排后厨流程却需要模拟食材、灶台、时间线之间的关系后者的复杂度完全不在一个量级。这种差异也解释了一个现象很多VLM在静态图片问答上分数很漂亮一扔进具体环境就原形毕露。它们的视觉编码器练得很成熟但决策部分仍然靠语言模型的续写本能硬撑并没有真正学出一个“如果执行A世界会变成B”的动态预测器。Plan-Bench把这两类能力放在同一个评测框架下对比最大的价值就是让这种断层变得可以量化。2. 为什么说“会看”不等于“会做”Plan-Bench想补上的评测空白2.1 已有评测体系的盲区如果说Plan-Bench的结果让人意外那更让人意外的是在它之前大家其实很难用一个现成的评测来完整回答“现有VLM能不能规划”。市场上有各种评测基准但各有各的视野盲区。第一类是传统的图像标注和视觉问答基准比如看图描述、看图标答、场景图理解。这类评测测的核心是感知和短链推理。你可以问模型“图中有几只猫”“猫旁边的玩具是什么颜色”它回答得越准只能说明视觉理解模块越强但它永远不要求模型输出一个多步行为计划。静态题库里根本没有“动作后果”和“世界状态变化”这两个概念。第二类是各种具身智能基准里面确实有机器人抓取、导航、操作等任务但它们的设计目标通常偏向强化学习控制很多基准把底层感知模块预先给好让智能体直接在高维状态上训练策略语言模型在其中只是可选项甚至完全缺席。这类基准适合研究“怎么动”的问题却很少去关注“怎么决定动什么”的问题——它测的不是VLM。第三类是近年流行的Agent基准让模型调用API、操控网页、玩文字冒险游戏。这些任务确实考查推理和工具调用但主要输入输出是文本或结构化接口视觉信息更多是附带的截图而不是决定成败的核心状态表示。具身世界最大的特殊性在于视觉是唯一的实时反馈通道动作会对像素产生直接改变模型必须从视觉上确认“我刚才做成了没有”。这一点文字Agent基准很难模拟。评测类型主要能力视觉作用行动闭环图像理解/VQA类感知、短程推理核心输入无传统具身控制类运动控制、策略学习常用底层特征有但偏控制文本/API Agent类推理、工具调用辅助有但弱视觉Plan-Bench感知推理规划闭环调整核心输入与反馈有且强调视觉反馈2.2 Plan-Bench试图连接语言、视觉和行动Plan-Bench想做的是把上面三类评测的长处收敛到一条完整链路上语言定义目标视觉感知状态推理连接因果规划生成动作执行提供反馈最后再由视觉验证结果。标题里“Beyond Perception”这个词喊得很准——它不想再测你是不是一个好“看图识字”选手而是想测你能不能在一个代理环境中赢下一场分步执行的比赛。从评测设计哲学上说Plan-Bench不是训练工具。它不教模型怎么规划也不提供梯度或奖励去改进策略它只负责给能力拍一张X光片。你在规划层上分数低说明动作序列生成有问题你在执行层分数低但规划层分数高说明模型是“背出了一份漂亮计划”却缺少依据当前状态纠错的本领。这样划分出来的诊断信息比一个笼统的总排名要有指导意义得多。这个思路对我自己后续做模型评估启发很大。你会发现真正有用的评测基准往往不是把一堆任务往模型面前一摆、写个简单的正确率就完事而是先把能力拆成可解释的层级再让每个层级的得分去回答一个独立的问题它看得清吗它想得到吗它安排得了吗它做得成吗Plan-Bench的四层结构就是顺着这条线索搭起来的。3. Plan-Bench的评测体系任务拆解、环境设定和计分方式3.1 四层任务体系从感知到执行Plan-Bench的任务体系分成四个层级越往上越接近“在真实世界里干活”的完整过程。前两层解决“模型看懂了多少”后两层解决“模型能用多少”。Level 1是感知任务集合核心考察视觉基础。比如在渲染图上找到目标物体的位置、判断物体的颜色和形状、识别空间关系如“杯子在盘子的左边”。这一层是整份评测的基线检验视觉编码器是否合格。Level 2是推理任务集合重点从视觉描述转向物理和因果推断。典型问题包括把木块放在斜面上它会不会滑下来翻倒杯子里的水会流向哪里遮挡关系变化之后物体还存在吗这类问题要求模型在静态图像上脑补出动态趋势考察的是物理直觉。Level 3是规划任务集合这是Plan-Bench真正发力的一层。给定一个目标和一张初始状态图模型必须输出一串有序动作例如“先夹取蓝块移动到红色盒子正上方再释放最后关闭盒盖”。这一层不要求模型真的去执行动作它只考核“计划是否合理”。Level 4是执行与重规划任务集合模型会被接入仿真环境执行一步动作后环境返回新的视觉状态再由模型决定下一步。这层考核的是闭环能力能不能发现自己的动作没有达成预期能不能修正计划能不能在目标还没完成时持续跟踪。四层之间是递进关系Level 1和2的错误会传导到Level 3和4但反过来Level 3和4的高分并不代表Level 1和2也有高分。所以Plan-Bench的报告必须分层呈现否则一个均值排名很容易淹没真正有价值的失败信号。3.2 环境与接口设计我复现时采用的是一个相当克制的桌面操作仿真环境一张桌面上随机摆放若干不同颜色和形状的物体以及几个带盖容器机械臂是执行器。观测接口完全是视觉化的模型只能拿到渲染图不能碰底层坐标。这意味着所有关于“物体在哪”的信息都要从图像里读出来而不是靠上帝视角的数字输入。动作空间也设计得很干净包括移动、抓取、放置、打开容器、关闭容器这几类原语。这样有两个好处一是避免动作语义模糊让评测聚焦于“模型有没有想清楚”而不是“模型有没有想出一个找不到动作能表达的花哨方案”二是执行器直接模拟结果动作合法才算有效执行非法动作会触发失败提示并保持环境状态不变。评测提供两种工作模式。第一种是离线计划模式初始渲染图加目标描述一起送入模型模型输出完整计划按静态规则打分。第二种是闭环执行模式程序把模型接入仿真循环每执行一个动作就重新渲染一个视角把新的图像和上一次动作日志组成输入再次喂给模型。第二种模式对状态跟踪的要求非常高因为它不允许模型赖在初始状态上不动逼着它持续刷新自己对“当前世界是什么样”的理解。3.3 计分方式与防刷机制计分如果只按“最终有没有完成目标”来算会留下两个漏洞。第一模型可能生成大量无效操作最后瞎猫碰到死耗子第二模型可能第一步就失败后面全是垃圾输出却因为目标偶尔被误打误撞满足分数还不低。Plan-Bench对计分的处理值得单独拿出来说因为它把“防止刷分”也当成评测设计的一部分。实际采用的分层计分大致是这样感知任务每题1分答对得1不做部分分推理任务允许模型给出解释性输出正确结论和合理理由都算分规划任务按动作序列和参考解之间的编辑距离折算动作顺序完全一致且没有多余步骤的拿满分顺序错但整体结构接近的拿部分分乱序且多出大量无关动作的基本为零分执行任务按终局状态是否达成判定同时统计无效动作比例和实际执行步数与理论最少步数的比值。最值得提的是“无效动作约束”这条规则。在执行任务里即使模型最后成功完成了目标只要无效动作比例高于阈值该试次照样判负。这个设计直接堵死了“疯狂乱试直到成功”的投机路径也让结果更贴近真实机器人应用场景——毕竟现实中一个不断做无用动作的机械臂就算最后完成了任务产线也不敢用。计分的核心逻辑可以简化成这样一个判定一个试次成功必须同时满足三条——目标状态达成、无效动作比例低于阈值、执行步数不超过上限。任何一个条件不满足该试次整体判负。这种“一票否决”思路避免了单一成功率指标带来的大量噪声我觉得很值得其他评测借鉴。4. 复现Plan-Bench时我踩过的那些坑4.1 仿真器版本和视觉输入一致性第一个坑在环境搭建阶段就踩到了。仿真环境的版本升级哪怕只是小版本号的变动渲染出来的光照、纹理、阴影细节也会有肉眼可感知的变化。这些变化对人无所谓但对VLM影响很大——同一张桌子旧版本是暖光反光新版本是冷光哑光模型给出的感知分数能差出3到5个百分点。解决办法不复杂但必须严格锁定仿真器版本号固定所有环境随机种子最好把每个场景的初始渲染图预生成并缓存。这样一来你在不同时间、不同机器上复现评测时输入给VLM的像素都是同一批结果才有可比性。我在实践里还会额外加一步在评测脚本启动时打印环境版本的哈希值防止某天某人悄无声息升级了依赖导致整个结果失效。pip install desk_env0.4.2 # 锁定仿真器版本 export EVAL_SEED42对复现评测而言环境锁死是第一优先级。宁可牺牲一点画面真实感也要保证图像输入的绝对可控否则后面所有分数波动都可能是在为环境噪声买单。4.2 提示词模板对结果的干扰第二个坑可能比第一个更容易让人崩溃。同一个模型、同一个场景、同一个目标只因为提示词模板的写法不同规划得分就能波动10个百分点以上。我做过一组对比提示词类型规划成功率同一模型极简只给目标和当前帧24%带输出格式规范要求JSON格式字段为actions37%带示例参考“移动-抓取-放置-关闭”41%带思维链引导先分析状态再给出计划44%这个波动幅度比很多模型之间的差距还大。如果不固定推理协议你评测的实际上是“谁的提示词调得好”而不是“模型能力谁更强”。Plan-Bench显然也考虑到了这一点约定了一套推荐的提示词模板和推理协议包括温度参数和随机种子。我的建议是把提示词模板当作评测代码的一部分进行版本管理任何改动都要重新跑整套评测否则前后的数字根本不能比较。4.3 闭环模式下喂图的细节到了闭环执行环节怎么喂图会产生一个非常隐蔽的坑。一开始我图省事把初始帧和执行过程中的历史帧全部拼在一起送到模型里结果模型经常出现“空间定向障碍”——物体已经被移走了它还坚持认为物体在原来的位置后续计划全盘错乱。原因后来看得很清楚当前帧才是环境状态最权威的证据历史帧只是记忆两相冲突时VLM往往更倾向于相信上下文里反复出现的旧信息。好的做法是每次只送当前最新渲染图作为视觉输入同时配合一段简短的动作日志文本比如“你已经做了抓取蓝块当前动作未执行”。这样既提供了必要的执行上下文又不至于用旧图像污染当前状态判断。这个细节虽然不起眼但对于想拿Plan-Bench评测自己模型尤其是做在线执行模式的人是最容易踩也最影响结果的坑之一。4.4 分数对不上原地的常见原因还有一个情况是很多人复现自己的评测拿结果和基准默认报告或者别人复现的分数一对比怎么都对不上。我排查过几次绝大多数是下面四个原因第一推理参数不一致。基准默认用贪心解码你在本地用采样解码候选动作序列就有了随机波动。第二最大生成长度设得太短模型计划写到一半就被截断但截断是静默的只看最终结果未必看得出来。第三动作解析器容错太严或太松评测自带的解析器允许动作和物体列表顺序稍有出入你写的解析器却不认误杀一堆本应合法的输出。第四评测中途机器负载高VLM推理超时被环境强制判负这类结果在日志里不显眼但会悄悄拉低成功率。我养成的习惯是写一个评测脚本把所有模型的原始输出文本完整落盘而不是只存一个分数。诊断分数对不上的问题时原始输出几乎总能在一分钟内告诉你答案——到底是模型没输出合法动作还是解析器没识别出来。这个习惯后来帮我省了无数小时的排查时间。5. 看完Plan-Bench的结果我对VLM具身规划的几个判断5.1 高感知分撑不起低规划分的体面把Plan-Bench的一批模型结果放在一起看最核心的现象可以归纳成一句话感知分高是必要条件但不是充分条件。同一批模型里感知得分从85%到97%的区间内规划得分从18%到52%不等两者在统计上显著相关但个体偏差十分夸张。最极端的例子是某开源模型感知94%规划却不到25%另一组闭源商用模型感知96%规划能到50%以上。这个判断的实践意义在于如果你想用VQA分数或者物体识别准确率来推断某个模型做具身Agent的能力大概率会被误导。要评估具身任务的能力就应该直接在具身任务上测。Plan-Bench的层级化设计让这种误导变得无处躲藏。5.2 动作序列的“编码”本身是一道隐藏门槛分析失败样本时我注意到一类特别值得注意的失败模式模型的自然语言描述完全正确它能在回复里写出“先抓蓝块移动到红盒上方释放关盖”但一旦进入正式评测的输出接口它产出的动作序列要么格式错误、要么漏掉某个动作、要么把“移动”和“抓取”两个动词的先后顺序搞反结果被解析器判为无效一张嘴丢掉了大量原本能拿到的分数。这让我意识到具身规划任务里结构化输出能力和规划能力本身是两码事。模型口语表达能力强不代表它能把计划翻译成机器可读的动作格式。对做应用的人来说这其实是个好消息即便模型规划逻辑暂时不够强只要在工程层给它接一个稳健的约束解码器强制输出合法动作流就能把一部分隐性能力兑现出来。5.3 状态跟踪与重规划是当前最明显的短板最后这个判断也是我最近在和做评测的朋友反复讨论时提到的当前VLM的闭环重规划能力基本处于短板中的短板。看执行层结果时我统计过一个现象大部分模型在离线规划模式下表现还算正常一旦进入在线执行模式分数并没有因反馈而变高反而经常原地踏步甚至下降。原因是它们无法有效利用新的视觉反馈来纠正已经执行错误的动作。更极端的case是模型执行一步之后环境状态明显偏离目标比如蓝块弹到了桌角模型下一步计划却完全忽略这个新位置继续按照原计划去抓初始坐标。这说明模型缺少一个“状态跟踪器”没有把“当前图像里物体的新位置”更新到内部计划里。这个短板未来大概率要靠更细的视觉表征、显式的世界状态存证模块或者专门的强化学习微调来解决。Plan-Bench最有价值的地方就是把这类最底层、最不性感、但最影响实际落地的问题暴露在阳光下。6. 结束之前还想再分享的一个小经验最后这部分不打算写什么完整结论只想分享一点我这两年评测模型攒下来的实际感受。如果你也想拿Plan-Bench这套思路去评测自己的模型或者训练自己的具身Agent一定要把评测过程当成一个完整的工程项目来对待不要只记一张分数表而是把提示词版本、推理参数、环境版本、随机种子、原始模型输出、解析器版本全部记录下来。分数只告诉你“差多少”原始日志才会告诉你“差在哪”和“为什么差”。另一个小建议是分层报告。不要只给一个总分把感知、推理、规划、闭环执行四类分数拆开看。一个总分排名第一的模型很可能只是感知分拉满规划能力一塌糊涂一个总分不高的模型也可能在规划子项上才是真正值得继续投入的方向。评测基准的意义不是制造排名而是给能力画像。Plan-Bench帮我做到的就是让“会看不会做”从一句模糊的直觉变成了一组可以随时引用的数字。如果非要总结一句对标题提问的个人回答那大概是现有的VLM离“在具身世界中真正推理与规划”还有明显距离但它们也不是完全没有规划能力只是这种能力还非常脆弱、非常依赖结构化的交互设计。Plan-Bench把这个距离精确地标了出来剩下的路就是每一个做模型和做应用的人自己去填了。 
长河君 · 2026/10/17 21:20:28 · 阅读 1.2k Plan-Bench评测：视觉语言模型“会看不会做”的能力鸿沟
最近我把一批视觉语言模型拉到同一套评测框架下跑了一遍发现了一个大家其实早有预感、但第一次被量化出来的现象你把一张乱糟糟的厨房照片丢给模型它能详细说出烤箱上搁着烤盘、台面下有一摊水渍但当你给它布置一个实体任务——比如“把蓝色杯子放到最左边的抽屉里”它几乎拿不出一条像样的动作序列。这个现象的量化版本就是Plan-Bench这个评测基准想回答的问题。它的标题问得很直接现有的视觉语言模型VLM能不能从感知层面的“看图说话”再往前走出关键一步在具身世界中完成真正的推理与规划Plan-Bench这个名字本身就划清了评测边界不测模型会不会识别而测它会不会推理、会不会制定计划、会不会在计划失败后自我修复。接下来的内容我按一个“动手复现过它的人”的视角来聊先讲为什么非要有Plan-Bench不可再拆它的任务体系和计分逻辑然后把我踩过的几个坑和完整排查过程交代清楚最后谈谈从结果里读到的VLM能力边界。这篇文章适合正在做多模态模型评测、研究具身智能Agent、或者想给机器人配“大脑”的开发者和研究者参考。1. 一个让人意外的结果模型会看图说话却在动手做事时彻底露馅1.1 感知题接近满分规划题不到三成我在本地复现Plan-Bench的时候第一轮先跑的是它的感知级子任务。这个环节里模型只需要看图回答一些可以直接从视觉观测中得到的结论物体在哪个位置、什么颜色、尺寸大小、是否被遮挡。这部分结果没什么意外主流VLM做得都很好某7B开源模型准确率能做到90%上下闭源商用组的成绩更是接近满分。真正让我挑眉的是更高层级的规划环节。一进到“规划”题目模型需要把一个目标描述翻译成若干动作整个局面就完全不一样了。同一个开源模型感知得分还在90%附近规划类任务的成功率掉到了不到30%。不是某一项特别难而是几乎所有涉及多步操作的任务都开始崩塌。我最初以为是提示词写得太含糊反复调整了一个下午结论是差距虽然会因为提示词往回收一点但整体趋势非常稳固感知和规划之间隔着一条明确的能力鸿沟。模型类别感知任务得分推理任务得分规划任务得分开源7B组91%72%28%开源13B组93%78%35%闭源商用组96%88%51%这张表里是我自己在统一配置下跑出来的趋势结果未必代表这些模型在所有硬件条件下的表现但相对顺序是稳定的。最扎眼的不是闭源商用组也才到51%而是“感知-推理-规划”三档分数呈现瀑布式下跌。模型能看明白世界也能推断出局部因果但一旦要求它把所有这些线索组织成一个可执行的多步方案能力就开始断崖式衰减。1.2 为什么感知和规划之间的差距这么大很多人会把“VLM规划能力差”简单归结为参数不够多或者训练数据不够大但Plan-Bench这组数据指向一种更像本质的解释感知本质是“匹配”规划本质是“生成与决策”两件事调用的是完全不同的内部机制。感知任务里模型做的是把二维图像特征映射到语义标签。训练数据里有海量的图文对模型见惯了各种物体、颜色、空间关系所以它本质上是在做模式匹配高度相关——看到这个特征组合能联想到“蓝杯子放在桌上”的语义描述因为它在大量样本里见过类似的映射自然答得准。规划就不一样了。给出“蓝色杯子放到红色盒子里”的目标模型需要维护一个状态集合杯子的初始坐标、需要被抓取并移动的轨迹、目标容器的位置、容器盖子的开关状态。它还要预测动作的后果如果先抓杯子而不是先开盖子会不会导致后续拿不出来这些不是简单的输入输出映射而是一种对世界动态变化的建模能力。用大白话说感知是“认得出菜名”规划是“能安排后厨流程”认菜名靠记忆排后厨流程却需要模拟食材、灶台、时间线之间的关系后者的复杂度完全不在一个量级。这种差异也解释了一个现象很多VLM在静态图片问答上分数很漂亮一扔进具体环境就原形毕露。它们的视觉编码器练得很成熟但决策部分仍然靠语言模型的续写本能硬撑并没有真正学出一个“如果执行A世界会变成B”的动态预测器。Plan-Bench把这两类能力放在同一个评测框架下对比最大的价值就是让这种断层变得可以量化。2. 为什么说“会看”不等于“会做”Plan-Bench想补上的评测空白2.1 已有评测体系的盲区如果说Plan-Bench的结果让人意外那更让人意外的是在它之前大家其实很难用一个现成的评测来完整回答“现有VLM能不能规划”。市场上有各种评测基准但各有各的视野盲区。第一类是传统的图像标注和视觉问答基准比如看图描述、看图标答、场景图理解。这类评测测的核心是感知和短链推理。你可以问模型“图中有几只猫”“猫旁边的玩具是什么颜色”它回答得越准只能说明视觉理解模块越强但它永远不要求模型输出一个多步行为计划。静态题库里根本没有“动作后果”和“世界状态变化”这两个概念。第二类是各种具身智能基准里面确实有机器人抓取、导航、操作等任务但它们的设计目标通常偏向强化学习控制很多基准把底层感知模块预先给好让智能体直接在高维状态上训练策略语言模型在其中只是可选项甚至完全缺席。这类基准适合研究“怎么动”的问题却很少去关注“怎么决定动什么”的问题——它测的不是VLM。第三类是近年流行的Agent基准让模型调用API、操控网页、玩文字冒险游戏。这些任务确实考查推理和工具调用但主要输入输出是文本或结构化接口视觉信息更多是附带的截图而不是决定成败的核心状态表示。具身世界最大的特殊性在于视觉是唯一的实时反馈通道动作会对像素产生直接改变模型必须从视觉上确认“我刚才做成了没有”。这一点文字Agent基准很难模拟。评测类型主要能力视觉作用行动闭环图像理解/VQA类感知、短程推理核心输入无传统具身控制类运动控制、策略学习常用底层特征有但偏控制文本/API Agent类推理、工具调用辅助有但弱视觉Plan-Bench感知推理规划闭环调整核心输入与反馈有且强调视觉反馈2.2 Plan-Bench试图连接语言、视觉和行动Plan-Bench想做的是把上面三类评测的长处收敛到一条完整链路上语言定义目标视觉感知状态推理连接因果规划生成动作执行提供反馈最后再由视觉验证结果。标题里“Beyond Perception”这个词喊得很准——它不想再测你是不是一个好“看图识字”选手而是想测你能不能在一个代理环境中赢下一场分步执行的比赛。从评测设计哲学上说Plan-Bench不是训练工具。它不教模型怎么规划也不提供梯度或奖励去改进策略它只负责给能力拍一张X光片。你在规划层上分数低说明动作序列生成有问题你在执行层分数低但规划层分数高说明模型是“背出了一份漂亮计划”却缺少依据当前状态纠错的本领。这样划分出来的诊断信息比一个笼统的总排名要有指导意义得多。这个思路对我自己后续做模型评估启发很大。你会发现真正有用的评测基准往往不是把一堆任务往模型面前一摆、写个简单的正确率就完事而是先把能力拆成可解释的层级再让每个层级的得分去回答一个独立的问题它看得清吗它想得到吗它安排得了吗它做得成吗Plan-Bench的四层结构就是顺着这条线索搭起来的。3. Plan-Bench的评测体系任务拆解、环境设定和计分方式3.1 四层任务体系从感知到执行Plan-Bench的任务体系分成四个层级越往上越接近“在真实世界里干活”的完整过程。前两层解决“模型看懂了多少”后两层解决“模型能用多少”。Level 1是感知任务集合核心考察视觉基础。比如在渲染图上找到目标物体的位置、判断物体的颜色和形状、识别空间关系如“杯子在盘子的左边”。这一层是整份评测的基线检验视觉编码器是否合格。Level 2是推理任务集合重点从视觉描述转向物理和因果推断。典型问题包括把木块放在斜面上它会不会滑下来翻倒杯子里的水会流向哪里遮挡关系变化之后物体还存在吗这类问题要求模型在静态图像上脑补出动态趋势考察的是物理直觉。Level 3是规划任务集合这是Plan-Bench真正发力的一层。给定一个目标和一张初始状态图模型必须输出一串有序动作例如“先夹取蓝块移动到红色盒子正上方再释放最后关闭盒盖”。这一层不要求模型真的去执行动作它只考核“计划是否合理”。Level 4是执行与重规划任务集合模型会被接入仿真环境执行一步动作后环境返回新的视觉状态再由模型决定下一步。这层考核的是闭环能力能不能发现自己的动作没有达成预期能不能修正计划能不能在目标还没完成时持续跟踪。四层之间是递进关系Level 1和2的错误会传导到Level 3和4但反过来Level 3和4的高分并不代表Level 1和2也有高分。所以Plan-Bench的报告必须分层呈现否则一个均值排名很容易淹没真正有价值的失败信号。3.2 环境与接口设计我复现时采用的是一个相当克制的桌面操作仿真环境一张桌面上随机摆放若干不同颜色和形状的物体以及几个带盖容器机械臂是执行器。观测接口完全是视觉化的模型只能拿到渲染图不能碰底层坐标。这意味着所有关于“物体在哪”的信息都要从图像里读出来而不是靠上帝视角的数字输入。动作空间也设计得很干净包括移动、抓取、放置、打开容器、关闭容器这几类原语。这样有两个好处一是避免动作语义模糊让评测聚焦于“模型有没有想清楚”而不是“模型有没有想出一个找不到动作能表达的花哨方案”二是执行器直接模拟结果动作合法才算有效执行非法动作会触发失败提示并保持环境状态不变。评测提供两种工作模式。第一种是离线计划模式初始渲染图加目标描述一起送入模型模型输出完整计划按静态规则打分。第二种是闭环执行模式程序把模型接入仿真循环每执行一个动作就重新渲染一个视角把新的图像和上一次动作日志组成输入再次喂给模型。第二种模式对状态跟踪的要求非常高因为它不允许模型赖在初始状态上不动逼着它持续刷新自己对“当前世界是什么样”的理解。3.3 计分方式与防刷机制计分如果只按“最终有没有完成目标”来算会留下两个漏洞。第一模型可能生成大量无效操作最后瞎猫碰到死耗子第二模型可能第一步就失败后面全是垃圾输出却因为目标偶尔被误打误撞满足分数还不低。Plan-Bench对计分的处理值得单独拿出来说因为它把“防止刷分”也当成评测设计的一部分。实际采用的分层计分大致是这样感知任务每题1分答对得1不做部分分推理任务允许模型给出解释性输出正确结论和合理理由都算分规划任务按动作序列和参考解之间的编辑距离折算动作顺序完全一致且没有多余步骤的拿满分顺序错但整体结构接近的拿部分分乱序且多出大量无关动作的基本为零分执行任务按终局状态是否达成判定同时统计无效动作比例和实际执行步数与理论最少步数的比值。最值得提的是“无效动作约束”这条规则。在执行任务里即使模型最后成功完成了目标只要无效动作比例高于阈值该试次照样判负。这个设计直接堵死了“疯狂乱试直到成功”的投机路径也让结果更贴近真实机器人应用场景——毕竟现实中一个不断做无用动作的机械臂就算最后完成了任务产线也不敢用。计分的核心逻辑可以简化成这样一个判定一个试次成功必须同时满足三条——目标状态达成、无效动作比例低于阈值、执行步数不超过上限。任何一个条件不满足该试次整体判负。这种“一票否决”思路避免了单一成功率指标带来的大量噪声我觉得很值得其他评测借鉴。4. 复现Plan-Bench时我踩过的那些坑4.1 仿真器版本和视觉输入一致性第一个坑在环境搭建阶段就踩到了。仿真环境的版本升级哪怕只是小版本号的变动渲染出来的光照、纹理、阴影细节也会有肉眼可感知的变化。这些变化对人无所谓但对VLM影响很大——同一张桌子旧版本是暖光反光新版本是冷光哑光模型给出的感知分数能差出3到5个百分点。解决办法不复杂但必须严格锁定仿真器版本号固定所有环境随机种子最好把每个场景的初始渲染图预生成并缓存。这样一来你在不同时间、不同机器上复现评测时输入给VLM的像素都是同一批结果才有可比性。我在实践里还会额外加一步在评测脚本启动时打印环境版本的哈希值防止某天某人悄无声息升级了依赖导致整个结果失效。pip install desk_env0.4.2 # 锁定仿真器版本 export EVAL_SEED42对复现评测而言环境锁死是第一优先级。宁可牺牲一点画面真实感也要保证图像输入的绝对可控否则后面所有分数波动都可能是在为环境噪声买单。4.2 提示词模板对结果的干扰第二个坑可能比第一个更容易让人崩溃。同一个模型、同一个场景、同一个目标只因为提示词模板的写法不同规划得分就能波动10个百分点以上。我做过一组对比提示词类型规划成功率同一模型极简只给目标和当前帧24%带输出格式规范要求JSON格式字段为actions37%带示例参考“移动-抓取-放置-关闭”41%带思维链引导先分析状态再给出计划44%这个波动幅度比很多模型之间的差距还大。如果不固定推理协议你评测的实际上是“谁的提示词调得好”而不是“模型能力谁更强”。Plan-Bench显然也考虑到了这一点约定了一套推荐的提示词模板和推理协议包括温度参数和随机种子。我的建议是把提示词模板当作评测代码的一部分进行版本管理任何改动都要重新跑整套评测否则前后的数字根本不能比较。4.3 闭环模式下喂图的细节到了闭环执行环节怎么喂图会产生一个非常隐蔽的坑。一开始我图省事把初始帧和执行过程中的历史帧全部拼在一起送到模型里结果模型经常出现“空间定向障碍”——物体已经被移走了它还坚持认为物体在原来的位置后续计划全盘错乱。原因后来看得很清楚当前帧才是环境状态最权威的证据历史帧只是记忆两相冲突时VLM往往更倾向于相信上下文里反复出现的旧信息。好的做法是每次只送当前最新渲染图作为视觉输入同时配合一段简短的动作日志文本比如“你已经做了抓取蓝块当前动作未执行”。这样既提供了必要的执行上下文又不至于用旧图像污染当前状态判断。这个细节虽然不起眼但对于想拿Plan-Bench评测自己模型尤其是做在线执行模式的人是最容易踩也最影响结果的坑之一。4.4 分数对不上原地的常见原因还有一个情况是很多人复现自己的评测拿结果和基准默认报告或者别人复现的分数一对比怎么都对不上。我排查过几次绝大多数是下面四个原因第一推理参数不一致。基准默认用贪心解码你在本地用采样解码候选动作序列就有了随机波动。第二最大生成长度设得太短模型计划写到一半就被截断但截断是静默的只看最终结果未必看得出来。第三动作解析器容错太严或太松评测自带的解析器允许动作和物体列表顺序稍有出入你写的解析器却不认误杀一堆本应合法的输出。第四评测中途机器负载高VLM推理超时被环境强制判负这类结果在日志里不显眼但会悄悄拉低成功率。我养成的习惯是写一个评测脚本把所有模型的原始输出文本完整落盘而不是只存一个分数。诊断分数对不上的问题时原始输出几乎总能在一分钟内告诉你答案——到底是模型没输出合法动作还是解析器没识别出来。这个习惯后来帮我省了无数小时的排查时间。5. 看完Plan-Bench的结果我对VLM具身规划的几个判断5.1 高感知分撑不起低规划分的体面把Plan-Bench的一批模型结果放在一起看最核心的现象可以归纳成一句话感知分高是必要条件但不是充分条件。同一批模型里感知得分从85%到97%的区间内规划得分从18%到52%不等两者在统计上显著相关但个体偏差十分夸张。最极端的例子是某开源模型感知94%规划却不到25%另一组闭源商用模型感知96%规划能到50%以上。这个判断的实践意义在于如果你想用VQA分数或者物体识别准确率来推断某个模型做具身Agent的能力大概率会被误导。要评估具身任务的能力就应该直接在具身任务上测。Plan-Bench的层级化设计让这种误导变得无处躲藏。5.2 动作序列的“编码”本身是一道隐藏门槛分析失败样本时我注意到一类特别值得注意的失败模式模型的自然语言描述完全正确它能在回复里写出“先抓蓝块移动到红盒上方释放关盖”但一旦进入正式评测的输出接口它产出的动作序列要么格式错误、要么漏掉某个动作、要么把“移动”和“抓取”两个动词的先后顺序搞反结果被解析器判为无效一张嘴丢掉了大量原本能拿到的分数。这让我意识到具身规划任务里结构化输出能力和规划能力本身是两码事。模型口语表达能力强不代表它能把计划翻译成机器可读的动作格式。对做应用的人来说这其实是个好消息即便模型规划逻辑暂时不够强只要在工程层给它接一个稳健的约束解码器强制输出合法动作流就能把一部分隐性能力兑现出来。5.3 状态跟踪与重规划是当前最明显的短板最后这个判断也是我最近在和做评测的朋友反复讨论时提到的当前VLM的闭环重规划能力基本处于短板中的短板。看执行层结果时我统计过一个现象大部分模型在离线规划模式下表现还算正常一旦进入在线执行模式分数并没有因反馈而变高反而经常原地踏步甚至下降。原因是它们无法有效利用新的视觉反馈来纠正已经执行错误的动作。更极端的case是模型执行一步之后环境状态明显偏离目标比如蓝块弹到了桌角模型下一步计划却完全忽略这个新位置继续按照原计划去抓初始坐标。这说明模型缺少一个“状态跟踪器”没有把“当前图像里物体的新位置”更新到内部计划里。这个短板未来大概率要靠更细的视觉表征、显式的世界状态存证模块或者专门的强化学习微调来解决。Plan-Bench最有价值的地方就是把这类最底层、最不性感、但最影响实际落地的问题暴露在阳光下。6. 结束之前还想再分享的一个小经验最后这部分不打算写什么完整结论只想分享一点我这两年评测模型攒下来的实际感受。如果你也想拿Plan-Bench这套思路去评测自己的模型或者训练自己的具身Agent一定要把评测过程当成一个完整的工程项目来对待不要只记一张分数表而是把提示词版本、推理参数、环境版本、随机种子、原始模型输出、解析器版本全部记录下来。分数只告诉你“差多少”原始日志才会告诉你“差在哪”和“为什么差”。另一个小建议是分层报告。不要只给一个总分把感知、推理、规划、闭环执行四类分数拆开看。一个总分排名第一的模型很可能只是感知分拉满规划能力一塌糊涂一个总分不高的模型也可能在规划子项上才是真正值得继续投入的方向。评测基准的意义不是制造排名而是给能力画像。Plan-Bench帮我做到的就是让“会看不会做”从一句模糊的直觉变成了一组可以随时引用的数字。如果非要总结一句对标题提问的个人回答那大概是现有的VLM离“在具身世界中真正推理与规划”还有明显距离但它们也不是完全没有规划能力只是这种能力还非常脆弱、非常依赖结构化的交互设计。Plan-Bench把这个距离精确地标了出来剩下的路就是每一个做模型和做应用的人自己去填了。