在具身智能领域“泛化”是最近一年出现在创始人沟通、产品路标、投资人提问和论文标题里频率最高的词。所谓泛化指的是模型把训练阶段已经掌握的能力稳定迁移到未见过的物体、未见过的场景、变化的光照、不同位姿甚至不同任务上的能力。当 29 位具身智能 CEO 围绕“泛化”展开讨论时并没有聊成一场哲学对话。相反讨论里出现了大量可落地的共识也在端到端训练、数据采集、仿真迁移和人形机器人路线这些具体问题上出现了明显的分歧。对于正在做具身智能方向选型的技术团队以及研究多模态大模型如何落地到物理世界的开发者来说这场讨论的价值不在于某一句具体结论而在于它把“泛化”拆成了一系列可以从数据、模型、仿真、硬件和评测维度分别解释的工程问题。本文会按这个顺序把共识、分歧和技术实现路径放在一起梳理最后给出可以直接用在工作中的排错清单和学习路线。1. 先理解具身智能里的“泛化”到底指什么1.1 泛化不是单一能力而是跨维度稳定输出泛化这个词听起来抽象但在具身智能里它有一个非常具体的判断标准模型在训练时见过物体 A 在场景 B 中抓取部署时能不能在未见过的物体 C、场景 D 中完成同样动作。如果只看训练集内指标很多模型都能做到 90% 以上的成功率一旦物体形状、材质、桌子高度、光照角度发生一点点变化成功率可能直接掉到 30% 以下。这种“训练时是学霸部署时是路痴”的现象就是泛化能力不足的直接表现。在具身智能场景下泛化至少包含以下维度泛化维度具体含义典型测试方式物体泛化面对训练中未见过的物体完成抓取、操作训练用 A/B/C 物体测试用 D/E/F 物体场景泛化在未出现过的桌面、货架、地面上完成动作训练在一个房间测试换到另一个房间光照与纹理泛化不同亮度、阴影、材质和表面纹理下保持稳定改变灯位、曝光、物体表面贴图位姿与视角泛化物体任意摆放、相机任意角度下仍然可操作改变物体初始姿态和相机高度任务泛化从单一动作扩展到组合动作或新任务从“抓取”扩展到“抓取后放到目标位置”这里要特别解释一个常见的误解很多人把泛化等同于“模型参数大”。实际上模型的容量只决定了它理论上能记住多复杂的规律能否泛化还取决于数据覆盖度、训练策略和评测方式。即使把模型从 7B 换成 70B如果训练数据只覆盖一种光照和一种机械臂部署到新环境时同样会退化。1.2 泛化能力差的典型现象看似学会了换场景就失效团队在复现具身智能抓取实验时最容易遇到的退化现象有几种。第一种是换物体失败训练时使用红色杯子测试时换成透明玻璃杯模型要么检测不到要么抓取位置明显偏移。第二种是换场景失败机械臂在实验室的固定桌面上成功率很高搬到仓库、厨房或者户外后背景复杂度和地面反光会极大干扰感知模型。第三种是换任务失败模型学会了“拿起物体”这个动作但把它放到目标区域时目标位置一变化整个动作序列就会解体。这些现象的本质是同一个问题模型学到的是训练数据里的表象相关性而不是物理世界的稳定结构。比如它可能通过“杯子把手朝向右侧”判断抓取点而不是通过杯子的三维几何、质心和表面摩擦特性判断。在这些问题上CEO 们的讨论有一个很少被质疑的共识真正有用的泛化必须建立在多模态感知和动作空间同时泛化的基础上。感知模块只输出物体的类别和位置还不够还需要准确的形状、姿态、材质和力学信息动作模块则要在这些信息变化后仍然输出合理的轨迹。1.3 为什么泛化问题在机器人里比“大模型生成文本”更复杂大语言模型的泛化表现为“没见过的组合问题也能回答”这种泛化发生在符号空间里错误代价相对低而且可以通过文字 prompt 快速修正。机器人的泛化则发生在物理空间里一个错误动作可能导致碰撞、跌倒或夹坏物体无法通过简单的重试绕开。机器人还需要在实时反馈中调整动作传感器噪声、机械臂关节延迟、物体滑动这些因素都会放大泛化失败的影响。另一个复杂之处是机器人泛化背后不是一个模型在单独工作而是感知、推理、规划、控制等多个环节串联。任何一个环节在分布外数据上失效整个任务都会失败。这也是为什么一部分 CEO 主张用端到端模型把所有环节压缩成一个大网络另一部分则坚持保留模块化接口和中间表征。两种路线本质上是“用更多数据换取更少误差累积”和“用人工先验换取更多可控性”之间的权衡后文会专门展开。2. 29位CEO的四个共识本质上是行业集体踩坑后的结论2.1 共识一泛化首先被数据瓶颈卡住而不是模型容量在 29 位 CEO 的讨论中最先形成共识的领域是数据。多位 CEO 都承认过去低估了具身智能数据的获取难度。大语言模型可以直接从互联网文本里获得海量数据机器人动作数据则必须从物理世界中采集要么通过遥操作由人演示要么通过强化学习在仿真环境中探索要么依赖固定的工业工艺流数据。三种方式各自有短板遥操作数据质量高但采集成本高、多样性和规模受限仿真数据规模大但存在 sim-to-real 域差距工业现场数据真实但任务单一、难以复用。所以在数据这一层CEO 们的基本共识是泛化首先是被数据覆盖度和数据质量卡住的当数据中缺少某类物体、姿态、光照或任务时再大的模型也只能靠强行记忆来弥补无法真正泛化。这也解释了为什么“具身智能数据清洗”会成为社区中的高频词。数据清洗不是简单去掉空帧和错误标注而是要系统性地识别数据分布中缺失的高价值区间并主动扩充这些区间。2.2 共识二仿真训练与 sim-to-real 是绕不开的环节另一个共识是纯靠真实数据做训练很难在成本可控的前提下达到足够的泛化覆盖度。原因是真实世界操作任务的分布是长尾的日常生活中会有各种材质的物体、不同的桌面高度、不同的光照如果每一种组合都靠遥操作采集数据成本无法收敛。因此仿真环境在具身智能里的地位变得越来越核心几乎所有面向多场景泛化的团队都会把仿真数据作为训练数据的重要组成部分。但这里存在一个关键边界仿真生成的数据并不天然等同于真实世界的分布。常见做法是域随机化也就是在训练时随机改变材质颜色、摩擦力、重力、光照、机械臂参数让模型被迫学习与具体外观无关的稳定策略。CEO 们的共识是sim-to-real 不能只在实验结束后做一次而是必须嵌入到数据生成、模型训练和真机测试的循环中先在仿真中确认策略稳定再上真机再把真机失败样本加入训练集重复迭代。2.3 共识三多模态大模型正在改写泛化的实现方式几乎所有 CEO 都认同多模态大模型尤其是视觉-语言-动作模型VLA改变了具身智能泛化的实现方式。传统机器人流程里感知、规划、控制是分开优化的每个环节对分布外数据的适应能力都要单独做处理。而 VLA 模型将视觉输入、语言指令和动作输出放在同一个网络里可以用自然语言描述把不同任务经验关联起来。比如一个模型同时接受“抓住红色杯子”和“把杯子放进洗碗机”的指令训练语言表征会让它在面对未见过的新指令时复用已经学到的物体识别和操作能力。不过共识限于“大模型方向是对的”具体怎么做仍然存在分歧。模型参数量、训练数据规模、动作空间设计这些细节不同团队有完全不同的选择。这也正是后文“路线分歧”要展开的内容。2.4 共识四泛化评测还没有统一标准是行业共同短板让 29 位 CEO 形成高度共识的另一个话题是评测。现在行业里缺少一套公认的、可对比的泛化能力评测基准。每个团队都在自己的机器人、自己的数据集、自己的任务难度上报告指标外部很难判断一个模型是否真的泛化还是只是对特定测试集过拟合。这里要注意评测标准缺失带来的问题不只是“无法横向比较”更严重的是它会让团队在内部选型时做出错误判断。如果评测集与训练集分布太接近模型的真实泛化能力会被高估如果评测任务定义不清晰则可能让模型把任务当成模板匹配问题来解决表面指标很高部署后立刻失效。所以后续第 4 章会专门给出一套可以在团队内部落地的多维评测框架。3. 路线分歧技术选择的背后是成本和场景约束不同3.1 端到端模型 vs 模块化管道端到端路线把视觉输入、语言指令直接映射为关节动作或末端位姿序列好处是减少了模块间的误差累积模型有潜力学到跨任务共享的表征。问题在于端到端模型的训练依赖大量高质量专家轨迹且一旦出现错误排查时很难定位到底是感知、规划还是控制的问题。模块化管道则保留感知、规划、控制的分层结构中间可以插入运动规划器、障碍物检测和紧急停止等安全逻辑。它的优点是可控、可解释、容易调试缺点是每个模块都要单独优化模块之间的接口会丢失信息导致整体泛化能力受限于最弱一环。两者之间还存在折中方案把感知模块做成大模型控制部分继续使用传统 MPC 或运动规划器这也是目前不少落地团队的实际选择。3.2 通用人形机器人 vs 专用形态在硬件形态上CEO 们的分歧很明显。一部分认为只有人形或双足形态才能覆盖足够多的场景泛化的最终目标是让机器人在人类社会环境里像人一样操作工具和移动另一部分认为在数据和模型都没有成熟到通用之前单臂、双臂、轮式底盘这些专用形态更容易在垂直场景里实现可控的泛化。从工程角度看硬件形态直接决定了动作空间和任务泛化的范围。人形机器人有两条腿和两条手臂动作空间巨大需要的数据和算力也成倍增长而一个固定在桌面上的单臂任务空间被约束在有限区域内同样的训练样本可以获得高得多的成功率。CEO 们的分歧不在于“长期要不要做人形”而在于“当前阶段能不能用有限的成本把泛化解决到可商用的水平”。3.3 自研 VLA vs 调用大模型做任务拆解在模型策略上有两条明显不同的路线。一条是自研或微调视觉-语言-动作大模型直接输出动作优势是可以针对自己的机器人本体进行动作空间优化长期积累模型能力劣势是训练成本高团队需要同时具备数据、算力和评估能力。另一条是使用通用多模态大模型负责场景理解和任务拆解把高层任务分解成子步骤再交给底层技能库执行。后者的落地速度更快但决策是否稳定依赖底层技能库的覆盖度且中间链路长很容易在大模型“自信地给出错误计划”时失控。这两条路线并不是非此即彼的关系。实际项目中可以先让通用大模型负责任务规划再用少量专家轨迹训练一个专用的动作模型负责执行但 CEO 讨论中出现分歧往往是因为两家团队对“数据获取速度”和“团队工程能力”的假设不同而不是模型结构上真的不可调和。3.4 分歧的深层原因同样谈泛化定义并不一样如果只看表面CEO 们似乎在一个词上争吵但深入看分歧的根源是对“泛化到哪一步”的定义不同。一类团队定义的泛化是“在固定本体上对同一类任务的物体和场景变化保持稳定”他们追求的是可量化的工业级成功率另一类团队定义的泛化是“在任意本体上理解任意新任务并完成操作”他们追求的是接近人类的行为灵活性。这两种定义对应完全不同的技术指标前者看任务成功率、失败率、平均操作时间后者看任务覆盖范围、全新指令理解成功率、跨本体迁移能力。如果不先把定义对齐任何关于技术路线的争论都得不到结论。这也是普通团队在借鉴这些讨论时最应该先做的一件事明确自己到底需要哪一种泛化。4. 泛化能力到底怎么测从评测维度到验证清单4.1 五个维度拆解泛化物体、场景、光照、位姿、任务泛化评测需要把“泛化”拆成可测的维度常见做法是分别控制变量只改变一个维度观察任务成功率的变化。比如物体泛化测试中训练集里放 A、B、C 三种物体测试集准备 D、E、F 三种未出现过的物体保持场景、光照、位姿不变比较成功率。如果成功率下降明显说明模型对物体的形状、质感和类别信息没有学到稳定的表征。场景泛化测试则是换房间、换桌面材质、换背景光照泛化测试调节光线角度和亮度位姿泛化测试改变物体的初始姿态、相机高度和视角任务泛化测试从单步动作扩展到多步组合。实践中很难一次把五个维度全部做全但至少要有一个可重复的“留出法”流程训练集和测试集在数据采集时就故意去耦合避免因为采集人员、设备参数或相机位置不同导致隐蔽的数据泄漏。4.2 一个可落地的泛化评测流程一个最小可落地的评测流程如下先定义任务用语言模板固定指令格式例如“将 {物体} 放到 {目标区域}”。再划分数据训练集使用 10 类物体、2 个场景、固定光照待测集使用另外 5 类物体、2 个新场景、1 组新光照。准备评测配置每个任务跑至少 20 次记录成功、失败、超时和人工干预次数。计算分组指标分别统计物体组、场景组、光照组的成功率不要只算总平均分。保留失败样本每个失败样本保存图像、语言指令、动作序列、机械臂日志用于后续分析。下面是一个评测配置文件的示例用于固定每个任务组的定义和重复次数eval_task_groups: - group_name: object_generalization command_template: 将 {object} 放到 {goal_region} test_objects: [杯子_透明, 圆珠笔, 玩具车, 手机壳, 纸盒] goal_regions: [目标点_A, 目标点_B] num_trials_per_object: 20 light_conditions: [fixed] camera_poses: [fixed] - group_name: scene_generalization command_template: 将 {object} 放到 {goal_region} test_objects: [杯子, 盘子] scenes: [厨房台面, 会议室桌面] num_trials_per_scene: 20 light_conditions: [fixed] camera_poses: [fixed]这个文件的价值在于把评测从“临时写一段脚本”变成“可重复的工程配置”。每次更新模型后跑同一套配置结果就能横向对比评测标准一旦固定下来团队内部关于“泛化是否变好”的争论也会少很多。注意评测集的数据在项目开始时就要和训练集分开管理。不要用同一批采集数据既做训练又做测试否则任何模型都会表现出虚高的泛化成绩。4.3 常用指标和它们各自掩盖的问题泛化评测常用的指标包括任务成功率、平均完成任务时间、平均干预次数和轨迹平滑度。成功率是最直观的指标但如果只报告总成功率会掩盖某一个维度的明显退化。平均完成时间只对成功样本有意义模型失败时尽早停止反而更安全。干预次数可以反映系统在真实环境下需要人工介入的频率但对自动化评测要求较高。还有一个容易忽略的问题评测过程本身需要有人或规则来判定“成功”。判定标准不同会直接影响指标。比如“放到目标区域”里目标区域是 5 厘米半径还是 20 厘米半径成功率会完全不同。建议在评测配置里把判定条件写清楚同时在发布结果时保留最原始的轨迹数据和失败样本这样即使后续判定标准调整也能重新统计。5. 提升泛化能力的工程路径数据、仿真、模型、硬件四层5.1 数据侧清洗、配比和多样性采样数据清洗是提升泛化能力的第一道关卡也是最容易被低估的一步。原始遥操作数据里往往存在几类问题动作不连续、末端执行器抖动、任务定义不一致、采集人员疲劳导致的无效演示。如果直接把这些数据送入训练模型会学到噪声和错误的时序依赖。一个实用的清洗流程包括以下步骤检查轨迹完整性剔除开始和结束状态不符合任务定义的轨迹。检查动作连续性对关节角度或末端位姿做差分超过阈值的帧标记为异常人工复核。统一标注格式把自然语言描述模板化避免同一任务出现多种语义表达式。平衡类别分布将高频物体和低频物体的样本比例控制在一个合理范围避免模型偏向少数类。移除近似重复样本用特征向量去重避免大量相似轨迹让模型过拟合。下面是一个简单的 Python 清洗脚本思路用于过滤轨迹中动作变化异常的帧import numpy as np def filter_unstable_frames(trajectory, joint_vel_threshold0.8): trajectory: 每行是一个时间步包含关节角度或末端位姿。 返回: 保留的有效帧索引列表。 if len(trajectory) 3: return [] velocity np.abs(np.diff(trajectory, axis0)) unstable_frames np.where(velocity.max(axis1) joint_vel_threshold)[0] valid_frames [] for i in range(len(trajectory)): if i - 1 not in unstable_frames and i not in unstable_frames: valid_frames.append(i) return valid_frames这段脚本的价值在于它把“动作异常”变成一个可量化的阈值判断。实际项目中可以把这个逻辑接入数据流水线自动标记疑似异常帧再由人工抽样复核。5.2 仿真侧用域随机化拉近 sim 和 real 的距离仿真数据的核心问题不是数量而是分布距离。域随机化的思路是在训练时让仿真环境里的材质、摩擦、光照、重力、机械臂参数在一定范围内随机变换迫使模型学习一个对参数不敏感的策略。典型配置如下domain_randomization: enable: true randomize: object_material: [metal, plastic, rubber, wood] object_color: true friction_coefficient: range: [0.3, 1.2] light_intensity: range: [500, 3000] table_height: range: [0.70, 0.90] robot_arm_joint_offset: range: [-0.02, 0.02]配置生成后每次环境复位时从范围内随机采样参数而不是固定使用一成不变的环境。这样做的一个直接收益是模型看到的外观变化足够多后它会逐渐放弃依赖颜色、纹理和固定高度这些无关变量转而依赖物体的几何、位姿和相对位置。要注意的是随机范围不能无限大。范围过大会让任务难度超过样本容量的表达上限训练无法收敛范围过小则泛化作用有限因此需要在实验中对每个参数单独做消融。5.3 模型侧统一动作空间、动作头和混合训练模型层面提升泛化要解决的是“同一套参数如何表达多个任务”的问题。一个常见的做法是让不同任务共享感知编码器和语言编码器 具身智能泛化能力如何提升？一场29位CEO讨论总结的工程路径
在具身智能领域“泛化”是最近一年出现在创始人沟通、产品路标、投资人提问和论文标题里频率最高的词。所谓泛化指的是模型把训练阶段已经掌握的能力稳定迁移到未见过的物体、未见过的场景、变化的光照、不同位姿甚至不同任务上的能力。当 29 位具身智能 CEO 围绕“泛化”展开讨论时并没有聊成一场哲学对话。相反讨论里出现了大量可落地的共识也在端到端训练、数据采集、仿真迁移和人形机器人路线这些具体问题上出现了明显的分歧。对于正在做具身智能方向选型的技术团队以及研究多模态大模型如何落地到物理世界的开发者来说这场讨论的价值不在于某一句具体结论而在于它把“泛化”拆成了一系列可以从数据、模型、仿真、硬件和评测维度分别解释的工程问题。本文会按这个顺序把共识、分歧和技术实现路径放在一起梳理最后给出可以直接用在工作中的排错清单和学习路线。1. 先理解具身智能里的“泛化”到底指什么1.1 泛化不是单一能力而是跨维度稳定输出泛化这个词听起来抽象但在具身智能里它有一个非常具体的判断标准模型在训练时见过物体 A 在场景 B 中抓取部署时能不能在未见过的物体 C、场景 D 中完成同样动作。如果只看训练集内指标很多模型都能做到 90% 以上的成功率一旦物体形状、材质、桌子高度、光照角度发生一点点变化成功率可能直接掉到 30% 以下。这种“训练时是学霸部署时是路痴”的现象就是泛化能力不足的直接表现。在具身智能场景下泛化至少包含以下维度泛化维度具体含义典型测试方式物体泛化面对训练中未见过的物体完成抓取、操作训练用 A/B/C 物体测试用 D/E/F 物体场景泛化在未出现过的桌面、货架、地面上完成动作训练在一个房间测试换到另一个房间光照与纹理泛化不同亮度、阴影、材质和表面纹理下保持稳定改变灯位、曝光、物体表面贴图位姿与视角泛化物体任意摆放、相机任意角度下仍然可操作改变物体初始姿态和相机高度任务泛化从单一动作扩展到组合动作或新任务从“抓取”扩展到“抓取后放到目标位置”这里要特别解释一个常见的误解很多人把泛化等同于“模型参数大”。实际上模型的容量只决定了它理论上能记住多复杂的规律能否泛化还取决于数据覆盖度、训练策略和评测方式。即使把模型从 7B 换成 70B如果训练数据只覆盖一种光照和一种机械臂部署到新环境时同样会退化。1.2 泛化能力差的典型现象看似学会了换场景就失效团队在复现具身智能抓取实验时最容易遇到的退化现象有几种。第一种是换物体失败训练时使用红色杯子测试时换成透明玻璃杯模型要么检测不到要么抓取位置明显偏移。第二种是换场景失败机械臂在实验室的固定桌面上成功率很高搬到仓库、厨房或者户外后背景复杂度和地面反光会极大干扰感知模型。第三种是换任务失败模型学会了“拿起物体”这个动作但把它放到目标区域时目标位置一变化整个动作序列就会解体。这些现象的本质是同一个问题模型学到的是训练数据里的表象相关性而不是物理世界的稳定结构。比如它可能通过“杯子把手朝向右侧”判断抓取点而不是通过杯子的三维几何、质心和表面摩擦特性判断。在这些问题上CEO 们的讨论有一个很少被质疑的共识真正有用的泛化必须建立在多模态感知和动作空间同时泛化的基础上。感知模块只输出物体的类别和位置还不够还需要准确的形状、姿态、材质和力学信息动作模块则要在这些信息变化后仍然输出合理的轨迹。1.3 为什么泛化问题在机器人里比“大模型生成文本”更复杂大语言模型的泛化表现为“没见过的组合问题也能回答”这种泛化发生在符号空间里错误代价相对低而且可以通过文字 prompt 快速修正。机器人的泛化则发生在物理空间里一个错误动作可能导致碰撞、跌倒或夹坏物体无法通过简单的重试绕开。机器人还需要在实时反馈中调整动作传感器噪声、机械臂关节延迟、物体滑动这些因素都会放大泛化失败的影响。另一个复杂之处是机器人泛化背后不是一个模型在单独工作而是感知、推理、规划、控制等多个环节串联。任何一个环节在分布外数据上失效整个任务都会失败。这也是为什么一部分 CEO 主张用端到端模型把所有环节压缩成一个大网络另一部分则坚持保留模块化接口和中间表征。两种路线本质上是“用更多数据换取更少误差累积”和“用人工先验换取更多可控性”之间的权衡后文会专门展开。2. 29位CEO的四个共识本质上是行业集体踩坑后的结论2.1 共识一泛化首先被数据瓶颈卡住而不是模型容量在 29 位 CEO 的讨论中最先形成共识的领域是数据。多位 CEO 都承认过去低估了具身智能数据的获取难度。大语言模型可以直接从互联网文本里获得海量数据机器人动作数据则必须从物理世界中采集要么通过遥操作由人演示要么通过强化学习在仿真环境中探索要么依赖固定的工业工艺流数据。三种方式各自有短板遥操作数据质量高但采集成本高、多样性和规模受限仿真数据规模大但存在 sim-to-real 域差距工业现场数据真实但任务单一、难以复用。所以在数据这一层CEO 们的基本共识是泛化首先是被数据覆盖度和数据质量卡住的当数据中缺少某类物体、姿态、光照或任务时再大的模型也只能靠强行记忆来弥补无法真正泛化。这也解释了为什么“具身智能数据清洗”会成为社区中的高频词。数据清洗不是简单去掉空帧和错误标注而是要系统性地识别数据分布中缺失的高价值区间并主动扩充这些区间。2.2 共识二仿真训练与 sim-to-real 是绕不开的环节另一个共识是纯靠真实数据做训练很难在成本可控的前提下达到足够的泛化覆盖度。原因是真实世界操作任务的分布是长尾的日常生活中会有各种材质的物体、不同的桌面高度、不同的光照如果每一种组合都靠遥操作采集数据成本无法收敛。因此仿真环境在具身智能里的地位变得越来越核心几乎所有面向多场景泛化的团队都会把仿真数据作为训练数据的重要组成部分。但这里存在一个关键边界仿真生成的数据并不天然等同于真实世界的分布。常见做法是域随机化也就是在训练时随机改变材质颜色、摩擦力、重力、光照、机械臂参数让模型被迫学习与具体外观无关的稳定策略。CEO 们的共识是sim-to-real 不能只在实验结束后做一次而是必须嵌入到数据生成、模型训练和真机测试的循环中先在仿真中确认策略稳定再上真机再把真机失败样本加入训练集重复迭代。2.3 共识三多模态大模型正在改写泛化的实现方式几乎所有 CEO 都认同多模态大模型尤其是视觉-语言-动作模型VLA改变了具身智能泛化的实现方式。传统机器人流程里感知、规划、控制是分开优化的每个环节对分布外数据的适应能力都要单独做处理。而 VLA 模型将视觉输入、语言指令和动作输出放在同一个网络里可以用自然语言描述把不同任务经验关联起来。比如一个模型同时接受“抓住红色杯子”和“把杯子放进洗碗机”的指令训练语言表征会让它在面对未见过的新指令时复用已经学到的物体识别和操作能力。不过共识限于“大模型方向是对的”具体怎么做仍然存在分歧。模型参数量、训练数据规模、动作空间设计这些细节不同团队有完全不同的选择。这也正是后文“路线分歧”要展开的内容。2.4 共识四泛化评测还没有统一标准是行业共同短板让 29 位 CEO 形成高度共识的另一个话题是评测。现在行业里缺少一套公认的、可对比的泛化能力评测基准。每个团队都在自己的机器人、自己的数据集、自己的任务难度上报告指标外部很难判断一个模型是否真的泛化还是只是对特定测试集过拟合。这里要注意评测标准缺失带来的问题不只是“无法横向比较”更严重的是它会让团队在内部选型时做出错误判断。如果评测集与训练集分布太接近模型的真实泛化能力会被高估如果评测任务定义不清晰则可能让模型把任务当成模板匹配问题来解决表面指标很高部署后立刻失效。所以后续第 4 章会专门给出一套可以在团队内部落地的多维评测框架。3. 路线分歧技术选择的背后是成本和场景约束不同3.1 端到端模型 vs 模块化管道端到端路线把视觉输入、语言指令直接映射为关节动作或末端位姿序列好处是减少了模块间的误差累积模型有潜力学到跨任务共享的表征。问题在于端到端模型的训练依赖大量高质量专家轨迹且一旦出现错误排查时很难定位到底是感知、规划还是控制的问题。模块化管道则保留感知、规划、控制的分层结构中间可以插入运动规划器、障碍物检测和紧急停止等安全逻辑。它的优点是可控、可解释、容易调试缺点是每个模块都要单独优化模块之间的接口会丢失信息导致整体泛化能力受限于最弱一环。两者之间还存在折中方案把感知模块做成大模型控制部分继续使用传统 MPC 或运动规划器这也是目前不少落地团队的实际选择。3.2 通用人形机器人 vs 专用形态在硬件形态上CEO 们的分歧很明显。一部分认为只有人形或双足形态才能覆盖足够多的场景泛化的最终目标是让机器人在人类社会环境里像人一样操作工具和移动另一部分认为在数据和模型都没有成熟到通用之前单臂、双臂、轮式底盘这些专用形态更容易在垂直场景里实现可控的泛化。从工程角度看硬件形态直接决定了动作空间和任务泛化的范围。人形机器人有两条腿和两条手臂动作空间巨大需要的数据和算力也成倍增长而一个固定在桌面上的单臂任务空间被约束在有限区域内同样的训练样本可以获得高得多的成功率。CEO 们的分歧不在于“长期要不要做人形”而在于“当前阶段能不能用有限的成本把泛化解决到可商用的水平”。3.3 自研 VLA vs 调用大模型做任务拆解在模型策略上有两条明显不同的路线。一条是自研或微调视觉-语言-动作大模型直接输出动作优势是可以针对自己的机器人本体进行动作空间优化长期积累模型能力劣势是训练成本高团队需要同时具备数据、算力和评估能力。另一条是使用通用多模态大模型负责场景理解和任务拆解把高层任务分解成子步骤再交给底层技能库执行。后者的落地速度更快但决策是否稳定依赖底层技能库的覆盖度且中间链路长很容易在大模型“自信地给出错误计划”时失控。这两条路线并不是非此即彼的关系。实际项目中可以先让通用大模型负责任务规划再用少量专家轨迹训练一个专用的动作模型负责执行但 CEO 讨论中出现分歧往往是因为两家团队对“数据获取速度”和“团队工程能力”的假设不同而不是模型结构上真的不可调和。3.4 分歧的深层原因同样谈泛化定义并不一样如果只看表面CEO 们似乎在一个词上争吵但深入看分歧的根源是对“泛化到哪一步”的定义不同。一类团队定义的泛化是“在固定本体上对同一类任务的物体和场景变化保持稳定”他们追求的是可量化的工业级成功率另一类团队定义的泛化是“在任意本体上理解任意新任务并完成操作”他们追求的是接近人类的行为灵活性。这两种定义对应完全不同的技术指标前者看任务成功率、失败率、平均操作时间后者看任务覆盖范围、全新指令理解成功率、跨本体迁移能力。如果不先把定义对齐任何关于技术路线的争论都得不到结论。这也是普通团队在借鉴这些讨论时最应该先做的一件事明确自己到底需要哪一种泛化。4. 泛化能力到底怎么测从评测维度到验证清单4.1 五个维度拆解泛化物体、场景、光照、位姿、任务泛化评测需要把“泛化”拆成可测的维度常见做法是分别控制变量只改变一个维度观察任务成功率的变化。比如物体泛化测试中训练集里放 A、B、C 三种物体测试集准备 D、E、F 三种未出现过的物体保持场景、光照、位姿不变比较成功率。如果成功率下降明显说明模型对物体的形状、质感和类别信息没有学到稳定的表征。场景泛化测试则是换房间、换桌面材质、换背景光照泛化测试调节光线角度和亮度位姿泛化测试改变物体的初始姿态、相机高度和视角任务泛化测试从单步动作扩展到多步组合。实践中很难一次把五个维度全部做全但至少要有一个可重复的“留出法”流程训练集和测试集在数据采集时就故意去耦合避免因为采集人员、设备参数或相机位置不同导致隐蔽的数据泄漏。4.2 一个可落地的泛化评测流程一个最小可落地的评测流程如下先定义任务用语言模板固定指令格式例如“将 {物体} 放到 {目标区域}”。再划分数据训练集使用 10 类物体、2 个场景、固定光照待测集使用另外 5 类物体、2 个新场景、1 组新光照。准备评测配置每个任务跑至少 20 次记录成功、失败、超时和人工干预次数。计算分组指标分别统计物体组、场景组、光照组的成功率不要只算总平均分。保留失败样本每个失败样本保存图像、语言指令、动作序列、机械臂日志用于后续分析。下面是一个评测配置文件的示例用于固定每个任务组的定义和重复次数eval_task_groups: - group_name: object_generalization command_template: 将 {object} 放到 {goal_region} test_objects: [杯子_透明, 圆珠笔, 玩具车, 手机壳, 纸盒] goal_regions: [目标点_A, 目标点_B] num_trials_per_object: 20 light_conditions: [fixed] camera_poses: [fixed] - group_name: scene_generalization command_template: 将 {object} 放到 {goal_region} test_objects: [杯子, 盘子] scenes: [厨房台面, 会议室桌面] num_trials_per_scene: 20 light_conditions: [fixed] camera_poses: [fixed]这个文件的价值在于把评测从“临时写一段脚本”变成“可重复的工程配置”。每次更新模型后跑同一套配置结果就能横向对比评测标准一旦固定下来团队内部关于“泛化是否变好”的争论也会少很多。注意评测集的数据在项目开始时就要和训练集分开管理。不要用同一批采集数据既做训练又做测试否则任何模型都会表现出虚高的泛化成绩。4.3 常用指标和它们各自掩盖的问题泛化评测常用的指标包括任务成功率、平均完成任务时间、平均干预次数和轨迹平滑度。成功率是最直观的指标但如果只报告总成功率会掩盖某一个维度的明显退化。平均完成时间只对成功样本有意义模型失败时尽早停止反而更安全。干预次数可以反映系统在真实环境下需要人工介入的频率但对自动化评测要求较高。还有一个容易忽略的问题评测过程本身需要有人或规则来判定“成功”。判定标准不同会直接影响指标。比如“放到目标区域”里目标区域是 5 厘米半径还是 20 厘米半径成功率会完全不同。建议在评测配置里把判定条件写清楚同时在发布结果时保留最原始的轨迹数据和失败样本这样即使后续判定标准调整也能重新统计。5. 提升泛化能力的工程路径数据、仿真、模型、硬件四层5.1 数据侧清洗、配比和多样性采样数据清洗是提升泛化能力的第一道关卡也是最容易被低估的一步。原始遥操作数据里往往存在几类问题动作不连续、末端执行器抖动、任务定义不一致、采集人员疲劳导致的无效演示。如果直接把这些数据送入训练模型会学到噪声和错误的时序依赖。一个实用的清洗流程包括以下步骤检查轨迹完整性剔除开始和结束状态不符合任务定义的轨迹。检查动作连续性对关节角度或末端位姿做差分超过阈值的帧标记为异常人工复核。统一标注格式把自然语言描述模板化避免同一任务出现多种语义表达式。平衡类别分布将高频物体和低频物体的样本比例控制在一个合理范围避免模型偏向少数类。移除近似重复样本用特征向量去重避免大量相似轨迹让模型过拟合。下面是一个简单的 Python 清洗脚本思路用于过滤轨迹中动作变化异常的帧import numpy as np def filter_unstable_frames(trajectory, joint_vel_threshold0.8): trajectory: 每行是一个时间步包含关节角度或末端位姿。 返回: 保留的有效帧索引列表。 if len(trajectory) 3: return [] velocity np.abs(np.diff(trajectory, axis0)) unstable_frames np.where(velocity.max(axis1) joint_vel_threshold)[0] valid_frames [] for i in range(len(trajectory)): if i - 1 not in unstable_frames and i not in unstable_frames: valid_frames.append(i) return valid_frames这段脚本的价值在于它把“动作异常”变成一个可量化的阈值判断。实际项目中可以把这个逻辑接入数据流水线自动标记疑似异常帧再由人工抽样复核。5.2 仿真侧用域随机化拉近 sim 和 real 的距离仿真数据的核心问题不是数量而是分布距离。域随机化的思路是在训练时让仿真环境里的材质、摩擦、光照、重力、机械臂参数在一定范围内随机变换迫使模型学习一个对参数不敏感的策略。典型配置如下domain_randomization: enable: true randomize: object_material: [metal, plastic, rubber, wood] object_color: true friction_coefficient: range: [0.3, 1.2] light_intensity: range: [500, 3000] table_height: range: [0.70, 0.90] robot_arm_joint_offset: range: [-0.02, 0.02]配置生成后每次环境复位时从范围内随机采样参数而不是固定使用一成不变的环境。这样做的一个直接收益是模型看到的外观变化足够多后它会逐渐放弃依赖颜色、纹理和固定高度这些无关变量转而依赖物体的几何、位姿和相对位置。要注意的是随机范围不能无限大。范围过大会让任务难度超过样本容量的表达上限训练无法收敛范围过小则泛化作用有限因此需要在实验中对每个参数单独做消融。5.3 模型侧统一动作空间、动作头和混合训练模型层面提升泛化要解决的是“同一套参数如何表达多个任务”的问题。一个常见的做法是让不同任务共享感知编码器和语言编码器