最近具身智能圈的讨论热度有一多半是由一家公司的一个百分比带起来的。Figure公布的泛化测试数据——56%——在群里刷了屏。这数字放在工业自动化项目里恐怕连验收标准都够不上但在具身智能语境下大部分人的第一反应不是“这么低”而是“怎么测出来的”。这话得解释一下。具身智能行业过去两年其实并不缺漂亮数字某模型抓取成功率95%某机器人任务通过率90%发布会PPT一个比一个亮眼。但这些数字大多有一个共同前提机器人在它训练过的环境里抓它训练过的物体执行它训练过的指令。这相当于开卷考试分数再高也说明不了真实世界的战斗力。而Figure这次之所以能引发热议关键不在数字本身而在它把考试形式改成了闭卷环境换了物体换了指令也换了最后端到端任务综合成功率56%。这篇文章想从一个从业者的视角把这个56%背后的评测逻辑、具身智能泛化验证的难点以及这套新标尺对整个产业链和从业者的影响拆开揉碎讲清楚。无论你是做算法、做系统、做数据还是准备转行进这个行业下面这些内容大概率能用上。1. 56%不只是个数字它把泛化从口号变成了考纲1.1 泛化验证到底考什么从“会做这道题”到“会做这类题”首先得把概念对齐。传统机器人工程里的验证测试的是一个系统在固定工况下的动作稳定性。比如一个码垛工作站托盘尺寸固定、纸箱尺寸固定、节拍固定验收只看两点节拍达不达标、稳定性达不达标。这种验证解决的是“可重复性”问题它默认环境是可工程化的把一切变量降到最低让动作百分之百复现。具身智能agent的验证逻辑完全不同。它的目标是同一个模型能放进不同家庭、不同仓库、不同工位面对的不是固定型号的纸箱而是无数种形状、材质、颜色、姿态的物体指令也可能是口语化的自然语言。所以泛化验证考的不是“对已知工况的重复精度”而是“对未见工况的适应能力”。这就像学生考试。传统考法是题库里抽题学生刷过原题就拿高分泛化考法是换一套从没做过的新题但考察的知识点确实是考纲要求掌握的能力。两者都在考但后者才真正说明学生学会了没有。56%这个分数放在闭卷新题面前其实已经是一个不算低的起点但更重要的不是这个分数而是这种考法本身。具体到Figure这轮测试公开信息里能还原出的评测设计大致是这样的在多个未见过的室内环境里摆放训练数据中没有出现过的日常物体用开放描述的自然语言下指令要求机器人完成搬运、摆放、收纳之类的端到端任务。这里的关键词是“三个没学过”没学过的场景、没学过的物体、没学过的指令表述。三个维度同时变化才能叫泛化验证。1.2 三重变量同时拉开才能逼出真实水平我帮大家把这种评测设定拆成一个矩阵会看得更清楚。变量维度训练阶段泛化测试阶段环境固定工作台、固定光照、固定背景陌生室内环境光照、遮挡、台面材质均变化物体训练集中出现过的物体训练集外物体形状、纹理、刚度、尺度均有差异指令固定模板或同义改写受限开放口语描述语序、措辞、语言都可能变化只看这张矩阵你会发现单换其中一个维度很多系统都能扛住。比如只换光照深度学习模型对光照扰动已经有不错的鲁棒性只换物体如果模型在大量语义数据上预训练过也能通过视觉语言信息推断出陌生物体的可抓取部位只换指令表达大语言模型的语义理解能力也足以处理。真正难的是三个维度一起换。环境一变光照和背景影响视觉特征物体一变抓取点、夹爪力度、提起方式全要重新推理指令一变模型要先把自然语言正确映射到机器人的动作空间。任何一环跟不上端到端任务就失败。这个“三变量同时拉开”的设计是这轮测试最有价值的地方它把很多模型在单维度测试里隐藏的问题全部逼了出来。1.3 为什么以前那些“抢眼数字”参考价值要打折扣过去两年圈内其实形成了不少默认的成功率数字。这里我不点名具体产品只说共性不少模型在自有数据集上宣称90%以上的任务成功率。这些数字不是假的但参考价值相当有限原因藏在三个细节里。第一测试环境与训练环境存在分布重合。很多数据集是同一个团队在同一间实验室里采集的所谓验证集、测试集只是同一分布里的随机切分。物体可能从没在画面里同框出现过但它们的材质、光照、背景纹路早就被模型记住了。这种测试测的是记忆不是泛化。第二分模块评估掩盖了系统级损失。有的团队分别报告视觉识别准确率98%、抓取规划成功率95%、运动控制成功率97%听起来每个环节都很强但端到端任务成功率可能不到70%。因为98%乘95%乘97%大约是90%再加上中间每个环节的误差放大最后真实成功率远低于任何一个单项。第三成功判定标准模糊。抓起来了算成功还是放到目标位置才算放偏了算不算允许几次重试这些口径差异能让同一个系统测出天差地别的两个数字。我曾见过两个团队用几乎一样的模型一个报85%另一个报52%差别主要就在判定口径上。Figure这个56%并不是说它就是行业最强水平而是它首次把“盲测、闭卷、端到端”这几个条件同时摆在了台面上。以后谁再报成功率都得解释清楚自己的判定口径和数据集切分方式。从这个意义上讲56%不是一张成绩单它是一份新考纲。2. 泛化难关具体卡在哪从sim2real到系统误差放大2.1 sim2real的鸿沟仿真里的95分真机上不一定及格做具身智能的人对sim2real仿真到真机迁移这个词不会陌生。几乎每个团队在开发初期都会选择先在仿真环境里验证算法因为仿真便宜、安全、可并行。但等到把模型部署到真机上时大家都会经历一次“成绩缩水”。为什么缩水这么严重我拆三层讲。第一层是视觉层面的偏差。仿真渲染出来的深度图和RGB图实在是太“干净”了。物体边缘锐利、材质参数统一、光照均匀而真机上的深度相机经常拍到黑边、飞点玻璃和反光表面直接透光在弱光环境里彩色图全是噪点。模型在仿真里学到的特征到了真机上找不到对应关系。第二层是物理层面的偏差。仿真里的摩擦系数、接触刚度、重心位置都是人为设置的固定值真实物体的质量分布、表面摩擦、形变特性千差万别。一张餐巾纸叠起来的手感一个装满水的马克杯的重心变化这些物理细节很难在仿真里精确建模。第三层是执行层面的偏差。机械臂控制存在延迟、抖动、标定误差同一个指令在仿真里执行得精准优雅到了真机上可能因为几毫米的手眼标定误差直接撞到物体。行业里应对sim2real的主流手段是域随机化在仿真里随机改物体颜色、材质、光照、物理参数让模型见过更多变化从而学到与具体域无关的特征。这套方法的有效性已经得到大量验证但它本质上是“用更大的仿真覆盖去对冲未知”不可能覆盖真实世界的无限长尾。这也是为什么域随机化做到一定程度后再加随机范围泛化收益会明显递减。2.2 长尾世界是一场开卷考不出来的课说一个很多非从业者忽略的事实真实世界是极端长尾的。日常场景里大部分需求可能集中在少数标准物体上比如杯子、盘子、瓶子、书本。但真正拉开产品体验差距的恰恰是那些非标物体一个用了十年的老式开瓶器、一个手工捏制的陶瓷摆件、一把餐厅后厨常见的硅胶铲。这些物体的共性是训练数据里几乎没有但用户默认机器人应该会处理。因为它们太日常了日常到用户根本不会觉得自己提了“超纲”要求。面对这些物体机器人靠什么泛化核心是靠语义推理。模型虽然没有见过硅胶铲但如果它在海量图文数据上预训练过它知道铲子的功能、手柄的结构、硅胶材质偏软偏滑。它可以把这些常识迁移到当下的视觉输入上识别出“手柄”是可抓取的部位推断出抓取硅胶需要更柔和的力度。这种推理能力靠的是预训练模型里沉淀的“对世界的常识”而不是靠标注数据里的“对这个物体的例程”。这也是为什么我始终认为具身智能agent的泛化本质是“理解”不是“记忆”。堆数据能解决的是让模型记住更多物体但永远解决不了它不认识全部物体的问题。能解决这个问题的是让模型学会推理。2.3 端到端闭环里小误差是怎么滚成大雪球的最后这个原因是系统级的建议每一个被泛化问题折磨过的团队都认真想想。一个端到端具身智能系统大致链路是视觉感知→目标定位→语义理解→动作规划→运动执行。每个环节都会引入误差。感知环节对目标的位姿估计可能有1到2厘米的偏差语义理解环节可能把“旁边”理解成“上面”规划环节生成的抓取点可能偏离质心执行环节机械臂末端可能还有抖动。关键是这些误差不是独立的它们会在链条里逐级叠加甚至互相放大。我举个常见的例子。机器人要“把杯子放到托盘上”感知模型把杯子位置估计偏了2厘米轨迹规划器按这个偏差位置规划抓取末端执行到位后真实杯子并不在夹爪中心夹爪闭合时只碰到杯壁于是把杯子怼倒了。杯子倒了之后下一个环节——目标托盘——如果也被遮挡导致位姿估计偏移那即便夹爪没有碰掉杯子放置动作也会落空。这类问题的悲剧在于单纯提升任何一个单点模型精度都不见得能解决端到端任务成功率。因为每个环节都在长尾条件下出错错误会不断组合出新形态。这也是为什么我在团队里一直强调泛化验证必须看端到端任务成功率而不是分模块指标。你不是在优化一台机器你是在驯化一个闭环系统。3. 落地一套能用的泛化验证方法栈3.1 评测层级先拆任务再选指标讲完痛点说说解法。我自己的经验是面对泛化验证第一步不是急着训练模型而是先定义“怎么算通过”。这套定义需要按层级拆开否则团队会陷入“平均一下看起来还行”的幻觉。建议按四个层级设计评测体系感知层目标检测、分割、位姿估计的准确率重点看训练集外物体的召回率和位姿误差中位数。操作层单次抓取成功率、抓取后搬运稳定性重点看首次尝试成功率而不是多次重试的最终成功率。任务层端到端任务成功率比如“把A放到B”“把指定物品收纳进柜子”任务是完整的感知-决策-执行闭环。系统层连续完成N个任务的通过率、长时间运行稳定性、异常恢复能力。四个层级的关系是分层指标用来诊断瓶颈端到端指标用来对外定级。如果一个系统端到端成功率只有50%你需要看分层指标找出是感知偏了、规划错了、还是执行抖了但如果对投资人或客户汇报永远只讲端到端数字因为分模块数字再漂亮也不能保证现场不翻车。3.2 数据切分泛化测试最怕数据泄漏泛化验证失败案例里最常见的不是模型能力不足而是评测集划分不严谨导致“假泛化”。我见过有的团队拿同一批数据随机切了个训练集和测试集然后跑出一个很高的“泛化准确率”。这种切法的致命问题在于测试集里那些物体哪怕没有和训练集物体出现在同一张图里训练时也见过它们各自的纹理、颜色、形状。模型记住的是物体本身不是物体的概念。真正有效的泛化评测至少要保证三个层面的隔离。物体隔离。训练集的物体集合和测试集的物体集合完全不重合。这意味着团队需要额外准备一批“封印物体”这批物体从采集、标注到训练全程都不许模型看专门留到最终评测时才拿出来。环境隔离。训练时用了A房间和B房间的采集数据测试时就选C房间甚至换一个不同装修风格、不同光照条件的环境。更严格的做法是留一环境评测把整个场景从训练数据里拿掉看模型从其他几个场景学到的能力能不能迁移过去。指令隔离。训练阶段的指令大多是人围着机器人说“把杯子放到架子上”这种直白指令测试阶段就要换成“帮我把桌上那个红色的杯子挪到左边那个木架子上”或者换成英文指令考察语义理解泛化。另外建议所有团队建立“盲测集黑盒制度”最终评测集由不参与模型训练的人管理日常开发迭代中谁都不能碰。等模型训练到候选状态再由管理盲测集的同事跑分。虽然这个流程麻烦但我见过太多团队因为开发时看了一眼测试数据导致评测结果失真。3.3 判定口径怎么算成功比成功率本身更重要最后说一下最容易被低估的环节成功判定的边界定义。一个系统的成功率到底是多少很大程度上取决于你如何认定“成功”。我给大家看三种常见口径判定口径含义对数字的影响抓取成功夹爪闭合后物体离地即算成功数字最容易做高但不代表任务完成放置成功物体被放到目标区域附近即算成功中等口径目标区域允许多少误差需定义稳定放置成功物体到达目标区域且夹爪松开后物体保持不倒、不出界最严格最能反映真实任务能力同一个系统用第一口径可能测出85%用第三口径可能不到50%。这中间的差距不是模型能力而是评测标准。我建议任何团队在发布泛化成功率时都附一份评测说明书至少写清楚是否首次尝试是否会记录重试次数成功是否需要满足位姿约束比如杯子立着放还是允许躺着是否允许人为干预失败case是计入分母还是剔除。没有这份说明书的成功率数字基本无法横向比较。4. 新标尺之下产业链和从业者的应对4.1 三种应对路线堆数据、加约束、建验证Figure把56%这个锚点立在行业里之后我观察到的应对方式大致有三类。第一类是数据驱动派也是最传统的一派。他们认定泛化不足是数据不够的锅于是扩大遥操作采集规模、增加场景数量、扩充物体库。这个路线的确有效但边际效应非常明显。机器人数据的采集成本远比文本和图片高一条高质量轨迹数据可能要投入大量真机时间而且数据质量参差不齐。堆到一定规模之后再增加数据的泛化收益会快速衰减。第二类是模型约束派。他们在模型里注入物理常识和结构化先验比如让模型生成动作时考虑物体重心、让规划模块强制避开不可行区域、在输出层加上运动学约束。这类做法能有效卡住“明显不合理”的动作但前提是团队对系统集成有很强的掌控力并且牺牲一定的通用性。第三类是验证驱动派。他们不急着加数据或加约束而是先把泛化测试集建起来让每次模型迭代都有可比较的分数用评测结果反推技术路线。这个做法短期见效慢但长期最稳定。我个人的选择也是这一派——先有标尺再有优化否则你根本不知道自己在往哪个方向优化。4.2 上下游连锁反应数据、仿真、硬件都在换逻辑这套泛化新标尺的冲击波不只在算法团队内部还会传导到整个产业链。数据服务商首当其冲。以前数据行业卖的是“干净量大”一套场景拍到天荒地老。以后真正值钱的是“多样性”跨场景、跨物体、跨任务、跨语言的组合多样性。一个包含200个场景各10条轨迹的数据集很可能比一个场景2000条轨迹的数据集更能提升泛化能力。数据标注的重心也会从“画框”转向“描述任务语义和约束”。仿真厂商也在被倒逼。当厂商们发现客户开始拿“新场景测试”当验收标准他们对程序化场景生成、材质多样性、物理真实感的重视程度会大幅提升。未来仿真平台的核心卖点不再是画面多好看而是能不能快速生成“看起来不像同一个地方”的大量场景。硬件层面泛化需求会推动末端执行器升级。固定场景的工业夹爪可能不太受影响但面向家用、商用的机器人柔性夹爪、多指手、带力控的手腕会越来越重要。因为在泛化测试里物体可能是硬的玻璃瓶、软的布料、易碎的生鸡蛋末端执行器的适应性和力感知能力决定了算法策略的上限。4.3 从业者和准备入行的人接下来该补哪些课最后说点对人的建议。最近很多朋友问我具身智能学习路线到底该怎么排。我给的答案和两年前不太一样了因为泛化验证现在成了一项核心能力面试官也开始围绕这个方向问细节。第一层先把基础模型理解透。Vision-Language-Action模型、Diffusion Policy、世界模型这些方向至少要能讲清楚它们的输入输出、训练方式和各自局限。面试时如果只能报出名字基本是送分题。第二层亲手跑通一个真机或仿真闭环。不用复杂一个抓取demo就够但是要完整记录训练集和测试集的表现差异亲身体会一次sim2real gap是怎么出现的。这个项目经历比你看二十篇论文都更能说明问题。第三层主动设计一个小型泛化测试。哪怕只有三个场景、五种物体你也要学会搭建盲测集、定义成功标准、统计失败原因。很多人忽略的是泛化验证不是把准确率打印出来就完了而是要把每一个失败case的失效模式记录下来这些case才是改进模型的关键线索。第四层往操作系统层面延伸思考。具身智能agent要进入实际场景一定绕不开调度、记忆、安全、多机协同这些系统能力。泛化能力不是孤立存在的它要和这些模块配合才能变成可用的产品。如果你能回答“模型中台、任务调度、在线学习这些模块如何支撑泛化能力提升”在面试当中就已经超出大多数候选人。这里补充一个我们团队内部的实用习惯每次评测失败case都按照“感知问题、规划问题、执行问题、任务理解问题”四类归档。一个月后翻出来看你会发现大多数失败都集中在两三个根因上解决掉它们泛化分数能肉眼可见地涨一截。最后聊一点个人体会。我做具身智能系统这么久最大的感受是这个行业不缺漂亮的Demo缺的是敢把模型放到陌生环境里跑、并且愿意把失败case摊开给人看的团队。56%这个数字恰恰是这种坦白。它让我想起以前做工程项目时那种“现场永远是另一个毛病”的无奈。仿真、实验室、演示现场永远是三个世界。但反过来想泛化验证的价值也正在于此每暴露一个失败就多了一个确定要修的bug。一批批这样修下去分数一定会涨。而整个行业如果都能习惯用这种盲测逻辑说话那具身智能离真正走进家庭和商铺也就不远了。