REFACTOR-VLA：用无监督学习将VLA黑盒策略重构为类型化运动程序库

Apple 这次放出的 REFACTOR-VLA第一眼看上去不是“又刷了一个更大的 VLA”那种路径。VLA 在机器人领域通常指视觉-语言-动作模型是当前机器人大脑的主流技术方向但前面加了 REFACTOR后面追了“类型化运动程序库”整个项目的意思就变了它更像是要把 VLA 这种端到端黑盒策略做一次架构级整理把策略训练过程中隐含的运动能力拆出来整理成一套可复用、可命名、可验证的运动程序模块而且这个整理过程尽可能不依赖人工标注。这不单是一个新模型发布更代表一种技术路线选择。端到端 VLA 虽然效果好但调试困难某个动作失败了是视觉理解问题、语言语义问题、采样策略问题还是奖励信号问题很难定位。运动程序库的抽象则把动作分解成相当于软件工程里的“函数”底层策略可以单独训练上层任务可以用语言模型做组合规划和调度。这个方向如果成立机器人策略维护会变得更加接近写代码而不是维护一个谁也不敢动的黑盒权重。文章会先拆解 REFACTOR-VLA 的设计意图再解释“无监督学习”和“类型化运动程序库”是如何配合的最后给出一套可参考的复现评估方案。考虑到目前公开资料只给出了项目概念和标题级描述具体参数量、显存占用、是否开放权重、API 路径都还不能确定文中凡是涉及具体数值的部分我会标清楚是通用参考避免把猜测当成官方结论。1. REFACTOR-VLA 核心能力速览先把已知信息和待确认信息分开。下表左侧是项目概念右侧是我基于命名和关键词形成的判断凡是项目面还没有明确公开的内容都标注为“待官方资料确认”。能力项说明项目名称REFACTOR-VLA发布方Apple机器人学习研究方向主要定位通过无监督学习将 VLA 策略转换为类型化运动程序库核心卖点让机器人技能变得可发现、可复用、可组合降低对人工动作标注的依赖技术关键词REFACTOR-VLA、无监督学习、类型化运动程序库所属技术栈视觉语言动作模型、机器人策略学习、技能发现、运动原语库模型参数量未公开待官方资料确认显存占用未公开待官方资料确认是否支持 CPU未确认通用大 VLA 不推荐 CPU 推理启动方式未确认论文阶段一般没有一键启动包是否支持 API未确认若有开源推理服务后续可能通过 HTTP/RPC 方式暴露接口是否支持批量任务未确认运动程序库天然适合批量轨迹复用但要看官方实现适合场景机器人操作技能学习、长时间任务规划、技能复用、多任务组合这个速览表要说明一件事REFACTOR-VLA 当前更适合被理解为研究型项目而不是一个拿到手就能pip install的命令行工具。不过机器人领域这类项目通常会在论文发表后陆续放出模型权重和推理代码值得后续持续跟踪。2. 适用场景与使用边界2.1 适合谁使用如果后续开放源码目标用户会很明确。机器人算法工程师可以在 VLA 策略上增加一层“运动程序库抽象”把单一模型替换成“技能库 规划器”的结构减少每个新任务都重新微调全量模型的需求。具身智能研究者可以重点看无监督技能发现方法特别是如何从无标签操作视频中提取稳定运动原语。自动化产线应用开发者则更适合把它当成一个技术验证方向先在仿真环境里跑通任务组合再决定是否在真实设备上落地。2.2 能解决什么问题这类项目最直接解决的问题是“策略复用难”。传统端到端 VLA 面对新任务时通常需要采集一批新任务的遥操作数据然后做全量微调。运动程序库的抽象则更像搭积木抓取、移动、放置、推、拉这些动作如果已经形成了稳定库新任务只需要在库层面做选择和排序不一定要重新训练底层动作。“类型化”还会进一步解决“哪些技能可以安全组合”的问题。如果每个运动程序都有明确的输入输出类型、前置条件和后置条件规划器可以在调用前做静态检查。比如pick技能要求夹爪打开、物体在可抓取范围内、动作空间是笛卡尔空间这些约束不满足时程序库直接返回错误而不是让模型硬产生一段不合法的轨迹。2.3 不适合什么场景如果只是需要一个简单的“图像 语言 → 机器人关节角”套路传统端到端 VLA 可能更省事。运动程序库方式需要额外维护技能粒度、程序签名、库版本前期工程成本明显更高。如果任务本身非常短、动作非常固定也不需要拆技能库。固定点位搬运任务里写死的控制脚本比 VLA 程序库方案更稳定、更快、更便宜。REFACTOR-VLA 的价值集中在任务种类多、动作复用率高、需要长程规划的场合而不是替代传统工业控制器。2.4 安全与合规边界机器人动作只要跑到真实硬件上就涉及物理安全。无监督学习发现的技能可能不稳定同一个技能在某个物体表面表现良好换一个材质却出现异常。真实设备测试前必须先在仿真环境穷举边界条件再在隔离区域、限速、急停保护的条件下验证。操作视频和遥操作数据可能包含真实人物、私有空间、物品和未公开的实验室信息。采集数据前要确认数据来源合法涉及他人的声音、人脸、物品或场所时需要获得明确授权。不能把未脱敏的真实环境数据直接丢进无监督管线跑技能发现也不要发布可能泄露他人隐私的轨迹片段。3. 理解 REFACTOR-VLA从黑盒策略到运动程序库3.1 为什么提复杂任务总绕不开 VLA机器人操作任务原本是“感知 → 规划 → 控制”三段式流程。视觉模块识别物体位置规划器在状态空间里搜索轨迹低层控制器负责跟踪轨迹。问题是三段式流程每层都有误差传递到最后动作很容易失效。VLA 的做法本质上是把三段式流程压缩成一个网络输入当前相机图像和任务语言指令输出动作序列。用大模型的多模态能力同时理解“看到了什么”和“要做什么”让视觉信息直接参与动作决策省掉中间物体姿态估计误差。这个路线在抓取、插孔、叠衣物等任务上都验证过效果。但端到端 VLA 的主要矛盾是数据成本和可控性。训练需要大量“图像 语言 机器人动作”对齐数据也就是遥操作记录而人类给机器人录轨迹时很难把动作切分成干净的技能单元。网络内部把感知、推理和动作全部揉在一起遇到边界案例要补充一个技能时不得不重新准备数据继续微调全量模型。REFACTOR-VLA 的关键转折就在这里不是训练一个更大的 VLA而是训练一个“能从 VLA 行为中提取运动程序的系统”。无监督学习负责自动发现动作数据里稳定的运动单元类型化负责给每个单元加上类似函数签名的输入输出规范最终得到的是一份运动程序库而不是单一策略。3.2 Re-Factor 的软件工程隐喻refactor在软件工程里是“重构”的意思在保持程序外部行为不变的前提下通过修改内部结构让代码更容易阅读、扩展和维护。如果把这个思想迁移到 VLA 上含义就很清晰了。策略模型学习到的“内部行为”不一定能被人类直接理解但理论上它可以被重新组织成一组更基础的运动程序并且重组后外部的任务表现不能下降。这就是 REFACTOR-VLA 名称里最关键的设计主张。“类型化运动程序库”则是重构的具体产物。普通技能库只有一个个技能的名字和执行代码类型化技能库会让每个技能带上一组接口声明。库里的技能不再是“可以用”或者“不可以用”这样的模糊状态而是能够回答“这个技能在什么条件下可以调用、输出空间是什么、完成后环境状态会发生什么变化”。一旦技能变成这种结构上层规划模型就可以像普通程序调用库函数一样去选择技能。4. 无监督学习如何建立运动程序库虽然官方还没给出详细训练流程但从“无监督学习 运动程序库”这个组合可以推导出一个非常典型的建模思路从无标签机器人操作视频中发现离散技能再对技能做语义和类型标注。4.1 数据形态与自监督目标可以假设模型的训练输入是大量“操作片段”。每个片段是由连续图像和机器人状态组成的轨迹它可能有任务级描述也可能完全没有人工标注。运动程序库学习的第一步是让网络在重建、预测、对比等自监督目标下学会区分不同的运动阶段。一个可行的自监督目标是“时序预测”给出一段观测历史让模型预测未来若干步的视觉特征或动作特征。机器人同一个运动意图产生的未来特征是相似的模型会把“抓住杯子”和“把杯子拿起”分开因为它们对应的未来动作趋势不同。另一个常见目标是“对比学习”把同一段轨迹切出的不同片段视为正样本把来自不同技能阶段的片段视为负样本让网络学到能够区分运动阶段的状态嵌入。拿到状态嵌入之后再做一层聚类聚类中心就对应运动程序库里的频次原语。这个过程不要求人工标签因此确实是“无监督”的。4.2 从连续轨迹中切割技能片段无监督技能发现有一个天然难点动作是连续变化的技能边界在哪并不明确。人类看到“抓取并拿起杯子”可能会把动作切成靠近 → 抓取 → 抬起但机器人记录里只有连续的位置和服务数据。解决这个问题需要引入一个“运动程序长度”的先验或者让网络自己学习动作片段应该持续多长。常见做法是用滑动窗口计算相邻时间步在嵌入空间里的距离距离突增的位置通常就是技能切换点。当机械臂从“前推”变成“抓取”时动作指令流会出现跳变这个跳变可以被检测到。如果 REFACTOR-VLA 的运动程序库设计更精细它可能会引入层次结构底层是几秒级别的运动原语高层是由原语序列组成的复合运动程序。这样长期任务可以被编码成一段由运动程序单元组成的“程序文本”方便语言模型理解和执行。4.3 为技能打上语义标签无监督聚类只能得到簇编号比如skill_0、skill_1、skill_2这时候技能库还不可读。要让技能被上层规划器使用需要把簇映射到自然语言描述。这一步可以由预训练视觉语言模型或大语言模型完成。收集每一个簇对应的轨迹片段把关键帧图和动作信息送给多模态模型让模型生成简短描述例如“把物体从左侧移动到中心区域”“打开夹爪”“向下按压”。有了语义标签运动程序库才真正变成能被语言指令调用的“库”。类型化是在语义标签基础上再加一层结构约束。skill_3只能描述为“靠近物体”但它需要知道进入该技能的视觉前提、输出动作空间、结束后物体的位置变化。这层结构约束就是第 5 部分要展开的“类型签名”。5. 类型化运动程序库给技能写“函数签名”类型化运动程序库和普通技能库最大的差异在于每个技能都配有可检查的程序签名。下面用一个概念示例展示它可能的设计方式这不是 REFACTOR-VLA 的官方定义而是帮助你理解这类系统应该有的结构。from dataclasses import dataclass dataclass(frozenTrue) class MotionProgramSignature: name: str input_observation: str action_space: str preconditions: tuple[str, ...] postconditions: tuple[str, ...] supported_objects: tuple[str, ...] () SKILL_LIBRARY { move_to_target: MotionProgramSignature( namemove_to_target, input_observationsingle_rgb, action_spacecartesian_velocity, preconditions(target_visible,), postconditions(reached_target,), supported_objects(object_pose_marker,), ), grasp: MotionProgramSignature( namegrasp, input_observationsingle_rgb, action_spacejoint_position, preconditions(gripper_open, object_in_reach), postconditions(gripper_closed, object_in_hand), ), place: MotionProgramSignature( nameplace, input_observationsingle_rgb, action_spacecartesian_position, preconditions(object_in_hand, target_available), postconditions(object_placed, gripper_open), ), }这种设计最直接的好处是可以写一个类型检查器只允许满足前置条件的技能被串联调用。def can_compose(first: MotionProgramSignature, second: MotionProgramSignature) - bool: required set(second.preconditions) provided set(first.postconditions) if not required.issubset(provided): missing required - provided raise ValueError( f无法将 {first.name} 与 {second.name} 组合缺少前置条件: {missing} ) return True当上层规划器决定执行grasp → place时类型检查器会检查grasp的完成效果是否能满足place的前置条件。grasp完成后的object_in_hand正好是place要求的前置条件因此这条组合链合法。如果把move_to_target直接接在place后面place要求的object_in_hand在move_to_target的后置条件里不存在组合就会被拒绝。这层抽象非常实用。规划器不用完全依赖语言模型的“感觉”去猜测技能是否兼容它可以先靠程序签名做一轮硬约束检查明显不能组合的技能直接拒绝再把合法子集交给执行器。6. 本地部署与复现前的环境准备由于 REFACTOR-VLA 尚未官方开源下面给的不是官方安装命令而是面向机器人 VLA 项目的通用环境准备模板。后续如果官方仓库发布再根据真实路径替换即可。6.1 硬件环境如果你要跑一个带有视觉编码器的 VLA 模型最好准备一张支持 CUDA 的 NVIDIA 显卡。设备显存建议至少不低于 16GB如果要做完整训练甚至在 24GB 以上具体要看你实际使用的模型版本。REFACTOR-VLA 如果只是提取运动程序库推理负载可能比直接跑一个 7B VLA 模型低因为它不需要每一步都让视觉语言模型输出动作技能库离线建好之后线上主要只做技能检索和轨迹生成。但这个判断需要官方模型复杂度确认。6.2 软件环境建议使用 Ubuntu 22.04 或同类 Linux 系统。Windows 可以跑部分机器人仿真但很多机器人仿真库和遥操作驱动优先适配 Linux。需要安装 Python、PyTorch、CUDA 工具链和一个机器人仿真环境。下面是一份通用依赖安装占位模板。# 创建虚拟环境版本按实际项目要求调整 conda create -n refactor_vla python3.10 -y conda activate refactor_vla # 安装 PyTorch注意跟本机 CUDA 版本匹配 # 这里只是占位示例具体版本请以 PyTorch 官网选择器为准 pip install torch torchvision # 克隆项目后安装依赖 # 官方仓库地址尚未公布下面路径需要替换成真实仓库 git clone https://github.com/your_org/refactor-vla.git cd refactor-vla pip install -e . # 安装常见仿真依赖 pip install gymnasium pybullet安装完成后先检查基础设备信息。import torch if torch.cuda.is_available(): print(GPU 名称:, torch.cuda.get_device_name(0)) print( 显存总量: {:.2f} GB.format( torch.cuda.get_device_properties(0).total_memory / 1024**3 ) ) else: print(未检测到 CUDA GPUCPU 模式只适合快速功能验证)7. 安装启动与功能测试验证流程官方代码没有放出之前建议先围绕“运动程序库”做功能验证测试。无论最终源码长什么样核心问题都应该是从无标签轨迹中发现的运动程序能不能稳定复现、能不能组合、能不能跨场景迁移。7.1 建立测试集准备一组机器人操作视频。不需要给每一个视频做时间戳级的技能标注但至少要保证数据里包含多种基础技能。例如抓取、放置、推动、堆叠、拉开抽屉等。记录每个视频的任务级描述方便后续对比测试效果。测试集要覆盖不同光照、不同物体颜色、不同起始位姿。无监督技能发现最怕的是把“光照变化”学成一种技能而测试集正是用来暴露这种问题的。7.2 技能一致性测试对同一种运动用不同观测角度重复测试看运动程序库是否返回稳定的技能标识。比如“从桌面上抓取红色积木”重复验证 20 次如果系统每次给出的运动程序都是grasp那么技能标识一致如果一半返回grasp、一半返回push说明无监督聚类边界不稳定。技能一致性是无监督系统质量的重要指标。簇边界不稳定会让上层规划器无法可靠调用技能。7.3 组合任务测试运动程序库的价值在于组合。设计一个两阶段任务“把积木推倒再抓起来放到盒子里”。这个任务需要先执行push再执行pick最后执行place测试库是否能自动生成组合链。如果系统是基于语言模型做规划输入指令后要观察它能不能输出合法的运动程序序列而不是直接输出底层关节轨迹。在这里类型检查器应该发挥作用拒绝不满足前置条件的组合。7.4 长程任务测试REFACTOR-VLA 如果要做长程任务还需要看错误累积情况。一个包含 40 步的运动程序链如果每步成功率是 95%最终成功率只剩约 13%这显然不可用每步成功率要达到 99% 以上长程任务才有实际价值。测试可以从第 10 步、第 20 步、第 30 步分别注入干扰例如移动物体位置、改变背景看运动程序库能不能重新规划后续动作。这类测试能反映技能库的鲁棒性。下面是一个评估脚本占位示例。tasks [ {instruction: push the block aside, expected_skill: push}, {instruction: pick the block and place it in the bin, expected_skills: [pick, place]}, ] for task in tasks: result evaluate_single_task(task[instruction]) print(task[instruction]) print( predicted skills:, result[skill_sequence]) print( success:, result[success])真正跑起来时evaluate_single_task会替换为项目提供的推理接口。8. 接口 API 与批量任务设计如果 REFACTOR-VLA 最终被封装成服务比较合适的接口不是让调用者直接传一张图获得原始关节角而是先返回运动程序序列再返回轨迹信息。这样调用方可以先把任务计划保存下来再由执行层决定是否执行。假设你用 FastAPI 封装规划服务接口形态大致如下import requests server_url http://127.0.0.1:8000 payload { image_path: /data/input/table_scene.png, instruction: put the red cup on the plate, max_skills: 10, return_trajectory: True, } response requests.post( f{server_url}/plan, jsonpayload, timeout60, ) if response.status_code 200: data response.json() print(skill sequence:, data[skill_sequence]) print(trajectory points:, len(data[trajectory])) else: print(error:, response.text)批量任务适合用数据表驱动。很多需要验证 REFACTOR-VLA 的场景都有现成的 csv 文件每一行包含一张图像路径、一条指令、一个期望结果。批量执行时要注意位置设置重试机制、输出日志、保存失败样例。import csv import time input_rows [] with open(tasks.csv, r, encodingutf-8) as f: for row in csv.DictReader(f): input_rows.append(row) for idx, row in enumerate(input_rows): print(f处理任务 {idx 1}/{len(input_rows)}: {row[instruction]}) for attempt in range(3): try: resp requests.post( f{server_url}/plan, json{ image_path: row[image_path], instruction: row[instruction], max_skills: 10, }, timeout60, ) resp.raise_for_status() break except Exception as exc: print(f第 {attempt 1} 次尝试失败: {exc}) time.sleep(2)批量任务常见的坑包括长时间连续调用导致显存增长、某一张异常图像让推理服务崩溃、技能序列输出长度不一致。批量代码里要单独保存失败样例的路径和错误信息方便后续定位。9. 资源占用、性能观察与排查方法显存占用现在没有官方口径但部署时应做三件事实时观察显存、记录推理延迟、留出余量防止 OOM。在 Linux 上可以用下面的命令持续监测 GPU 状态。nvidia-smi --query-gpuindex,name,memory.used,memory.total,utilization.gpu --formatcsv -l 1影响资源占用的因素大概率包括图像分辨率输入大小、运动程序库的序列长度、是否在同一条轨迹上同时运行多个模型、无监督技能聚类时缓存了多少轨迹片段。图像分辨率翻倍视觉编码器的显存占用可能翻数倍测试时先从低分辨率开始。如果出现显存不足优先检查以下几项批量大小是否大于 1、图像输入是否过大、是否同时加载了多个模型权重、是否在 PyTorch 里开启了梯度计算。推理阶段要把模型切换到eval模式并在torch.no_grad()下运行。常见的部署问题可以参考下面的排查表。问题现象可能原因排查方式解决方案服务启动后请求超时模型尚未完全加载或首次冷启动较慢查看服务日志和 GPU 占用服务启动后先发一次预热请求VRAM 不足图像分辨率太高或同时跑多个模型nvidia-smi查看占用进程缩小输入尺寸、关闭历史进程、用 batch_size1技能序列不稳定无监督聚类种子不同或数据分布变化多次运行相同输入对比结果固定随机种子统一预处理顺序规划器无法组合技能后置条件和前置条件不匹配打印类型检查错误信息检查运动程序库签名定义调用接口返回 500输入图像不可读或指令过长查看后端异常堆栈检查图像路径和请求字段